Synology Volume Crashed Recovery

What Does Volume Crashed Mean on a Synology?

A Synology volume is a stack of standard Linux layers, not a proprietary appliance. DSM marks a volume Crashed when this stack can no longer assemble or mount cleanly. That is a metadata-layer failure: the array will not assemble, the volume group will not activate, or the filesystem tree is inconsistent. Knowing which layer failed determines whether recovery is a vanilla reassembly or a forensic filesystem walk. None of these layers are black boxes.

1. Physical disks and partitions

Every member drive is partitioned identically. Partition 1 across all drives forms md0 (a ~2.4 GB RAID 1 DSM system array), partition 2 forms md1 (~2 GB RAID 1 swap), and partition 3 and up form md2 and up (the data arrays). A failed DSM update can brick md0 while md2 data survives, which is also why a migration that rewrites md0 does not automatically destroy data unless you accept a fresh install.

2. mdadm software RAID

The data partitions are combined into a Linux mdadm array using the standard mdadm 1.2 superblock, located at a 4 KB offset from the start of each data partition. SHR is a management overlay on top of mdadm, not proprietary silicon: SHR-1 is RAID 1 on two drives or RAID 5 on three or more, and SHR-2 is RAID 6. A healthy array assembles on any Linux workstation with mdadm --assemble --readonly.

3. LVM logical volume

The Storage Pool is an LVM2 volume group built on the mdadm device. A mixed-capacity SHR stack splits each drive into size bands, builds a separate mdadm array per band, and joins them with LVM into one logical volume. The volume is activated on a workstation with vgchange -ay.

4. Btrfs or ext4 filesystem

Plus-series units default to Btrfs; value-series units use ext4. The filesystem sits on the LVM logical volume. A crash here can mean a Btrfs copy-on-write tree that no longer mounts even though every disk is healthy, which is a different problem from a missing array member.

Because the entire stack is standard Linux, a crashed array reassembles on a vanilla Ubuntu or Debian workstation. No Synology hardware is required to read the disks. That single fact is what separates an honest recovery from a firm charging a premium to read a format it falsely calls proprietary.

Should I Click Repair in DSM?

No. Repair on a degraded array issues an mdadm rebuild, and a rebuild is the most common way a recoverable Degraded state becomes an unrecoverable Crashed one. A RAID 5 or SHR-1 array that has lost one disk must read every remaining disk in full to reconstruct the missing member.

Consumer drives are rated for roughly one unrecoverable read error per 10¹⁴ bits read, which is about 12.5 TB. A rebuild across multi-terabyte members routinely reads more than that, so the probability of hitting at least one URE mid-rebuild approaches certainty on a large array. When mdadm hits a URE on a surviving disk during a degraded rebuild, it kicks that disk too, and the array crashes. And if you reinsert the originally dropped drive to force the repair, the rebuild overwrites any historical parity left on that drive that a forensic reconstruction could have used.

This is why imaging comes before any rebuild. We clone every member to a separate disk first, then perform all reconstruction against the clones, so a URE during analysis costs nothing. Rebuilding a degraded multi-terabyte array in place, without images, is a gamble with no second attempt.

How Can Btrfs Crash When All My Drives Are Healthy?

Btrfs is a copy-on-write filesystem. It never overwrites a live block; it writes a new version of the data or metadata and then atomically updates a pointer to it. That design protects you from torn writes, but it also means the filesystem depends on a consistent chain of metadata trees from the superblock down to the file extents.

If power is lost mid-transaction, or a read-write NVMe cache device fails and takes uncommitted metadata with it, a tree node can carry a generation number that does not match its parent. Btrfs reports a transid verify failure and refuses to mount the current root to avoid compounding the damage. Every disk can pass a SMART check and the volume still will not mount.

The previous tree generations are still physically on the disks. The correct response is to scan for older valid tree roots with btrfs-find-root, identify a consistent historical generation, and extract files with btrfs restore -t <root_id>. Running btrfs check --repair as a first step does the opposite: it prunes mismatched nodes to force a mount and can destroy the very historical metadata a clean extraction depends on.

How Do You Recover a Crashed Synology Volume?

Recovery follows one immutable rule: nothing writes to the original drives. The sequence below is read-only end to end, and it is the same whether the failure is at the array, the LVM, or the filesystem layer.

1. Power down and stop all activity. Every write to a degraded array, including a rebuild already in progress, risks overwriting recoverable data. The unit comes off as soon as the volume reads Crashed.
2. Image every member. Each disk is cloned to separate media with ddrescue, or with a PC-3000 Portable III or DeepSpar Disk Imager when a member is weak and needs head-aware imaging. All later work is done against the images.
3. Assemble read-only. mdadm --assemble --readonly rebuilds the array map from the cloned superblocks. We never use mdadm --create, which writes new superblocks and destroys the original layout.
4. Activate the volume group. vgchange -ay brings up the LVM logical volume from the assembled array so the filesystem becomes addressable.
5. Extract read-only. The filesystem is mounted with mount -o ro, or, when Btrfs will not mount, files are pulled directly from a historical tree root with btrfs restore. The recovered data is verified and returned on fresh media.

If you want the consumer-facing walkthrough of the same failure with less terminal detail, see our Synology volume crashed problem guide. This page is the architecture and methodology reference behind it.

Does a Synology Array Replace a Backup?

No. A redundant array gives you hardware availability, not a backup. SHR and RAID protect you from a single drive dying without downtime; they do nothing against the failures that actually crash volumes.

Ransomware, an accidental deletion, a controller or power fault that pollutes parity across every member, and cascading failures across drives from the same manufacturing batch all hit the whole array at once. Keep discrete, offline backups of anything you cannot recreate, and verify them with a test restore to a different machine before you assume they protect you. A crashed volume is survivable; a crashed volume with no backup and a rebuild already attempted is where recovery gets expensive.