Synology NAS Data Recovery: When Drives Fail at Home or in the Office

If your Synology NAS just lost more than one drive at the same time, do not let DSM rebuild the array. Do not pop in a fresh drive. Do not click re-initialize. Synology's web interface is fantastic at managing healthy systems and dangerous when things are already broken. Every "helpful" suggestion DSM gives you when the array is degraded assumes the missing drive was an isolated failure. It usually isn't. When two or three drives go down close together, the metadata that knits the array back together gets scrambled, and a rebuild attempt writes new data over the very sectors a lab needs to read.

Single drive failure in a healthy SHR or RAID 5 setup? That's recoverable in-place. Swap the drive, let DSM rebuild, you're done in a day. Two or more drives dropping out, volume crashed, DSM upgrade bricked the unit, or Btrfs corruption after a power loss? Power the NAS off. Pull every drive. Note which bay they came from. Then call a lab. This guide explains why, what we do differently from what DSM tries to do, and what it costs.

What not to do right now (front-load)

If you're reading this with a sick NAS sitting in front of you, this section is the one that matters. The rest of the article is context. These are the four moves that turn fixable cases into unrecoverable ones, in the order people make them.

The pattern these all share is writing to the drives. A failed NAS needs to be read, not written. Powering off and pulling the drives is the safest move you can make. Slide each drive out, write the bay number on it with a marker or piece of tape (Bay 1, Bay 2, etc.), and stop. The drive order matters for reconstruction. If you put them back in the wrong slots, even a lab will have a harder time.

If you've already done one of the things above, don't panic. Stop now. Power the unit off. Most arrays we see have already had a rebuild attempted on them before the owner called us. We can usually still get the data, the case just gets more expensive.

Why Synology arrays fail

Synology builds reliable hardware. The DS920+ in a closet running for four years is a normal thing to see. So when a NAS does fail, the cause is rarely random. It's usually one of a handful of patterns we see over and over again.

All the drives were the same age and brand

This is the number one reason for multi-drive failures. You bought a 4-bay NAS, you populated it with four identical WD Reds at the same time, you spun them up on the same day. Four years later, the drives all start showing wear at the same time. One fails. While the array is rebuilding, a second one fails. Game over. Mixing drive ages and brands is the fix for this, but most customers don't do that until they've lost data once. SHR with mixed brands is the configuration to aim for if you're rebuilding from scratch.

Power events

Lightning strikes, brownouts, and bad UPS batteries kill NAS units in a specific way. The drives are usually fine. The Synology unit's controller takes the surge. The drives end up with bad parity blocks because the system was mid-write when the power dropped. When the unit reboots, DSM sees inconsistencies and either refuses to mount the volume or tries to scrub it (which writes more bad data on top of the existing bad data).

DSM upgrade gone wrong

Every few years a major DSM release ships with a regression that bricks a percentage of older units. The unit reboots into a recovery prompt, won't see the drives, or sees the drives but won't mount the volume. The data is fine. The unit is the problem. We've recovered hundreds of arrays from units running every DSM version from 5.x through 7.x.

Btrfs metadata corruption

Synology pushed Btrfs hard starting in 2016 for its snapshot and self-healing features. When Btrfs works, it's great. When the filesystem metadata corrupts (usually after an unclean shutdown or a failing drive), the volume goes read-only or refuses to mount. DSM's repair tools sometimes help and sometimes make it worse. We carry forensic Btrfs tools that don't write to the disks.

NAS unit controller failure

The drives are fine. The NAS unit itself is dead. Power LED is off, no fans, no beep. Or the unit powers on but the SATA controller can't talk to any of the drives. Older DS units have known capacitor failures on the motherboard. We can sometimes repair the unit, but the faster route is usually to take the drives to the lab and reconstruct the array virtually without ever needing the original NAS to come back to life.

Hot-swap mistakes

You see one red light on Bay 3 and you pull Bay 3. Turns out the problem drive was actually Bay 2, and your hot-swap just killed the array. Or you swap a drive while the unit is still trying to recover from a different fault. The lesson here isn't to never hot-swap. It's to look at the actual DSM error log before pulling drives. Storage Manager tells you which bay it thinks is failing, and that label is usually right but not always.

SHR vs RAID 5/6/10, and why it matters for recovery

Synology's storage layout choices look similar in the DSM web interface but behave very differently when something breaks. Knowing what you have changes what a recovery looks like.

SHR is Synology's proprietary layout that allows mixed drive sizes. Underneath, it's actually built on top of standard Linux mdadm and LVM, with some extra bookkeeping on top. That matters for recovery because we can use forensic mdadm tools on the imaged drives and reconstruct an SHR volume in our lab as if it were a regular Linux software RAID. Synology's special sauce is the management interface, not the underlying storage format.

