Synology NAS Data Recovery Service

What Do Synology-Specific Storage Terms Actually Mean?

DSM dresses standard Linux storage layers in Synology-branded names. Knowing what each term maps to in the underlying stack determines whether a recovery is a vanilla Linux reassembly or a forensic Btrfs traversal. Every term below has a concrete on-disk structure; none of them are proprietary black boxes.

SHR (Synology Hybrid RAID)

A DSM management overlay on top of standard Linux software RAID. The on-disk format is mdadm RAID 1 (two-drive SHR-1), RAID 5 (three-or-more-drive SHR-1), or RAID 6 (SHR-2) on equal-size slices, joined across capacity boundaries by LVM2 and topped with Btrfs or ext4. A healthy SHR array assembles on any vanilla Linux workstation with mdadm --assemble --scan, then vgchange -ay, then a read-only mount. SHR is not a proprietary algorithm.

DSM (DiskStation Manager)

The Linux distribution Synology ships on every DiskStation and RackStation. Userspace is a mix of busybox and Synology-authored binaries; the kernel and storage stack are standard upstream Linux with Synology patches. DSM lives on partitions md0 (system) and md1 (swap) of every member drive, mirrored across the array.

Volume Crashed

A DSM display string, not a single failure mode. It surfaces any unrecoverable error raised by the mdadm layer (dropped member, stale superblock), the LVM layer (missing volume group, broken physical-volume mapping), or the Btrfs/ext4 layer (parent transid verify failed, open_ctree failure, journal damage). Two Synologies showing Volume Crashed can have entirely different root causes.

Storage Pool

The LVM Volume Group that ties one or more mdadm arrays into a single addressable pool. On a fixed-capacity SHR-1 array the Storage Pool maps to a single md device. On a mixed-capacity SHR the Storage Pool aggregates multiple md devices that span different drive-size bands.

Btrfs Subvolume

An independently snapshottable B-tree root inside a Btrfs filesystem. On DSM, each shared folder is implemented as a Btrfs subvolume, which is why per-folder snapshots and per-folder quotas work. If the main filesystem tree is damaged but a subvolume root is intact, the subvolume can sometimes be extracted in isolation with btrfs restore against a discovered root generation.

Hyper Backup

The DSM backup application that produces .hbk container files for versioned, deduplicated, optionally encrypted backups. A corrupt or truncated .hbk container cannot be restored through Hyper Backup itself; recovery requires parsing the underlying versioned-archive format from a forensic copy. Always verify .hbk backups by performing a test restore to a different machine before assuming they protect you.

When you describe a failure to us, naming the layer (SHR vs Storage Pool vs Volume vs shared folder/subvolume) tells the engineer which on-disk structure to inspect first and shortens the time between intake and an honest recovery probability estimate.

How Does Filesystem Type Affect Synology Recovery?

Filesystem type determines which extraction tools we use after the SHR/mdadm layer is reconstructed. Btrfs recovery exploits copy-on-write B-tree history to reach prior consistent states, while EXT4 recovery relies on journal replay and backup superblocks. Both sit on top of the SHR/mdadm layer, which must be reconstructed first. Synology uses Btrfs on newer models and EXT4 on older hardware.

Both filesystems sit on top of the SHR/mdadm layer, which itself must be reconstructed first. We image every member, capture the mdadm superblocks and LVM metadata, rebuild the virtual array, and only then address the filesystem. XFS volumes (less common on Synology, but supported) follow a similar approach with XFS-specific log replay.

How Does Synology SHR Compare to Standard RAID-5 and RAID-6?

SHR is standard Linux mdadm plus LVM with a Synology management layer on top. With identical drives, SHR-1 behaves as a RAID 1 mirror on two drives and as RAID 5 on three or more drives. SHR-2 behaves as RAID 6. Mixed-capacity arrays stack multiple mdadm arrays joined by LVM, while standard RAID caps all members to the smallest drive and wastes excess capacity. SHR arrays reassemble on a vanilla Linux workstation.

For mixed-capacity SHR arrays, we reconstruct each underlying mdadm array from the cloned images, then reassemble the LVM volume group that ties them together. Plain RAID-5 or RAID-6 arrays skip the LVM step. The imaging, retry, and RAID data recovery parameter-detection workflow is identical.

Rebuilding a degraded SHR-1 or RAID-5 array on modern high-capacity drives carries a significant statistical risk of failure. Consumer-class drives are typically rated for one unrecoverable read error per 10^14 bits, which equals roughly 12.5 TB of data read. A rebuild that recalculates parity across a 48 TB array practically guarantees encountering a URE on a surviving member, halting the rebuild and crashing the volume. We image every member through a write-blocker before attempting any parity recalculation.

