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

On most models every member is partitioned the same way: a DSM system partition mirrored across the drives (md0), a swap partition, and one or more data partitions. On a mixed-capacity array DSM cuts the larger drives into more than one data partition, so their spare capacity doesn't go to waste.

2. mdadm software RAID

The data partitions are aggregated by the kernel's md driver, managed from userspace with the mdadm tool. 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 copy-on-write. On a normal write, it puts the new version of a block somewhere else and updates a pointer. That leaves the older tree roots sitting on disk. A repair tool that writes in place can destroy those 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 or ext4 filesystem. A mixed-capacity SHR is several RAID sets stacked by LVM. Either way we recover it from the clones in the same order: 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.

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.

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, assembly is automatic. When they don't, we solve disk order, chunk size, and offset on the clones once per band, not once for the volume. The LVM metadata records the exact byte offset where the second band attaches to the end of the first. If that metadata is damaged, the filesystem won't mount until we rebuild that LVM mapping, even if every band reconstructs perfectly. That's why an LVM-layer failure is an in-lab job rather than something to attempt on the live NAS.

Why Did My SHR Volume Crash After an NVMe Cache Failure?

When a read-write NVMe cache drops off the PCIe bus, the uncommitted writes it was holding go down with it. Your HDD array stays healthy. The Btrfs filesystem on top of it is left incomplete, and DSM reports the volume as crashed. Models with M.2 slots like the DS920+, DS1520+, and DS1621+ let you provision an NVMe SSD as cache, and the failure mode depends on which mode you chose.

Read-only cache

A read-only cache sits outside the write path. Synology's own SSD Cache white paper describes the cache as filled by data that is copied from the disks as it is requested, and it is the read-write mode, not this one, that Synology documents as write-back. In Synology's DSM 5.2 white paper, a multi-SSD read-only cache ran as RAID 0, and a read-write cache ran as RAID 1 "to ensure data integrity in case one SSD fails."

Read-write cache (dangerous failure)

A read-write cache sits in the write path. It intercepts new writes as a dirty cache and acknowledges them before they commit to the HDDs. When the NVMe drive drops off the PCIe bus, the writes it had acknowledged but not yet flushed to the array are gone. The HDDs never received them, and the filesystem is now missing structure it believes it already wrote.

Here is the part that decides the recovery: the corruption lands on the Btrfs filesystem layer, not on the mdadm or LVM block layers underneath it. The mdadm arrays and the LVM volume group come through the dropout intact, because the data that vanished with the cache was Btrfs filesystem-level metadata and extent updates, not block-device parity.

Btrfs is copy-on-write and stamps every tree update with a monotonically increasing transaction id, its generation tracking. When a parent node on the HDDs points at a child block and expects a transaction id that was only ever written to the now-vanished cache, the generation check fails.

The kernel reports a parent transid verify failed condition and refuses to mount the filesystem rather than serve corrupt structure.

Recovery runs on two tracks at once, the mechanical HDDs and the failed NVMe drive, because the surviving data and the lost data live on different media:

1. HDD track: Image every mechanical HDD member through a hardware write-blocker with the PC-3000 Portable III, the PC-3000 Express, or a DeepSpar Disk Imager, assemble each size band with mdadm --assemble --readonly, activate the LVM volume group, and mount the Btrfs filesystem read-only. Where the tree will not mount, we work read-only with btrfs-find-root and btrfs restore against historical generation roots that predate the aborted transaction.
2. NVMe track, in parallel: We image the failed NVMe drive separately.

There's a hard limit. If the NVMe drive is physically unrecoverable, the dirty writes are gone and nothing can recreate them.

btrfs-find-root and btrfs restore can still traverse older trees and pull out the files those trees still reference, but they can't bring back data that went down with the cache. What was acknowledged to the cache and never flushed is the part that is lost.

You'll find two pieces of advice on forums that make this worse. The first is to pull the cache SSDs to force the volume to mount. Synology warns that a read-write cache normally holds new data that hasn't been synchronized to the HDDs yet. It also warns that removing the SSDs before you remove the cache in Storage Manager can crash the volume.

The second is btrfs check --repair. It writes to the live tree and overwrites the historical copy-on-write roots we reach back to in a read-only extraction. Don't do either one on a crashed read-write cache volume.

If yours is one of the M.2-equipped prosumer units, the DS920+ NVMe read/write cache dropout is the exact case to read next, down to shipping the failed cache SSD alongside the drives. A caching device dying in front of the array isn't Synology-only either: a failed TrueNAS SLOG loses the in-flight synchronous writes after a sudden power loss, which is why NAS recovery across every vendor images the cache device and the array as two separate jobs.

# READ-ONLY DIAGNOSTIC. For sector-by-sector clones only,
# not live or degraded drives. The block stack is intact;
# the filesystem is the layer that will not mount.

# Block layers assemble cleanly from the HDD clones
# (N is the data partition number; Synology's own examples show 3 or 5)
mdadm --assemble --readonly /dev/md127 /dev/sdaN /dev/sdbN /dev/sdcN /dev/sddN
vgchange -ay

# A read-only mount fails with a generation mismatch when the
# cache that held the newest transaction never reached the HDDs:
#   parent transid verify failed on <block> wanted <N> found <N-x>

# Traverse older generation roots read-only. No check --repair,
# no recovery mount framed as safe. These read; they never write.
btrfs-find-root /dev/vg1/volume_1
btrfs restore -t <older_root_bytenr> /dev/vg1/volume_1 /target/recover

Why Should I Not Move SHR Drives to a New Synology or Run mdadm --create?

