Synology NVMe Write-Back Cache Died. Don't Repair Over Healthy HDDs.

Written and maintained by the Desert Data Recovery lab team. · Updated September 22, 2026

We already wrote about DSM's Volume Crashed / Repair screen, about a controller Rebuild, and about Unraid Format and TrueNAS destroy-and-recreate. This is a narrower failure that can wear the same red banner. The cache SSD died or dropped. The HDD members of the volume can still be in the bays. Do not rebuild by swapping the cache first.

The cache is not a RAID member

A Synology volume is still the stack from the other post: mdadm or SHR, then LVM, then Btrfs or ext4 on the hard drives. An SSD cache sits on top of that stack. It is an acceleration device. It is not one of the disks SHR will reconstruct from parity.

Storage Manager can show all of this at once:

• SSD cache status Crashed, Missing, or Degraded on an M.2 NVMe
• Every HDD bay still Normal
• The volume or the storage pool flipped to Degraded, Read-only, or Crashed

Synology's own definition of a cache crash is that the number of failed SSDs exceeded the fault tolerance of the RAID type you chose for the cache. A single NVMe has no second member. That one module dying, or dropping off the bus, is already past tolerance. A two-SSD cache, usually RAID 1, can lose one SSD and stay degraded. The second failure is the crash.

The same red volume status is what the Volume Crashed post is about, and that post still applies to Repair, filesystem check, and reinitialize. This page does not repeat it. The new fact is which device is red. If the red device is the cache and the hard drives are still present, you are not looking at a one-disk pool rebuild.

Read-only cache and write-back cache fail differently

DSM's labels are read-only and read-write. Read-write is the write-back mode. People say "write-back cache" because that is what the mode does.

Read-only keeps copies of data that already live on the volume, to speed up reads. Synology's crashed-cache article says an SSD failure in this mode does not lose volume data, and their steps are: remove the cache, then create a new one on healthy SSDs. If Storage Manager says the cache was read-only and the volume is still Healthy, that is their documented path. It is not a reason to click Repair on the volume. This post is not that screen.

Read-write is different. Synology's description is that data are written to the SSDs first, to speed up access, and flushed to the hard drives later. Until that flush, the newest copy of some blocks can exist only on the NVMe. The HDDs still hold the volume. They may not hold the last writes.

There is a flush path, and it is narrower than people think. When a redundant read-write cache goes degraded — one SSD failed, tolerance not yet exceeded — DSM's automatic protection mechanism is supposed to stop new writes to that cache, send new writes straight to the drives, and write the cached data back. The alert Synology sends splits the next step in two. If the cache is read-only, or it is read-write and that flush has finished, they say remove the cache, replace the defective SSDs, and create a new cache. If it is read-write and the data have not been synced, they say contact Synology support. Read the alert you actually received. Do not assume the flush finished because the email subject said "crashed."

A single M.2 that dies or vanishes does not get that degraded-then-flush window. Tolerance was already exceeded. If you cannot confirm the sync finished, treat unflushed writes as possibly still on that module.

Synology's crashed-cache article then splits on volume status. Volume Healthy: remove the cache and create a new one; they attribute that to the protection mechanism having done its job. Volume Read-only: back up, remove the volume, create a new volume, copy the backup over, then a new cache. Volume Crashed: they send you to the crashed-volume article. That article says a crash caused by drive errors or filesystem errors cannot be repaired. If you can sign in and cannot read the data, it says contact a data rescue company. If you can still read the files, its path is back up, then remove the storage pool, then create a new one. If a drive was pulled by accident, put that drive back and use online assemble on DSM 7. None of those steps are "insert a blank NVMe and click Repair."

Replace-and-Repair is the wrong motion

Repair, in Storage Manager's own help for a degraded storage pool, is a pool operation. The pool still has redundancy. You replace the defective hard drive. Repair reconstructs that member. The option is documented as appearing when the pool is degraded. A crashed pool, that same help says, you can no longer repair yourself.

That procedure is what people know from a single dead disk in SHR or RAID 5. It gets aimed at the cache slot because the M.2 is the thing in red. The cache is not the member parity can rebuild. A new NVMe is empty. It does not contain the blocks that were waiting on the old write-back SSD. Repair, aimed at the pool or at the cache, writes. So does creating a new cache over a volume whose flush you have not confirmed.

Forcing the volume online is the same class of mistake. Online assemble is Synology's step for putting an accidentally removed drive back. It is not a way to mount a volume by substituting a blank cache module for the one that died.

The public case log has no write-back cache SSD job. We will not invent a case ID, a model, or an outcome. The Synology job we have published is a different failure: DDR-2026-0003, a four-drive RAID 5 (three ST3000DM001, one ST3000DM008) that went offline because two hard-drive members failed. One of those two was reporting only a few gigabytes. The filesystem on that set was EXT3/4. Nothing was rebuilt in the NAS. That is two-member RAID 5 loss, which is past what RAID 5 survives. It is not a cache SSD that dropped while the HDDs were still present.

