Synology Btrfs Volume Crashed? Don't Run Repair From DSM.

What this means and what to do next

Synology adopted Btrfs as the default filesystem on DSM 6 and continued it through DSM 7. Btrfs gives Synology features that ext4 doesn't: snapshots, checksums on every data block, self-healing reads against parity, and online conversion between volume layouts. The trade-off is that Btrfs is structurally far more complex than ext4. When something goes wrong it tends to go wrong in the metadata, and metadata corruption on Btrfs is harder to repair than equivalent corruption on ext4 — both for the user and for recovery labs.

The most common Synology Btrfs failure mode is not a disk failure at all. It is a metadata inconsistency between the Btrfs tree roots, usually triggered by an unclean shutdown (power cut, kernel panic, controller hang) while the volume was actively being written to. The underlying disks are perfectly healthy. DSM, on reboot, detects the inconsistency, marks the volume as crashed, and presents the user with two options: repair the volume, or rebuild it from scratch. Repair sometimes works. When it doesn't, it usually makes the situation worse.

The other class of Btrfs failure is checksum mismatches accumulating during a parity scrub on an SHR or RAID array. Btrfs records a checksum for every data block. If the scrub finds that the data on disk doesn't match the checksum and parity can't repair it, DSM reports the file as corrupt. A handful of such files is usually a sign of a degrading disk; hundreds at once is usually a sign of a controller, cable, or memory fault rather than the disks themselves.

The four most common Synology Btrfs recovery scenarios

1. Volume marked 'crashed' after unclean shutdown. Symptom: NAS boots, DSM loads, but the volume is shown as Crashed and shared folders are inaccessible. The disks themselves report healthy in Storage Manager. Cause: Btrfs metadata tree roots are inconsistent between superblock copies, typically from a write that was in flight during a power loss. Recovery: image each disk, assemble the underlying md/SHR array in software, then mount the Btrfs volume in degraded-read mode using btrfs-progs in our lab environment. From there the directory structure is recovered into a fresh filesystem on output media.

2. Btrfs reports 'parent transid verify failed' or tree corruption on mount. Symptom: DSM cannot mount the volume; the system log shows Btrfs errors referring to tree blocks or transid verification. Cause: a stale tree root is being followed, often because two transactions both partially committed before a power loss. Recovery: assemble the array in our lab, then use Btrfs forensic mount options (recovery, nologreplay, ro) to expose the most consistent point-in-time view of the filesystem. We pick the snapshot or root that recovers the largest fraction of the data and image it out.

3. Massive checksum errors after a scrub on SHR/RAID. Symptom: scrub reports many uncorrectable errors, files become unreadable, DSM may put the volume in read-only mode. Cause: the underlying RAID is silently inconsistent — usually a controller, cable, or memory issue that has been corrupting writes for a period without being noticed. Recovery: image the disks, then try a series of array assemblies to find the layout that produces the smallest number of checksum mismatches, recover the data from that assembly, and discard the irrecoverable files.

4. Volume drops to read-only with no further detail. Symptom: shared folders are still readable, but writes fail and DSM warns the volume has gone read-only. Cause: the kernel has decided the filesystem is too inconsistent to be trusted for writes — usually after a few earlier corrupt-block warnings. Recovery: in this state the data is still accessible; the right move is to immediately copy the most critical data off the NAS to another device (not to repair the volume in place), then arrange a lab recovery for the rest. The read-only state is recoverable if it is preserved; running repair from it usually is not.

How Data Clinic recovers a Synology Btrfs volume

Step one is a free triage call. We will ask about the failure sequence, what DSM is reporting, whether any repair attempts have been made, and the make/model of the disks. We will also ask whether the unit was UPS-protected — unclean shutdowns are the single biggest cause of recoverable Btrfs crashes turning into non-recoverable ones if a repair has been attempted in the meantime. If you call before running repair, your odds of full recovery are dramatically better.

If you ship the unit (or just the disks — Synology arrays are portable between units of the same family) to our Bury lab, we image each disk individually using PC-3000 imagers, then assemble the SHR/JBOD/RAID array in our recovery environment. The disks themselves are usually fine; the array is rebuilt virtually so the original physical disks are not modified. Btrfs is then mounted forensically — read-only, with various recovery flags — to find the most consistent view of the filesystem.

Recovered data is returned on a fresh USB-3 enterprise drive or, for larger volumes, a small replacement NAS pre-configured with your data. We provide a written report identifying which files were recovered intact, which were recovered with checksum mismatches (and so should be verified before use), and which were not recoverable. More on our NAS data recovery service →.

Get a free initial diagnosis in 60 seconds

In the tool below, choose NAS / RAID / Server and then volume crashed or read-only. The tool routes Synology Btrfs cases straight to our NAS recovery team.

What our customers say

Frequently asked questions