Synology SHR Hybrid RAID Data Recovery

What Is Synology SHR Actually Made Of?

SHR is a nested stack of standard Linux layers with a thin Synology management overlay on top. There is no proprietary RAID silicon inside a DiskStation. Knowing which layer failed decides whether your case is a routine read-only reassembly or a hand reconstruction, and none of these layers is a black box.

1. Physical disks and partitions

Every member is partitioned the same way: a small DSM system partition mirrored across all drives (md0), a swap partition, and one or more data partitions. On a mixed-capacity array DSM cuts each drive into multiple partitions so the spare capacity of the larger drives can be used rather than wasted.

2. mdadm software RAID

The data partitions are aggregated by mdadm, the same Linux software RAID tool that has shipped in the kernel for two decades. Each drive carries an mdadm 1.2 superblock written 4096 bytes into the partition, which records the array UUID, the member order, the chunk size, and the RAID level. A healthy array assembles with mdadm --assemble --readonly.

3. LVM logical volume

The Storage Pool is an LVM volume group, the Linux Logical Volume Manager that lets a NAS combine mismatched drive sizes. On a mixed-capacity SHR array LVM concatenates several mdadm arrays end to end into one continuous logical volume. It is activated on a workstation with vgchange -ay.

4. Btrfs or ext4 filesystem

The filesystem is formatted on top of the LVM logical volume. Btrfs is the snapshotting filesystem most modern DiskStations use; ext4 is the older default. Because Btrfs never overwrites a block in place, it writes the new version elsewhere and updates a pointer, which is exactly why an in-place repair tool can destroy the older, still-valid versions of your data.

A standard equal-capacity SHR-1 of three or more drives is a single RAID 5 set under LVM and a Btrfs filesystem. A mixed-capacity SHR is several RAID sets stacked by LVM. Either way the recovery is the same shape: read the mdadm metadata, bridge with LVM, mount the filesystem read-only. The hard cases are the ones where the LVM bridge or the Btrfs tree is damaged, covered below.

Why Are Mixed-Capacity SHR Arrays Harder to Reconstruct?

A mixed-capacity SHR volume is not one RAID array. It is several stacked on top of each other and joined by LVM, and each one has to be solved separately if the metadata is gone. This is the single thing that makes manual SHR reconstruction harder than a plain RAID 5, and it is the part most recovery pages never mention.

Take an SHR-1 of two 1TB drives and two 2TB drives. DSM carves a 1TB partition on all four drives and a second 1TB partition on the two larger drives. It builds the first band as a four-drive RAID 5 across the matched 1TB partitions, and the second band as a two-drive RAID 1 mirror across the leftover space on the 2TB drives.

LVM then takes both mdadm devices, marks them as physical volumes in one volume group, and concatenates them into a single logical volume. That is how SHR uses all 6TB of raw space to give you 4TB usable with one-drive fault tolerance instead of wasting the extra capacity the way classic RAID 5 would.

When the superblocks survive, all of this is automatic. When they do not and the geometry has to be carved by hand, the engineer solves disk order, chunk size, and offset once per band, not once for the volume.

If the LVM metadata that records the exact byte offset where the second band attaches to the end of the first is damaged, every band can be perfectly reconstructed and the Btrfs filesystem will still read as raw, unformatted data until that LVM bridge is repaired at the hex level. That repair is precise, irreplaceable work, which is why an LVM-layer failure is an in-lab job rather than something to attempt on the live NAS.

Why Is Clicking Repair on a Degraded SHR Array Dangerous?

DSM presents Repair as a safe, automatic fix. On a degraded array it is a high-stress parity rebuild, and there are two ways it turns a recoverable situation into a lost one. The first is mechanical. Repair forces every surviving drive to read every sector to recompute the missing parity. If a surviving drive already has weak heads or bad sectors, that sustained read load can finish it off, turning a logical recovery into a clean-bench mechanical job.

The second is statistical. Consumer drives carry a worst-case rating of one unrecoverable read error per 10^14 bits read, which works out to roughly 12.5TB. That is a warranty floor, not a countdown, and most drives read well past it without a single error.