The clicks that make a cache failure worse

Replace the red NVMe and click Repair. You just ran a pool rebuild, or a cache repair, against a layer that is not a single dead HDD. The write lands on the surviving disks and on the new SSD. Unflushed blocks that existed only on the original module are not reconstructed by that pass.

Create a new cache while the volume is crashed, read-only, or degraded, or while the alert says data have not synced. A new cache starts empty. Creating it is a write of a new map, not a restore of the old one. The healthy-volume path above is the exception Synology documents. It requires the flush to have finished. It is not the button to clear a crashed volume.

Remove the write-back cache to make the red icon go away. Removal is the documented step only after a read-only crash, or after a read-write flush DSM says completed, with the volume Healthy. Removing it earlier tells DSM to drop that cache as the device it was flushing from. The module can still hold the blocks. Leaving it out of the shipment is how those blocks stay behind.

Missing cache, new stick, restart. Synology's missing-cache steps are: identify the missing SSDs, put those SSDs back, restart. A different module is not those SSDs.

Check filesystem / Repair, reinitialize, or remove the pool and create a new volume. Those are the writes in the Volume Crashed post. In-place Btrfs repair spends older tree roots. Removing the pool is what the crashed-volume article suggests only after you already have a backup. If File Station will not open the files, you do not have that backup yet. "Back up, then delete the pool" is a copy-off of data you can already read. It is not a repair of a write-back cache.

Throwing the NVMe away because Storage Manager called it crashed. If any write had not flushed, that module is the only place it exists. Keep it, even if it no longer shows up in a PC. See SSD not detected for a module that will not enumerate. Do not run a vendor "SSD repair" or format tool against it.

Powered-on M.2 swaps. Synology's storage-pool help says to add or remove an M.2 only with the NAS fully powered off. Hot-pulling the cache is another way to crash a write-back device that was still flushing.

What to do right now

Do not click Repair. Do not create a new cache. Do not remove the pool. Do not online-assemble a blank SSD into the cache slot.

1. Stop. If an HDD is clicking or Storage Manager errors on a hard drive are climbing, power the NAS down. Cache failure and a dying HDD can show up in the same hour. Extra uptime on a clicking member is more heads-on-media you do not get back. See what a clicking drive means.
2. Photograph Storage Manager before you change anything. Cache mode (read-only or read-write), cache status, volume status, pool status, the drive list with the M.2 called out separately from the bays, and the exact alert text — especially any line about whether cached data has synced. Screenshots help. They are not a diagnosis.
3. If the volume is Healthy and the alert says the cache was read-only, or read-write and the flush finished, Synology's article is remove the cache and create a new one. That is their path. It is still not Repair. If you are not sure the flush finished, do not take it.
4. Leave the original NVMe in place until the NAS is powered off. Label the M.2 slot and every HDD bay before anything comes out. Bay order is part of the configuration. The failed cache module comes with the set. So does any replacement you already inserted.
5. Write down what you remember: read-only vs read-write, one M.2 or two, SHR vs RAID, DSM version, whether the volume was encrypted. Encryption without the key is still encryption.

Pack the hard drives and the NVMe the way you would any failed drive — how to ship a failed drive safely. An M.2 in a padded envelope arrives bent. Do not open a hard drive to check it.

How a lab handles it

We do not click Repair on your NAS. We do not create a new cache to see if the volume mounts. We do not remove the pool.

Each hard drive is imaged write-blocked, including a member that only reads in pieces. The original cache NVMe is imaged too if it still enumerates, before anyone provisions that module or a replacement. Work happens on the copies. SHR or mdadm is reassembled from the HDD images, then LVM, then the filesystem. If the cache image holds blocks the hard-drive images do not, that comparison happens on the copies. We will not invent a merge procedure, and we will not promise the cache image fills the gap.

There is no cache-SSD case in the public case log. DDR-2026-0003 was two failed RAID 5 members, imaged and reconstructed, with a full recovery on that set. That outcome belongs to that set. It is not a rate, and it is not a prediction about a write-back NVMe. We don't advertise a success rate.

If the NVMe will not talk at all, that module is an SSD problem on its own. The hard drives are still a separate imaging job. We will tell you if the data is not there. A Repair that finished, a new volume created on the same disks, or a cache module whose NAND is gone is not a puzzle we pretend we can solve. The free evaluation is how you find out which one you have before anyone bills you.

If DSM says Volume Crashed and you never had a cache, or the red devices are the hard drives, start with don't click Repair. If the screen is a controller Rebuild, see RAID rebuild vs. data recovery. If it is Unraid or TrueNAS, the cache-versus-array question is that post, not this one. QNAP can mix a dropped cache SSD into an Inactive volume; the button there is Recover. For how these cases run in the lab, see RAID data recovery and SSD & NVMe recovery.