How Does DSM 7.2 Full-Volume Encryption Affect Recovery?

DSM 7.2 introduced full-volume encryption using LUKS in aes-xts-plain64 mode at the LVM logical-volume layer. The master cipher key is wrapped by the DSM Key Vault. If the Key Vault is gone and you do not have the exported recovery key, the encrypted volume is mathematically unrecoverable. We will tell you that on day one rather than bill you for theater.

Pre-DSM 7.2: eCryptfs at the shared folder

Older DSM releases encrypted at the shared-folder level using eCryptfs. Each folder was independently encrypted, filename lengths were capped at 143 characters, and the decryption key was unlocked at mount time using a per-folder passphrase or a key file. Recovery requires the original passphrase or key file; nothing else unwraps the per-file payload.

DSM 7.2+: LUKS at the logical volume

DSM 7.2 added full-volume encryption layered between LVM and the Btrfs/ext4 filesystem. The LUKS header sits at the start of the logical volume and stores the encrypted master key plus key-slot metadata. The cleartext master key is held by the DSM Key Vault and is wrapped with a vault-specific key. Daily mounting is transparent because the vault unwraps the master key automatically at boot.

What kills an encrypted volume

Hardware replacement without exporting the recovery key, factory reset, lost recovery key file, or motherboard failure on units that bind the vault to per-unit hardware identifiers. Without the wrapped master key, the LUKS header on the surviving members cannot be unsealed. The ciphertext on the platters is intact; the key needed to read it is not.

What we can and cannot do

With the LUKS recovery key in hand, we image every member, reassemble SHR/mdadm and LVM, decrypt the logical volume against the exported key, and extract Btrfs or ext4 normally. Without the key, there is no brute force, no manufacturer override, and no vendor backdoor. AES-XTS with a strong key is not a checksum; it is a cipher with a key space too large to enumerate.

Practical mitigation before disaster

Export the LUKS recovery key during initial volume encryption. Store it off the NAS: a password manager such as 1Password or Bitwarden, a printed copy in a safe, or a hardware token. A recovery key stored only on the same volume it decrypts is not a recovery key. A recovery key stored only on the same NAS is one PSU failure away from useless.

Encryption changes what a successful recovery means. Without the key, the only ethical answer is no. With the key, the recovery follows the same SHR + LVM + filesystem workflow as an unencrypted volume, with an LUKS decryption step inserted between LVM activation and the filesystem mount.

What Are the Risks of Swapping Drives After a Synology Beep Code?

Swapping drives, reinitializing, or reinstalling DSM after a failure overwrites the exact metadata we need to reconstruct your array. Every write to a member drive reduces the chance of a full recovery. Inserting a new drive triggers a rebuild that can crash the volume further.

A factory reset erases the LVM volume group entirely.

1. Inserting a new drive triggers a rebuild. DSM will attempt to rebuild the RAID array onto the new member. If the remaining drives have weak sectors or unreadable regions, the rebuild stalls or writes bad parity, corrupting the array further.
2. Reinstalling DSM overwrites system partitions on every drive. Synology stores DSM system files and swap on the first two partitions (md0, md1) of each member. A standard reinstall rewrites these system partitions and their RAID superblocks. User data resides on Partition 3+ (md2+), which a Mode 2 reinstall does not directly touch. However, partition table changes or selecting "Erase all data" can make array reconstruction harder.
3. Swapping drive order confuses the mdadm layer. SHR records which physical drive occupies which role in the array. Moving drives between bays without preserving the original order can cause DSM to misidentify members or trigger an unwanted reinitialization.
4. Factory reset destroys LVM and filesystem metadata. A full reset through DSM's Control Panel erases the LVM volume group that ties multiple mdadm arrays together in SHR configurations. This metadata is small but irreplaceable.
5. Moving drives to a new Synology chassis triggers a metadata rewrite. DSM will prompt you to "Migrate" or "Repair" the existing array. This rewrites the system partitions and attempts a forceful import. If the import fails, DSM offers a "fresh install" that permanently overwrites the data partitions.

The safe response to a Synology beep code: power off, label drives by bay position, and ship them to us. We will image each drive in its current state before any analysis begins.

Can Data Be Recovered After Reinstalling DSM?

Data recovery after a DSM reinstall is possible if you reinstalled without selecting 'Erase all data.' A standard Mode 2 reinstall rewrites system partitions md0 and md1 but does not directly touch user data and its mdadm superblocks on Partition 3+. If you erased and reinitialized, recovery becomes harder but may still be partially viable through filesystem carving.