But a degraded SHR-1 rebuild of, say, four 12TB drives has to read about 36TB off the surviving members to reconstruct the missing one, and across that much data the probability of hitting one latent unreadable sector is real. On a single-parity stripe there is no second parity to rebuild that sector, so mdadm can abort the resync and drop the array to crashed. This is the math behind why a RAID 5 or SHR-1 rebuild is never a routine button press on a large modern array.

The safe path does not depend on which failure mode you are facing. Image every member with ddrescue, the PC-3000 Portable III, or a DeepSpar Disk Imager first, give any marginal drive a conservative retry profile so imaging does not accelerate wear, then recompute parity against the clones where a mistake costs nothing. The Repair button writes to the only copy you have.

How Do You Recover a Synology SHR Volume?

We image every member through a hardware write-blocker, reassemble the mdadm and LVM stack from the clones, and extract Btrfs or ext4 offline. Your original drives are never modified. The steps below describe the work; they are not a do-it-yourself procedure, because a single wrong write to a superblock or an LVM header ends the recovery.

1. Free evaluation: We document the model, the DSM error state, the SHR-1 or SHR-2 layout, the drive capacities and whether they are mixed, the filesystem, and which members were dropped and when. Suspected SMR members are flagged here so imaging is throttled from the start.
2. Write-blocked imaging: Each member is cloned with the PC-3000 Portable III, the PC-3000 Express, or a DeepSpar Disk Imager. Marginal drives get conservative retry profiles and head maps; suspected-SMR drives get raised timeout thresholds so a cache-flush stall is not misread as a dead drive.
3. Geometry and band detection: We read the mdadm 1.2 superblock at offset 4096 on each cloned data partition to recover the member order, chunk size, and RAID level for every size band. On a mixed-capacity array this is solved once per band rather than once for the volume.
4. Read-only assembly: Each band is assembled from the clones with mdadm --assemble --readonly, never with create. For arrays whose superblocks are too damaged to assemble, the bands are reconstructed virtually from the imaged members using Data Extractor Express RAID Edition on the PC-3000 Express.
5. LVM activation or repair: The volume group is located with lvscan and activated read-only with vgchange -ay. If the LVM metadata bridging one band to the next is damaged, the physical-volume headers are repaired at the hex level so the bands concatenate in the right order before the filesystem is read.
6. Filesystem extraction: The filesystem is mounted read-only. If the Btrfs tree is damaged we work read-only with btrfs-find-root and btrfs restore against historical generation roots. We never run btrfs check --repair or force a recovery mount, because copy-on-write means an in-place write destroys the older roots the extraction depends on.
7. Verification and delivery: Recovered data is copied to a target drive, verified against your priority file list, and shipped back. Working copies are securely purged on request.

# READ-ONLY DIAGNOSTIC. For sector-by-sector clones only,
# not live or degraded drives. Wrong assembly = data loss.

# Assemble one SHR size band read-only from cloned partitions
mdadm --assemble --readonly /dev/md127 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

# Locate and activate the LVM volume group (read-only intent)
lvscan
vgchange -ay

# Mount the filesystem read-only once the LV is active
mount -o ro /dev/vg1/volume_1 /mnt/recover

The same RAID and filesystem logic applies to every Synology layout. SHR adds the size-band concatenation; the rest mirrors any RAID data recovery case we run, and SHR is one slice of the wider NAS data recovery work we handle across every vendor.

How Do I Reduce the Risk of an SHR Volume Crash?

Use CMR drives from your NAS vendor's compatibility list, not whatever SMR drive was cheapest, because the SMR timeout cascade is the failure mode that turns a healthy drive into a crashed array during a rebuild. If you run a large SHR-1, understand that a degraded rebuild on high-capacity consumer drives carries real URE risk, and consider SHR-2 on anything you cannot afford to lose so a second unreadable member does not end the array.

SHR also does not change the oldest rule in storage: a redundant array gives you hardware availability, not a backup. Ransomware, an accidental deletion, a controller fault, or a cascading failure across drives from the same manufacturing batch destroys every member at once. Keep discrete, offline backups, and verify them with a test restore to a different machine before you assume they protect you.