Synology Showing "Volume Crashed"? Don't Run Repair Yet.
UK NAS recovery specialists since 2002. SHR, SHR-2, RAID 5/6, Btrfs and ext4. Trusted by UK enterprises including the BBC, Tesco, HSBC and Williams F1.
What this means and what to do next
Synology's "Volume Crashed" status is one of the most alarming things a Synology NAS can show, and it's also one of the most misunderstood. It does not necessarily mean your data is gone — it means the volume can no longer be mounted by DSM, usually because there's a mismatch between what RAID thinks is on the disks and what the filesystem (Btrfs or ext4) thinks should be there. The data is almost always still on the disks. Recovering it is a question of getting at it without making things worse.
Synology builds its volumes in three layers. The bottom layer is Linux MD-RAID, which combines several disks into a redundant array. On top of that sits LVM, which manages the logical volumes. On top of that is the filesystem — Btrfs on most modern Synology models, ext4 on older ones or where users have selected it. "Volume Crashed" can be triggered by problems at any layer: a degraded RAID with bad sectors on a surviving disk, an LVM metadata corruption, or filesystem-level damage from a power cut or DSM upgrade interruption.
The reason DSM's "Repair" function is dangerous in this state is that it operates at the RAID layer, attempting to rebuild parity from what it thinks are good disks. If the assumption is wrong — if a second disk has latent bad sectors that have been masked by RAID, or if you've inserted a replacement disk that doesn't match the array geometry — Repair can write parity over good data. We see at least one case a month where a "Volume Crashed" that we could have recovered fully arrived at our lab as a half-rebuilt mess after the customer ran Repair first.
The three most common Synology "Volume Crashed" scenarios
1. Single disk failed in SHR/RAID 5, second disk has latent bad sectors. By far the most common scenario. A disk fails. RAID degrades but the volume is still online. The user replaces the failed disk and starts a rebuild. During the rebuild, the surviving disks are read end-to-end for the first time in years — and one of them hits unreadable sectors that RAID has been silently working around. The rebuild aborts, the volume drops offline, and DSM shows "Volume Crashed". Recovery requires imaging all disks individually, then reconstructing the RAID and filesystem from those images — never working live on the original disks.
2. Btrfs metadata corruption from sudden power loss or interrupted upgrade. Btrfs is robust under most conditions but its tree-structured metadata can corrupt during sudden power loss, especially if write caching was enabled. DSM upgrades that fail mid-process leave volumes in inconsistent states. The disks themselves are healthy and the user data blocks are intact, but the metadata trees that point to those blocks are damaged. Recovery requires forensic analysis of the on-disk metadata and reconstruction from the metadata's redundant copies.
3. Multiple disk failure beyond redundancy (two disks in SHR-1, three in SHR-2). Beyond the array's redundancy, the volume cannot be reconstructed by RAID alone. This is where many labs give up. Data Clinic doesn't — we can often recover most of the data by analysing what's still readable on the surviving disks, rebuilding partial stripes, and reconstructing files from the fragments. Recovery rates depend on which disks failed and how completely; expect partial recovery in this scenario, full recovery in the others.
How Data Clinic recovers a Synology "Volume Crashed"
First and most important: we work from images, not the original disks. We image every disk in the array individually using a PC-3000 or Atola DiskSense. Bad sectors are read repeatedly with different tactics until we have the most complete copy possible. The original disks are never written to and never used during the recovery work — they're set aside and returned untouched.
Once we have full images, we reconstruct the SHR or RAID layout in software. Synology's SHR is a clever variant of MD-RAID that uses different stripe sizes across uneven disks; we read the on-disk RAID metadata to determine the exact geometry, disk order and stripe parameters. We then reassemble the LVM layer to expose the logical volume that contained the data.
On the resulting reconstructed volume we run filesystem recovery tools — for Btrfs, our forensic tooling walks the metadata trees, falls back to redundant copies when the primary is damaged, and recovers files even when the volume cannot be normally mounted. For ext4, we use a combination of fsck-style repair on a copy and journaled-rollback techniques. Files are extracted, verified, and returned on a new drive of your choice. More about our RAID/NAS process →.
Get a free initial diagnosis in 60 seconds
In the tool below, choose RAID / NAS → Synology → Volume crashed for the right escalation path.
What our customers say
"Three years of family photos on a drive that suddenly failed. Data Clinic collected next day, kept me updated through the cleanroom work, and got everything back. Worth every penny."
"Honest, fixed-price, no-fix-no-fee. Quoted by another lab at three times the price. Recovered 100% of my files."
"Reasonable cost, clear communication, and they were straight with me about what was recoverable and what wasn't. Recommended."
Frequently asked questions
Should I just replace the failed disk and let DSM rebuild?
Only if the volume is still online and accessible — i.e. status is "Degraded" not "Crashed". If DSM is showing "Volume Crashed" and you trigger a rebuild, you risk overwriting recoverable data with parity calculated from possibly-bad disks. Get a recovery quote first; rebuilds can wait.
How much does Synology data recovery cost in the UK?
Most NAS recoveries fall into our standard tier: typically £695–£1,495 including VAT depending on the number of disks, total capacity, filesystem and damage extent. Emergency turnarounds and very large arrays (10+ disks, multi-terabyte) are quoted individually. Free diagnosis. No fee if we cannot recover your data.
Do I need to send the whole NAS or just the disks?
Just the disks is fine — but label them clearly with their bay numbers (1, 2, 3, 4, etc.) before removal. If you don't know which disk was in which bay, send the whole NAS. Don't change disk order; the recovery depends on knowing which disk holds which RAID stripes.
What if I've already run "Repair" or replaced a disk?
Recovery is still possible in most cases but the work is harder. Bring or send us everything — the original disks (including the one DSM said had failed), any replacement disks, and the NAS itself if the operation didn't complete. We treat each disk as a potential source of data and reconstruct from whichever copy is most intact.
Btrfs vs ext4 — does the filesystem affect recovery?
Yes. Btrfs is harder to recover when metadata is heavily damaged but provides more redundancy when partial recovery is needed. ext4 is more forgiving with metadata but offers fewer recovery hooks. We work with both routinely. If you don't know which one your volume uses, that's fine — we'll determine it from the disks.
SHR, SHR-2, RAID 5, RAID 6 — all the same to you?
We handle all of them, plus RAID 0, 1, 10, F1 (Synology's own redundant variant), JBOD, and the Hybrid Migration arrays. Synology's SHR is our most common case because it's their default. RAID 6 / SHR-2 (dual-disk redundancy) recovers more cleanly because there's more parity to work with.