Synology NAS Data Recovery Service

What Do Synology Error Codes Mean?

DSM reports failures through specific error states in Storage Manager. Each state tells you what failed and what remains intact. Volume Crashed, Storage Pool Degraded, Drive Status Critical, and beep codes each require a different first response. All share a common first step: power the NAS down and avoid further writes.

Volume Crashed

The filesystem or RAID array is in a state DSM cannot repair. This often means multiple drives failed, or the Btrfs/EXT4 metadata is corrupt. Do not click Repair in Storage Manager. Our Synology volume crashed recovery guide covers the underlying architecture and safe diagnostic steps.

Storage Pool Degraded

One member drive has dropped out, but the pool is still running on reduced redundancy. If a second drive fails before a rebuild completes, the pool crashes. Power down and contact us rather than starting a rebuild on aging drives.

Drive Status: Critical/Failed

DSM has marked a specific drive as unusable. SMART data may show reallocated sectors, pending sectors, or read errors. This drive likely needs professional imaging with retry control before it is usable in a reconstruction.

Beep codes (long continuous beep)

A long continuous beep on models like the DS920+ or DS1621+ signals a critical system warning, typically a volume crash or thermal shutdown. Do not swap drives in or out while the unit is beeping.

All of these errors share a common first step: power the NAS down, label each drive with its bay number, and avoid any further writes. The more you interact with a failing array, the more metadata gets overwritten.

How Does Filesystem Type Affect Synology Recovery?

Synology uses Btrfs by default on newer models (DS920+, DS1621+, DS423+) and EXT4 on older hardware. The recovery approach differs for each filesystem. Both sit on top of the SHR/mdadm layer, which must be reconstructed before any filesystem work begins.

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 sits on top of Linux mdadm and LVM. With identically sized drives it behaves like RAID-5 (SHR-1) or RAID-6 (SHR-2). With mixed capacities it stacks multiple mdadm arrays across capacity boundaries and joins them with LVM. The reconstruction workflow changes accordingly.

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.

Why Do WD Red DM-SMR Drives Fail During Synology Rebuilds?

Device-Managed Shingled Magnetic Recording (DM-SMR) drives like the WD Red WD20EFAX through WD60EFAX series cause a specific failure pattern in Synology arrays. During a RAID rebuild, the NAS writes sequential parity data across the replacement drive. DM-SMR drives can't rewrite overlapping shingle tracks fast enough to keep up with the controller's timeout window, so DSM drops the drive mid-rebuild and crashes the volume.

We clone timed-out SMR members using DeepSpar Disk Imager with modified read-retry algorithms that override the SATA command timeout. The imager reads sector-by-sector at its own pace rather than relying on the drive's internal shingle management. Once all members are imaged, we reconstruct the SHR array from clones using PC-3000 RAID Edition.

Why You Shouldn't Swap 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.

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.

How We Recover Data from a Failed Synology NAS

Synology NAS recovery follows an image-first, offline reconstruction workflow. Each member drive is connected through a hardware write-blocker and imaged with PC-3000 or DeepSpar before any analysis begins. Your original drives are never modified. All RAID reconstruction and filesystem extraction happen on cloned images.

1. Free evaluation: We document your Synology model (DS920+, DS1621+, RS1221+, etc.), the DSM error state, RAID/SHR configuration, filesystem type (Btrfs or EXT4), and any prior recovery attempts.
2. Write-blocked imaging: Each member drive is connected through a hardware write-blocker and imaged with PC-3000 or DeepSpar. Drives with weak heads or bad sectors get conservative retry profiles and head maps to maximize data capture without accelerating degradation.
3. Mechanical repair (if needed): Drives that click, beep, or refuse to spin require clean-bench head swaps with matched donor parts before imaging can proceed.
4. RAID/SHR reconstruction: We read mdadm superblocks from the imaged copies, determine stripe size, parity rotation, and member order. For SHR with mixed-size drives, we also reconstruct the LVM layer. PC-3000 RAID Edition performs virtual assembly from images, never from originals.
5. Filesystem extraction: Once the virtual array is assembled, we mount and extract the Btrfs or EXT4 filesystem. For Btrfs, we traverse subvolume trees and recover snapshots where applicable. For EXT4, we perform journal replay and inode table reconstruction.
6. 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.

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 a $400 to $800 array reconstruction fee for SHR/mdadm and LVM work. If we recover nothing, you owe $0.

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. Compare that to the $10,000-plus bundle quotes that larger recovery shops hand out with no per-drive breakdown.

Confidentiality, Chain-of-Custody, and Direct Engineer Communication

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.

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.

Why Does an M.2 NVMe Cache Failure Crash a Synology Storage Pool?

Newer Synology models (DS920+, DS1520+, DS1621+) support M.2 NVMe SSDs for read/write caching. If a cache SSD's controller suffers firmware corruption, the Synology can crash the associated Btrfs storage pool because dirty write-cache blocks never committed to the mechanical drives. The pool shows Volume Crashed even though the HDDs themselves are healthy.

We stabilize the failed NVMe SSD using PC-3000 Portable III to upload loader microcode into the controller's RAM, then extract the uncommitted dirty blocks. Those blocks are merged back into the main volume during offline reconstruction. This recovers data that never reached the spinning drives and would otherwise be lost if the cache SSD were simply replaced.

Synology Recovery FAQ