RAID 5 with three drives can tolerate one failure. RAID 6 with four or more can tolerate two. SHR-2 is Synology's flavor of RAID 6. RAID 10 stripes pairs of mirrors, so you can lose one drive from each pair and survive, but lose both drives from the same pair and you've lost everything on that pair. The takeaway: if your NAS is in any layout other than SHR-2, RAID 6, or RAID 10 with careful planning, two simultaneous drive failures kill the volume. More on RAID 5 specifically here.

Failure scenarios we actually see

These are the most common Synology recovery cases that come through the lab. Skim to whichever matches your situation.

One drive failed in an SHR or RAID 5 array

This is the easy case. DSM shows one bay with a red light. The volume is still mounted. You can still access your files. You just need to swap the failed drive and let DSM rebuild.

You don't need a lab for this. You need a replacement drive of the same size or larger. The trap to watch for is buying a drive from the same brand and batch as the original failed one. If the failure was age-related, the remaining drives are at risk during the rebuild because they're being read intensively. The rebuild takes 24 to 72 hours on a typical 4-bay system, and during that window you have zero redundancy. If a second drive fails mid-rebuild, you lose everything.

Mitigation: back up the current data before swapping the drive. Yes, even though the array is still working. The rebuild puts the most stress on the remaining drives. Many multi-drive failures happen during a rebuild.

Two or more drives failed in SHR or RAID 5

The volume is dead. DSM shows the storage pool as "Crashed" or won't mount. Files are inaccessible. This is the bread-and-butter Synology recovery case.

What we do: image every drive sector by sector, including the failed ones, then reconstruct the array virtually in the lab. The failed drives often have most of their data intact and only specific bad sectors. Imaging a "failed" drive at the lab level recovers 90 to 100% of the sectors most of the time. Combined with the parity blocks on the still-working drives, we can usually reconstruct the original volume.

The order this work happens in matters: drives get cloned first, then reconstruction happens against the clones. Original drives stay untouched. If we make a mistake during reconstruction, we go back to the original drives and try again. Background on how RAID drive recovery works in general here.

Volume corruption after power loss

NAS was running, power went out, NAS came back up, volume won't mount or shows as read-only. The drives themselves are fine. The filesystem (Btrfs or ext4) got caught mid-write and the metadata is inconsistent.

DSM will offer to "check and repair" the filesystem. That sometimes works on minor corruption. On bigger corruption, the repair makes it worse. Lab process: image the drives, mount the filesystem read-only with forensic tools, copy the files off. If the metadata is too far gone, we use Btrfs forensic tools to walk the disk and reconstruct what we can without going through the filesystem.

DSM upgrade brick

You hit the DSM update button. Unit rebooted. Now it's stuck on "System Repair Required" or won't see the drives. Data is fine. Unit firmware is the problem.

Easy version: pull the drives, put them in a working Synology of similar or newer generation, the drives mount and DSM offers to migrate. Hard version: that doesn't work, drives need to be imaged and the array reconstructed in the lab. The migration path between DSM versions is well-documented and Synology has a "drive migration" feature for exactly this case. We use it when we can.

Btrfs metadata corruption

Volume mounts but you get "Input/output error" trying to read certain files, or the volume shows wildly wrong sizes. DSM's snapshot feature seems to work or doesn't, depending on which metadata block is hit.

This is one of the trickier recoveries. Btrfs is a complex filesystem with copy-on-write semantics, and broken metadata can corrupt previously-good snapshots too. We use a combination of `btrfs-rescue`, `btrfs-restore`, and forensic Btrfs walkers that don't trust the filesystem metadata at all. Most of the time we get most of the data back. Sometimes specific files are unreadable because their metadata pointers are scrambled.

NAS unit chip failure

Power LED off. Or LED on but unit beeping continuously. Or LED on, fans spinning, but no drives detected. The unit itself is dead.

Two paths. Path one: we repair the unit at the component level. The DS-series motherboards have known capacitor failures and SATA controller chip failures we can rework. Path two: skip the unit entirely. Image all the drives separately on lab hardware, reconstruct the array virtually, deliver the data on an external drive. Path two is faster and works regardless of how broken the unit is. More on RAID controller failures here.

Wrong drive replaced ("I pulled Bay 3 but Bay 2 was the bad one")

This is the panic call. You saw a red light, you pulled the drive you thought was failing, you put in a new one, DSM started rebuilding, and now the volume is gone. The drive you pulled was actually fine, and the rebuild started overwriting the new drive with bad parity data from the actual failed drive.

This case is recoverable in most situations. We image all the drives including the one you pulled, identify which drive was the real failure, and reconstruct from the correct combination. The longer the rebuild ran before you noticed, the harder it gets. If you catch it within the first 30 minutes you're usually fine. If the rebuild completed before you realized the mistake, the data on the new drive is permanently corrupted and we work off whatever's left.

Synology Not Booting? The Data Is on the Drives, Not the Box

