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 Did My SHR Volume Crash After an NVMe Cache Failure?

A read-write NVMe cache that drops off the PCIe bus takes the uncommitted writes it was holding down with it, and those writes were Btrfs filesystem metadata, so the HDD array stays healthy while the filesystem on top of it refuses to mount. Models with M.2 slots like the DS920+, DS1520+, and DS1621+ let you provision an NVMe SSD as cache, and the failure mode depends entirely on which mode you chose.

The whole risk turns on read-only versus read-write. They sound like a performance tuning choice and they are actually a data-safety choice, because only one of them sits in the write path:

Read-only cache (safe failure)

A read-only cache holds nothing but duplicate copies of frequently read data. Every block it caches already lives on the HDD array underneath. If the NVMe drive dies, it is holding no unique data and no uncommitted writes, so the primary volume stays intact and DSM simply drops the cache. This is the failure you want to have.

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 under sustained write load or a firmware panic, 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. That single failed check is the difference between a healthy block stack and a Volume Crashed banner.

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: The failed NVMe drive is imaged separately through the same write-blocked forensic imaging workflow. We then attempt to parse the DSM dirty-cache extents off that image and apply them as a delta against the base HDD volume, putting the uncommitted writes back where the filesystem expects them. This track is what can close the transaction-id gap the HDD track alone cannot.

There is a hard limit, and it is honest to state it up front. If the NVMe drive is physically unrecoverable, from NAND degradation or a dead controller board, the dirty writes are gone and nothing can recreate them. The Btrfs extent tree keeps permanent structural gaps where those extents should have committed.

btrfs-find-root and btrfs restore can still traverse older trees and pull most files intact, but they cannot synthesize data that evaporated with the cache. What was acknowledged to the cache and never flushed is the part that is lost.

Three pieces of advice circulating on forums make this worse. The first is to pull the degraded cache to force the volume to mount: yanking a degraded read-write cache guarantees the uncommitted writes are lost and crashes the volume outright, so it is the one move to avoid, not the fix.

The second is the DSM Repair button, which on a cache-dropout crash tries to rebuild the arrays while the filesystem is corrupt and writes over the very structure the recovery needs. The third is btrfs check --repair, which aggressively deletes orphaned inodes to force the tree to mount and destroys recoverable data in the process. None of the three is safe on a crashed read-write cache volume.

# 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
mdadm --assemble --readonly /dev/md127 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
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 destroy more SHR arrays than the original failure did: 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 that spans every drive so it can install its own operating system. If a drive went in the wrong slot, or the original crash involved partition-table corruption, that overwrite can bleed past the system partition into the data bands, taking out the LVM headers and the Btrfs trees.

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. One wrong parameter codifies the wrong geometry, and when the filesystem tries to mount it reads scrambled, out-of-order blocks that shred the Btrfs trees and the ext4 journal.

The original superblock is gone. The only safe assembly is mdadm --assemble --readonly, run against clones. The commands in the next section are read-only forensic diagnostics for sector clones, not a repair sequence for 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. 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.

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. Track one rebuilds the same mdadm and LVM block stack this page already documents. Track two unlocks the LUKS container that DSM 7.2 layers on top of it.

If the wrapped key on the md0 system partition is gone and you never exported the recovery key, a perfectly reconstructed block stack still decrypts to nothing, because a 512-bit AES-XTS master key cannot be brute-forced.

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 documented above. 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.

Three of the four layers are pure geometry: they reconstruct from on-disk metadata with no secret involved. The LUKS layer is the exception. It is the only layer whose recovery depends on a key rather than on geometry, and that single difference is what sets an encrypted SHR case apart from an unencrypted one.

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. Unlocking it needs the recovery key passphrase, supplied to cryptsetup luksOpen, 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 and the Btrfs or ext4 filesystem extracts read-only with the same tooling the rest of this page describes, 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 or remote over KMIP. The wrapped auto-mount key is bound to md0, the DSM system partition that mirrors across every member drive, which is why the Key Vault survives a single-drive failure but not the loss of the system RAID itself.

Recovery proceeds on the two tracks in order: first the block-stack reconstruction described throughout this page, then, once the LVM logical volume is active, the decryption pass.

The decryption pass runs cryptsetup luksOpen --readonly against the activated logical volume using the recovery key passphrase. 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 the Key Vault on md0 is intact, or you exported the recovery key when you enabled encryption, this step is routine and the case becomes a standard SHR extraction from that point on.

Here is the hard limit, stated plainly. AES-XTS with a 512-bit master key cannot be brute-forced. If md0 and the Key Vault are unrecoverable and no recovery key was ever exported, decryption is mathematically impossible even with a flawless mdadm, LVM, and Btrfs block stack underneath. No forensic tool and no lab technique circumvents that.

Any lab claiming a proprietary decryptor that opens a LUKS volume without the key is describing something that does not exist, and the same is true of the common forum advice to move the encrypted drives into a donor Synology: the wrapped key is bound to the original unit's Key Vault, so a replacement chassis does not unlock the volume without the recovery passphrase.

Encrypted-volume cases outside SHR, including legacy file-level shared-folder encryption, are covered in more depth on 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/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
vgchange -ay

# Track 2: unlock the LUKS container on the logical volume.
# Requires the recovery key passphrase. There is no way past
# this step without it; a 512-bit AES-XTS key is not brute-forceable.
cryptsetup luksOpen --readonly /dev/vg1/volume_1 shr_crypt

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