We image each member through a hardware write-blocker before any analysis begins, then assemble the virtual array from cloned images using mdadm parameters extracted from each member. If Partition 3+ (md2+) is intact, the filesystem mounts normally after SHR/mdadm reconstruction. If the erase option was selected, we fall back to filesystem carving.

How Much Does Synology NAS Recovery Cost?

Synology recovery uses two line items: a per-member price based on each drive's physical and firmware condition, plus an array reconstruction fee for SHR/mdadm and LVM work. Each member drive is priced against the same five-tier schedule used for individual hard drive data recovery. If we recover nothing, you owe nothing under our no-fix-no-fee guarantee.

Per-Member Drive Pricing

Each member drive is priced against the same five-tier schedule used for individual hard drive data recovery. A four-bay unit with one head-swap member and three logical-only members generates one tier-4 line plus three tier-2 lines, not a single opaque bundle.

Array Reconstruction Fee

On a typical four-bay DS920+ with one mechanically failed drive and three healthy members, the invoice itemizes one head-swap line, three firmware or file-system lines, and the array reconstruction fee of $400-$800. Every drive is priced as its own line so you can see exactly what each member required.

How Do Btrfs, EXT4, and SHR Layers Work in Synology Recovery?

Synology stacks three independent layers under your shared folders: the mdadm/SHR storage layer, the LVM logical volume layer, and the Btrfs or EXT4 filesystem on top. Each layer can fail on its own, and knowing which layer is intact and which is corrupt drives the recovery plan.

A Volume Crashed error can originate in any of these three layers. If SHR/mdadm fails, the filesystem above never gets a chance to mount. If Btrfs or EXT4 metadata is corrupt but SHR is fine, the virtual array assembles cleanly and recovery moves directly to filesystem extraction. Mid-rebuild failures, like those covered in our NAS RAID rebuild data loss guide, typically corrupt the SHR layer first and leave the filesystem intact on the surviving imaged members.

How Does Confidentiality and Chain-of-Custody Work for Business Synology Data Recovery?

Business Synology workloads carry the same confidentiality expectations as any other storage system. We sign NDAs, log chain-of-custody from intake through return shipping, and route every technical question to the engineer performing the recovery. Drives stay in our Austin lab for the entire engagement.

This matters most when a case is time-sensitive: a SHR-2 with two failed members, a RackStation powering production infrastructure, or a DSM rebuild that stalled overnight. Decisions about retry profiles, head swaps, or pausing reconstruction to re-evaluate should come from the engineer with the drives on the bench, not a dispatcher reading from a script. The same logic applies to every RAID data recovery case we run.

What Do RTO and RPO Look Like in a Real Synology Recovery?

Recovery Time Objective and Recovery Point Objective are continuity-plan terms. When a production Synology has already failed, those objectives become questions: how long until data is back in hand, and how much in-flight work survived the crash. Honest answers require knowing the failure mode, the member condition, and whether snapshots or NVMe cache writes are involved.

Recovery Time Objective: time from intake to recovered data in hand

A two-bay unit with logically failed but mechanically healthy drives is typically recovered in 2 to 4 business days from intake. Four-bay SHR-1 or SHR-2 arrays run 4 to 8 business days because each additional member adds imaging time and changes the parameter-detection workload. Cases that need clean-bench head swaps, donor PCB sourcing, or platter work add 4 to 8 weeks while we source matched donor hardware. A rush fee of $100 moves a case to the front of the imaging queue, but it does not change the physical time required for head swaps or donor matching.

Recovery Point Objective: how much in-flight data is recoverable

On a Synology with Btrfs snapshots enabled, the latest healthy snapshot defines a guaranteed recovery point even when the live filesystem is corrupt. On a Synology with NVMe SSD write cache, dirty cache blocks that never committed to spinning media are recoverable only if the cache SSD can be stabilized through controller microcode upload. Without snapshots and without surviving cache extraction, the recovery point is the last consistent state captured in the on-disk filesystem at the moment of power-off.

Status updates and engineer contact during an active case

The engineer running PC-3000 and DeepSpar on your drives is the same person who answers status questions. There is no ticket queue between you and the bench. When an imaging session finishes or a parameter-detection result changes the plan, you hear about it from the engineer, not a dispatcher.

NDA and chain-of-custody timing

A mutual NDA can be signed before drives ship; it does not delay intake. Chain-of- custody logging begins at the moment drives arrive in the Austin lab, with serial numbers, bay positions, and SMART snapshots recorded before any imaging starts.

We will not commit to a calendar date during the free evaluation. We will commit to an ordered estimate once imaging results are in hand, because that is the first point where member condition is known with certainty rather than inferred from SMART output.

What Are the Most Common Synology Recovery Questions?