A Synology that will not boot feels like total loss, but in most of these cases every byte of your data is fine. DSM, the operating system, lives on a small partition mirrored across your drives; the hardware that failed is usually the enclosure itself: power supply, mainboard, or a botched DSM update. The array and your shared folders are sitting there intact, waiting for something healthy to read them.

The failure patterns we see most: a blue power LED that blinks forever (mainboard or PSU), the unit powering off seconds after start (PSU or a shorted board), DSM stuck mid-update so the web interface never comes back, and Synology Assistant finding the unit as "Not installed" even though it ran for years. That last one is the dangerous moment: DSM will offer to reinstall, and depending on the prompt you accept, it can wipe the system partition or the whole volume.

Do not mount the drives read-write in a desktop PC either. SHR volumes are layered md-RAID plus LVM plus Btrfs or ext4, and Windows will offer to initialize the "unreadable" disks, which is exactly the click that destroys them. A lab clones every member drive first and reassembles the array virtually from the clones, so the originals are never written to. If the dead unit also hosted iSCSI LUNs or virtual machines, say so up front: those need to be extracted as images, and our virtual machine recovery guide explains why the VM layer changes the job. The same drives-first logic applies to QNAP hardware, which we cover separately in our QNAP NAS data recovery guide.

How a real Synology recovery works in the lab

NAS recovery is different from single-drive recovery in one big way: there are multiple drives that have to be coordinated. The process below is what happens after the unit arrives, in the order it actually happens.

Models we recover from

Every Synology model from the original DS-series through the current x25 lineup. SHR, SHR-2, RAID 0/1/5/6/10, Basic, JBOD. Btrfs and ext4. Rackmount and desktop. Single-bay through 24-bay.

We also handle SA-series, FS-series, and HD-series enterprise units. ZFS-based units (XS+ Plus running DSM with Btrfs) follow the same imaging pattern. If you've got a Synology, we can work with it. Our main NAS recovery page covers other brands too.

Honest pricing

NAS recovery costs more than single-drive recovery because there are more drives to image and more work to reconstruct the array. Here's what to expect, with no fake "starting at" numbers.

Two things to know about pricing. First, the price is for the actual recovery, not a deposit. If we can't recover, you owe nothing. Second, the range exists because we don't know the full damage until we image the drives. We won't quote you $1,200 over the phone and then surprise you with $3,000 once the drives are in our hands. Our full pricing page shows ranges for every recovery type.

When recovery actually isn't possible

We promised honesty, so here's the list of situations where the data is genuinely gone and no lab can help.

• Four or more drives in a 4-bay array all failed at the same time with significant media damage. Statistically, the data is gone. Even if each drive recovers 90% of its sectors, the missing 10% on each drive overlaps in ways that mean entire files are unrecoverable across the array. Math is brutal here.
• SHR-2 or RAID 6 with three or more simultaneous drive failures, same problem.
• The array was re-initialized through DSM after the failure. "Initialize" wipes partition tables. We can sometimes still get data, but the recovery rate drops dramatically and the price goes up.
• Drives that were used as a doorstop or run over by a vehicle. If the platters are physically cracked, the data on the cracked region is gone. Heat damage from a fire can do the same.
• Encryption with lost passphrase. Synology lets you encrypt shared folders. If you lost the encryption key and the volume is encrypted, the recovered files will be unreadable ciphertext.

If you're not sure which bucket you fall into, call us. We'll tell you within 10 minutes whether it's worth pursuing. We don't take cases we know are hopeless. The "no data, no charge" promise depends on us being honest about what we can do.

Real lab footage

What hard drive recovery looks like inside the cleanroom. NAS work happens here whenever the drives have mechanical damage from age, drops, or thermal failures. This is the same equipment we use on Synology drives.

The hidden cost of doing nothing

A degraded Synology array is a ticking clock. Every day the volume stays in a half-broken state, the remaining drives keep working under stress. Background scrubbing, snapshot maintenance, and routine reads all put more wear on the surviving drives. The right move when an array goes degraded is either fix it properly within days, or power it off entirely until you have a recovery plan.

The wrong move is to let it limp along while you "figure out what to do." We've seen customers who waited two weeks with a degraded array to decide what to do, only to have a second drive die during that window and turn a $1,500 recovery into a $3,500 one. If you can't act on it this week, power the unit off and store the drives somewhere safe until you can.

FAQ

Can Synology recover my data themselves?

Should I let DSM rebuild the array if one drive failed?

My DS920+ shows the volume as "Crashed." Can I still recover?

How long does Synology NAS data recovery take?

Do I need to ship the whole NAS unit or just the drives?

What if I already tried to rebuild and it made things worse?

Will I get back my Btrfs snapshots and shared folder permissions?

My NAS unit died but the drives seem fine. Can I just buy a new Synology and put the drives in?

Is my Hyper Backup file useful if the main NAS died?

Where are you located, and can I drop the drives off?

Do you work with businesses needing receipts or compliance documentation?