Two pieces of common advice can destroy a recoverable SHR array: migrating the drives to a replacement NAS, and forcing the array online with mdadm --create. Both write to the metadata you need for reconstruction.

When you move SHR drives into a new Synology and it offers to Migrate, DSM rewrites the md0 system partition so it can install its own operating system.

When the forced import then fails, DSM commonly offers a fresh install, which finishes the job. The metadata that recovery depends on is small and irreplaceable, and these workflows are precisely what overwrites it.

The mdadm --create command is just as final. Forum threads recommend it to force a crashed array back online, but create writes a brand new superblock over the original and makes you supply the exact drive order, chunk size, and layout from memory. Get one parameter wrong and that wrong geometry is now what the superblock says. Then mdadm starts a resync after the create, and it writes parity across that wrong layout, right over the data.

The original superblock is gone. The non-destructive assembly command is mdadm --assemble --readonly, and we run it against clones, never your live, degraded drives.

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. This is lab work, 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: We list the logical volumes with lvscan and activate them with vgchange -ay against the cloned images, never against your original drives. If the LVM metadata bridging one band to the next is damaged, we rebuild it by hand on the clones so the bands concatenate in the right order before we read the filesystem.
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
# (N is the data partition number; Synology's own examples show 3 or 5)
mdadm --assemble --readonly /dev/md127 /dev/sdaN /dev/sdbN /dev/sdcN /dev/sddN

# List the logical volumes and activate the volume group (cloned images only)
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 Synology's classic RAID levels. SHR adds the size-band concatenation. Everything else works like any RAID data recovery case we run. 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.

What Happens When an Encrypted SHR Volume Crashes?

An encrypted SHR crash is a two-track problem, and the honest answer is that one track is geometry and the other is a key you either have or you do not. On track one, we rebuild the same mdadm and LVM block stack as any SHR, from the clones. On track two, we unlock the LUKS container that DSM 7.2 layers on top of it.

DSM 7.2 full volume encryption is LUKS running in aes-xts-plain64 mode, the Linux device-mapper dm-crypt target. On an encrypted SHR volume that target sits between the LVM logical volume and the filesystem, which adds a fourth layer to the mdadm, LVM, and Btrfs or ext4 stack. Counting from the disks up, the order is now mdadm size bands, the LVM logical volume, the LUKS container, then the filesystem that lives inside the container. We reconstruct three of the four layers from on-disk metadata, with no secret involved. The LUKS layer is the only one whose recovery depends on a key.

1. mdadm software RAID (geometry)

The data partitions aggregate into one or more mdadm size bands, exactly as on an unencrypted SHR. Each band carries its 1.2 superblock and assembles read-only with mdadm --assemble --readonly. No key is involved at this layer.

2. LVM logical volume (geometry)

LVM concatenates the bands into one logical volume and activates with vgchange -ay. On an encrypted volume the logical volume holds ciphertext rather than a mountable filesystem, but the layer itself is still recovered from LVM metadata alone, with no key.

3. LUKS aes-xts-plain64 container (key-dependent, the new layer)

This is the device-mapper dm-crypt target that DSM 7.2 places on top of the logical volume. It is the only layer that no amount of geometry work can open. To unlock it, we need the recovery key file DSM exported. We base64-decode it and hand it to cryptsetup luksOpen as a key file, which creates the plaintext device mapping the filesystem lives inside. Without the key, the layer below it is intact and the layer above it is unreachable.

4. Btrfs or ext4 filesystem

The filesystem sits inside the unlocked LUKS container. Once the container opens, the plaintext mapping behaves like any SHR volume. We extract the Btrfs or ext4 filesystem read-only with the same tooling we use on any SHR, including btrfs-find-root and btrfs restore against historical generation roots where the tree is damaged.

The key material that auto-mounts the volume is held by the DSM Encryption Key Vault, local on the unit or remote over KMIP.

We work the two tracks in order. First we reconstruct the block stack on the clones. Once the LVM logical volume is active, we decrypt it by running cryptsetup luksOpen --readonly against the activated logical volume with the decoded recovery key file. That command maps a plaintext device without ever writing back to the encrypted container, and the Btrfs or ext4 filesystem is then mounted read-only off that mapping. If you exported that recovery key when you enabled encryption, the container opens and the rest is a standard SHR extraction.

An AES-XTS master key can't be brute-forced. If the Key Vault is unrecoverable and no recovery key was ever exported, decryption is impossible even with a flawless mdadm, LVM, and Btrfs block stack underneath. No forensic tool and no lab technique gets around that.

Any lab claiming a proprietary decryptor that opens a LUKS volume without the key is describing something that does not exist.

For encrypted volumes outside SHR, including file-level shared-folder encryption, see our Synology encrypted volume recovery page.

# READ-ONLY DIAGNOSTIC. For sector-by-sector clones only,
# not live or degraded drives. The block stack reconstructs
# from geometry; the LUKS layer needs the recovery key.

# Track 1: assemble the mdadm band and activate LVM read-only
mdadm --assemble --readonly /dev/md127 /dev/sdaN /dev/sdbN /dev/sdcN /dev/sddN
vgchange -ay

# Track 2: unlock the LUKS container on the logical volume.
# Requires the recovery key file DSM exported, base64-decoded.
# There is no way past this step without it; an AES-XTS key is
# not brute-forceable.
base64 --decode volume_1.rkey > /target/decoded_key
cryptsetup luksOpen --readonly -S 1 -d /target/decoded_key /dev/vg1/volume_1 shr_crypt

# Mount the filesystem inside the unlocked container read-only
mount -o ro /dev/mapper/shr_crypt /mnt/recover