Synology Says Volume Crashed. Don't Click Repair.

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

We already wrote about the RAID controller's Rebuild button, and about Unraid Format and TrueNAS destroy-and-recreate. This is the Synology screen: Storage Manager in red, volume status Crashed, and a Repair action that looks helpful. The words are different. The write is the same class of mistake.

What Volume Crashed usually means

A Synology volume is not one thing. Under Storage Manager it is a stack: mdadm RAID or SHR (Synology Hybrid RAID — mdadm plus LVM so mixed sizes can share a pool), then an LVM mapping, then a filesystem — Btrfs on most DSM 6/7 volumes, ext4 on older ones. Volume Crashed is a Storage Manager state. It does not say which layer failed.

The same red banner can be:

• An mdadm/SHR member loss — one disk dropped, or two, and the RAID will not assemble
• LVM that will not map the logical volume even though the RAID underneath still comes up
• Btrfs (or older ext4) damage: dirty log, broken tree roots, metadata that DSM will not mount

DSM does not split those out for you. The UI looks the same. Repair is offered in all of them. That is the problem.

We published a Synology four-drive RAID 5 that went offline with two members failed — public case DDR-2026-0003. Four Seagate Barracuda 3 TB disks (three ST3000DM001, one ST3000DM008), 9 TB usable. Two of four members failed — one more than RAID 5 can survive — and one of those two was reporting only a few gigabytes, a capacity/translator fault. The volume was inaccessible. Nothing was rebuilt in the NAS. Each member was imaged individually and the array was reconstructed from those images. The write-up describes an offline, inaccessible volume. It does not quote the DSM Volume Crashed banner, and we will not pretend it did. That job was two-drive RAID 5 loss. Volume Crashed in DSM can also be Btrfs or metadata damage with every member still present. Those are different failures that share one UI status.

Degraded is not Crashed. Repair is still a write on both.

Degraded means the volume is still mounted and redundancy is gone. On SHR-1 or RAID 5, one member is missing or failed and DSM is running without a spare copy of each stripe. The shares may still be up. That is the one situation where a replace-and-rebuild can be a normal maintenance step — if every remaining disk is healthy, the volume is still assembled, and you are following Synology's procedure for a single known-dead member.

Crashed means the volume is offline. DSM will not assemble it, or it assembled and the filesystem will not mount. Shares are gone. Repair here is not "check the disk and tell me what happened." It is DSM attempting to fix a layer it has not identified.

A degraded volume can become a crashed one if a second member dies, if someone yanks a disk, or if a filesystem check is run against media that is already throwing errors. Repair is dangerous on both states when you do not know which layer failed. Degraded-and-still-mounted is not permission to click past a crashed volume later.

The buttons that make it worse

Repair. In Storage Manager this is the Synology equivalent of a controller Rebuild or Unraid Format. On a crashed volume it can rewrite RAID metadata, run a filesystem repair, or both. It is not a read-only report. Believe that it writes.

Check filesystem / Repair filesystem. DSM can offer a check, then a check-and-repair. The check is still I/O against the patient disks. The repair is an in-place write to Btrfs or ext4. If the crash is RAID- or LVM-level, you just wrote to members that were not a filesystem problem. If it is Btrfs, see the next section.

Reinitialize. This creates a new volume structure on the same disks. The old RAID, LVM, and filesystem are treated as gone. Do not "start clean" on disks that still hold the data.

Replace the red drive and Repair. A rebuild writes reconstructed data onto the new disk and updates parity on the survivors. That is correct only when one member is dead, the rest are healthy, and the volume is still a RAID problem. On a crashed volume you do not have that confirmation. A second weak member, a bay swap, or a filesystem-only crash turns the rebuild into the overwrite we already describe in RAID rebuild vs. data recovery. Two members down on RAID 5 or SHR-1 is already past what the array can survive — that is RAID 5 with two drives failed, not a replace-and-rebuild.

Yanking or reordering bays. SHR and mdadm care about member identity. Pulling disks to "test them in a PC," swapping two bays, or reseating until Storage Manager looks happier can change which member DSM tries to reconstruct. Label first. Do not shuffle.

Expanding or creating a new volume on the same disks. Adding a disk to expand, or creating a fresh volume so the NAS "works again," writes a new map over the old one. The crashed volume you still need is then competing with a new filesystem on the same platters.

Why Btrfs repair is especially risky

Modern Synology volumes are usually Btrfs. Btrfs is copy-on-write. It keeps historical tree roots — older generations of the filesystem — that a lab can walk with read-only tooling if nobody has written over them. That is often the whole job when DSM will not mount: the current root is dirty, an older one is not.

In-place Btrfs repair rewrites superblocks and tree roots on the live members. It can destroy the older generations that were still readable. btrfs check --repair has the same reputation outside Synology; DSM's Repair / repair-filesystem path is that class of write with a friendlier label. Once those roots are gone, we are not walking them back.

Older ext4 volumes do not have that generation story, but fsck-style repair is still a write. It is not "just a check." If the crash is actually a dead RAID member, you are running filesystem repair against an incomplete array.

What to do right now

Do not click Repair. Do not run a filesystem check to "see if it comes back." Do not create a new volume on the same disks.

1. Stop. Leave the NAS alone. If a drive is clicking, grinding, or SMART / Storage Manager errors are climbing, power the unit down. Extra uptime on a dying member is more heads-on-media you do not get back. See what a clicking drive means.
2. Photograph Storage Manager. Volume status, RAID/SHR type, drive list with serials if shown, any exact error text, and the bay order on the back of the unit. Screenshots of the crashed banner help. They are not a diagnosis.
3. Label every bay before anything is unplugged. Slot 1 through slot N, matching the photos. Bay order is part of the configuration.
4. Keep every disk, including the one you think is dead and the spare you already inserted. On SHR, the disk you "replaced" may still be a required member.
5. Write down what you remember: SHR vs RAID 1/5/6/10, DSM version if you have it, encryption keys if the volume was encrypted. Encryption without the key is still encryption.

If a disk is mechanical, pack it like any other failed drive. Do not open a drive to "check" it. Do not leave the set running overnight so Repair can finish.

How a lab handles it

We do not click Repair on your NAS. We do not run DSM check-and-repair against the patient disks.

Each member is imaged write-blocked, sector by sector, including disks that only read in pieces. SHR or mdadm is reassembled from those images, then LVM, then the filesystem — Btrfs or ext4 — extracted offline. A wrong guess about rotation, member order, or which generation root to walk costs a clone, not the original. That is the same method we use on hardware RAID, Unraid, and TrueNAS.

On DDR-2026-0003 that meant imaging all four members — including the two that had failed and the one misreporting capacity — then reconstructing the RAID 5 from the copies. Full recovery on that job. That is what happened on that set. It is not a rate, and it is not a promise about a Btrfs crash on a different NAS. We don't advertise a success rate.

We will tell you if the data is not there. A Repair that finished, a reinitialize, or a disk whose platters are 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 the screen you are looking at is Unraid or TrueNAS rather than DSM, start with what not to click on those boxes. If it is a controller Rebuild button, see RAID rebuild vs. data recovery. For how these cases run in the lab, see our RAID data recovery service and the case log.