If your Synology DiskStation has crashed its storage pool, refused to mount its volume after a reboot, failed during a DSM upgrade, dropped to recovery mode, or been hit by ransomware, you’ve reached the right team. Synology is the most widely deployed prosumer and small-business NAS brand we see at the lab, and Synology cases account for a substantial share of the NAS recovery work we handle. Gillware has been recovering data from failed Synology DiskStations and RackStations since the original DSM platform shipped, from our ISO 5 Class 100 cleanroom in Madison, Wisconsin. Synology cases are scoped at intake by an engineer who has handled the failure mode you’re looking at — not by a generic sales gate. See also our NAS data recovery hub.

Open a Synology recovery case →

How Synology NAS Devices Work

Synology has been shipping the DiskStation line for nearly two decades, and the deployed fleet today spans dozens of models and three major DSM operating-system generations. Knowing which generation and model family your unit belongs to is the first step in scoping a recovery, because the storage layer underneath has changed meaningfully across the line.

DSM (DiskStation Manager) generations. The Synology operating system has shipped in three actively-deployed generations. DSM 5.x is the legacy version that ran ext4 only and was the standard from 2014 through 2016. DSM 6.x, released in 2016, introduced btrfs as a supported (and eventually default) filesystem alongside ext4. DSM 7.x, released in 2021, is the current version on supported hardware. Older hardware that can’t run DSM 7 is stuck on DSM 6 (or in some cases DSM 5) permanently — Synology has not back-ported DSM 7 features and is not going to. Recovery from a DiskStation depends in part on which DSM generation the unit was running, because the filesystem and the storage layout differ across them.

Model lineup we recover. The active Synology fleet is dominated by the DiskStation (DS) desktop line. Common single-bay units include the DS115j, DS118, and DS119j. Common two-bay units include the DS218+, DS220+, DS220j, DS220play, DS223, and the older DS214, DS214play, DS214+, DS216, and DS216+. Common four-bay units include the DS418, DS418j, DS418play, DS420+, DS420j, DS423, and the older DS412+, DS413, DS414, DS414j, DS415+. Common higher-capacity units include the DS918+, DS920+, DS923+, DS1019+, DS1517+, DS1520+, DS1522+, DS1618+, DS1621+, DS1819+, and the older DS1512+, DS1513+, DS1812+, DS1813+. Synology’s small-rackmount RackStation line (RS series) overlaps with the SMB tier we recover — RS217, RS218, RS422+, RS820+, RS822+, RS1219+, RS1221+ — though larger RackStation units are closer to enterprise SAN than to consumer/SMB NAS and follow a slightly different recovery profile.

The storage stack underneath DSM. Across the entire DiskStation lineup, the storage layer below DSM is built on standard Linux components arranged in a Synology-specific configuration. mdadm software RAID handles the redundancy layer; LVM handles the volume management layer; ext4 or btrfs sits on top as the filesystem. Each member drive is partitioned into a small DSM system partition (the operating system — identical content mirrored across all drives), a swap partition, and a data partition. The data partition is the one mdadm assembles into the RAID array, with LVM and the filesystem on top of that. This stratified architecture is what makes off-controller Synology recovery viable: the system partition can be completely corrupt and the data partition still intact.

SHR (Synology Hybrid RAID). Synology’s proprietary RAID variant, available on most Plus-series and J-series DiskStations as the default option. SHR allows mixed-capacity drives in the same array and automatically expands available capacity when drives are upgraded one at a time. Under the hood, SHR is built on multiple stacked mdadm arrays — not a single large array but a layered set of smaller arrays that together present a single volume. This stacking is the technical basis for the mixed-capacity behavior and is also the property that makes generic mdadm-aware recovery tools frequently miss the full SHR layout. SHR-2 is the dual-parity variant that tolerates two simultaneous disk failures. Recovery from an SHR array requires reconstructing the layered mdadm topology correctly, which is fundamentally different from reconstructing a flat RAID 5 or RAID 6.

btrfs and the snapshot layer. When btrfs is selected as the filesystem (the default on supported DSM 6+ models), DSM enables additional features including filesystem-level snapshots, self-healing checksums, and Hyper Backup with snapshot-based incremental backups. The snapshot layer is one of the more important Synology recovery considerations — on a unit where snapshots existed before a failure event, those snapshots are sometimes the cleanest recovery path back to a known-good state. They are especially relevant in ransomware scenarios. Identifying which snapshots exist on a downed unit and which are reachable is part of our recovery scoping.

Synology Failure Conditions That Lead to Data Loss

The patterns below are the ones that disproportionately bring Synology cases to our lab.

Storage Pool Crashed. The most common DSM error state we see. The storage pool reports a “Crashed” status in the DSM Storage Manager, the volume on top of it shows as inactive, and shared folders are inaccessible from the network. The underlying cause is usually multi-drive failure beyond the array’s fault tolerance: one drive had been quietly degraded for some time, a second drive failure pushed the pool over the redundancy limit, and DSM took the entire pool offline. Sometimes the cause is metadata corruption on a single drive that DSM has escalated to the whole pool. More on crashed Synology storage pools →

Volume Crashed (distinct from Storage Pool Crashed). The DSM storage stack has two layers above mdadm — the storage pool and the volume. The volume can crash while the storage pool remains active, when the failure is at the filesystem layer rather than the RAID layer. On btrfs volumes this typically means metadata-tree corruption that the kernel cannot navigate cleanly; on ext4 volumes it typically means journal corruption or partition-table damage at the volume layer. The data is generally still on the underlying storage pool; the path through the filesystem is what’s broken.

System Partition Failed on Multiple Drives. DSM mirrors its system partition (the operating system itself) across every drive in the array. When the system partition fails on a single drive, DSM marks it and continues using the others. When the system partition fails on multiple drives simultaneously — usually after a power event, a botched DSM upgrade, or an extended period of file system corruption that escalated — the unit may boot but report that the system partition is failed across the array. The data partition is generally intact; the operating system has just lost its working copy. DSM offers a “system partition repair” function from the recovery interface that sometimes succeeds and sometimes leaves the unit in a worse state.

Recovery Mode / “Bootloader not found”. The unit boots, displays the Synology splash screen, and then drops to a recovery mode state — sometimes accessible through the Synology Assistant utility, sometimes not. The DSM system partition has failed on all the drives, the unit cannot complete its boot sequence, and shared folders are unreachable. The data on the storage pool is typically intact, but DSM cannot mount it without a functioning system partition. We see this most often after a partial DSM upgrade, after a power event that interrupted a write to the system partition, and on aging units where the underlying hardware is gradually failing.

DS214+ flashing blue power light. The specific motherboard failure mode on the DS214+ that has become well-documented enough to identify by symptom alone — the unit powers on, the blue power LED flashes continuously, and the unit never reaches a usable boot state. The cause is motherboard failure; the drives inside are typically intact. Several other older DiskStation models (DS213, DS414, DS415+) have related but distinct motherboard-failure symptoms. More on the DS214+ flashing blue power light →

DSM update failure or DSM 6 to DSM 7 migration issues. DSM updates are usually low-risk, but the 2021 transition from DSM 6 to DSM 7 produced a wave of failed-upgrade cases. Several specific DSM 7 minor versions (DSM 7.0 early releases, certain DSM 7.1 builds) have been documented as causing post-upgrade volume mount failures on units that had been running smoothly on DSM 6. We see cases where the upgrade completed apparently successfully, the unit rebooted, and the storage pool came back online inactive or crashed. The data is intact; the firmware layer is in an inconsistent state.

Failed migration between DiskStation models. A common Synology failure: an owner with a working older DiskStation (DS214, DS218, DS415+) buys a newer model (DS220+, DS420+, DS920+) and migrates the drives expecting a seamless transfer. Synology documents this as “drive migration” and has compatibility tables describing which model-to-model paths are supported. The field cases that arrive at our lab are the ones outside those compatibility paths, or the ones inside the documented paths that didn’t complete cleanly. Symptoms include the destination DiskStation refusing to recognize the storage pool, prompting to reinitialize the drives, or appearing to import the pool but mounting it inaccessibly.

SHR reconstruction failures. SHR’s mixed-capacity flexibility comes from a stacked-mdadm topology that’s more complex than standard RAID. When the stacked layout becomes inconsistent — usually after a multi-drive failure event, sometimes after a partially-completed expand-by-drive-upgrade operation — DSM may refuse to reassemble the array even when most of the underlying data is intact. SHR recovery requires reconstructing the stacked layout correctly off-controller; generic RAID tools that only understand flat mdadm arrays will miss SHR’s layered structure.

btrfs metadata corruption. btrfs is Synology’s default filesystem on DSM 6 and DSM 7 units, and most modern DiskStation deployments are running btrfs. The filesystem’s design assumption is that checksum-validated metadata trees will catch and self-correct corruption; in practice, certain corruption patterns — especially in the metadata trees themselves — can leave the filesystem unmountable even though the data extents are intact. btrfs scrub, btrfs check, and DSM’s filesystem repair tools sometimes fix this and sometimes make it worse. The cases that come to our lab are usually the ones where one of those tools made it worse.

Multiple drive failure beyond fault tolerance. The same condition that takes down standard RAID arrays applies to Synology. SHR, RAID 5, and RAID 10 tolerate one drive loss; SHR-2 and RAID 6 tolerate two. When a second or third failure arrives before a rebuild completes, the storage pool drops to a crashed state. We see this most often on units that have been in service since the original install with the original drive cohort — the first drive failure isn’t a surprise, but the second arriving 48 hours later while the rebuild is mid-flight is what takes the array down. Surviving drives are often only partially failed, which is why cleanroom imaging frequently resurrects enough of a failed-status drive to make recovery possible.

Ransomware on Synology shares. Synology DiskStations have been hit by multiple major ransomware campaigns — SynoLocker in 2014 (which exploited an unpatched DSM vulnerability), eCh0raix starting in 2019, DeadBolt in 2022 (primarily QNAP but also hitting Synology units), and a continuing background of opportunistic ransomware events against internet-exposed DiskStations. The underlying RAID and filesystem are generally intact; the encryption sits at the file level. Recovery options depend on the variant, the time window before encryption completed, whether DSM snapshots existed and were preserved (snapshots are not always reachable by ransomware), and whether Hyper Backup repositories on attached drives or USB media survived the event.

Encrypted Shared Folders. Synology supports per-shared-folder encryption with user-set passphrases. When a customer has enabled encryption on a shared folder, recovery of that folder requires the encryption passphrase or the exported encryption key file. The encryption is real AES-256; the key cannot be recovered from the drives alone. If you’re shipping a unit with encrypted shares, the passphrase or the key file needs to come with it. Without it, even a successful recovery of the underlying storage delivers only encrypted data.

Encrypted Volume (DSM 7.2+ feature). Distinct from per-share encryption, full-volume encryption was added in DSM 7.2. Volume encryption uses a key stored in the DSM system partition and unsealed at boot. If both the system partition and the key escrow have been damaged, the encrypted volume cannot be opened. As with shared-folder encryption, the passphrase or key file is required for recovery.

Drive replacement and rebuild failures. A drive fails on a redundant Synology array. DSM marks the array degraded. The owner inserts a replacement drive and starts a rebuild from the Storage Manager interface. The rebuild reads every surviving sector across the remaining members and copies into the new drive. If a read error appears on a surviving member during the rebuild, the rebuild aborts and the pool can drop to crashed state. The replacement step looks routine in the DSM workflow; in the field it is one of the most common paths to a fully-offline Synology array we receive.

Power surge and unclean shutdown damage. Synology units handle unclean shutdowns reasonably well most of the time, but a sufficient power event — lightning strike, severe brownout, faulty UPS, controller-board-damaging surge — can leave multiple drives flagged as failed, the controller board itself damaged, or both. The pattern we see is “all four drives are red after the storm.” In most cases, only one or two drives have actually failed; the others have been marked failed by DSM as a precaution. Cleanroom evaluation determines which drives are truly failed and which are recoverable.

One pattern worth naming separately. The standard support-engineer instruction on the Synology forums and from Synology Support — for crashed storage pools, system-partition failures, failed migrations, post-upgrade volume crashes, and drive-replacement rebuilds that didn’t complete — tends to be a combination of “run the DSM repair function,” “remove and reinsert the drives in a specific order,” or “create a new storage pool and restore from backup.” Those steps work when the array is healthy underneath. When the underlying condition is multi-drive degradation, btrfs metadata corruption, or a stale-state member that DSM is about to overwrite during a repair attempt, the same steps destroy the data the customer called to save. The real decision in front of a downed Synology is not “Synology Support versus recovery shop” — it is “execute the documented repair now and accept whatever happens” versus “image the drives first and recover before any further DSM-side action.”

How We Recover Synology NAS Arrays

We never operate a failed Synology DiskStation during recovery. Running a degraded array during diagnostic work risks pushing the next drive over the edge, triggering an unwanted DSM data scrub, or letting the unit decide on its own to rebuild against the wrong member. Each drive is removed from the chassis, bay positions documented, and imaged on isolated, write-blocked hardware in our cleanroom. Physically damaged drives are repaired with donor parts as needed before imaging — head replacements, PCB swaps, firmware recovery, and platter burnishing where the surface has been damaged. We work from drive images for everything that follows; the originals stay shelved and untouched.

Once we have a verified image of every drive, our reconstruction work begins. HOMBRE — Gillware’s in-house RAID and filesystem reconstruction software, built and maintained by the engineers who use it — inspects every single sector of every drive image, identifying the Synology-specific partition layout, the mdadm RAID superblocks (including SHR’s layered topology), the LVM volume group structures, and the btrfs or ext4 filesystem above. That sector-by-sector inspection is the key to rebuilding a Synology array without the original DiskStation chassis. We don’t depend on a working DSM to read the data; HOMBRE reads it directly from the drives.

On Synology arrays specifically, HOMBRE understands the stacked mdadm topology that SHR uses, recognizes the version-specific differences between DSM 5, 6, and 7 storage layouts, parses btrfs metadata trees including the snapshot history when present, and reads through filesystem layers without depending on the DSM repair tools. Where snapshots exist on a btrfs volume and the live filesystem state is corrupted, we surface the snapshot history alongside the live state so the cleanest recovery path can be selected. Where encrypted shares or encrypted volumes are involved, we apply the customer-supplied key against the recovered filesystem to deliver decrypted content. Where the storage pool is crashed because of multi-drive failure, we use the partial surfaces from each drive to assemble the most-complete reconstruction available.

The engineers running this work see the failure modes catalogued above on a weekly basis. There is no Synology condition on this page that we are encountering for the first time. HOMBRE assembles the array as a virtual volume from the images, and the filesystem layer above it — btrfs or ext4 — is recovered against the assembled volume. The deliverable is a file list and an outcome you can act on, rather than a DiskStation that’s been talked back into mounting and then expected to keep working.

Related Pages

Synology-specific recovery topics: Crashed Synology storage pool · DS214 flashing blue power light. By NAS brand: WD NAS · QNAP · Buffalo · Drobo · LaCie · FreeNAS / TrueNAS. By RAID level: RAID 5 · RAID 6 · RAID 10. Return to the NAS data recovery hub for the full overview.

Start Your Synology Recovery

If your Synology is offline and the data on it matters, the next step is to power it off and start a free evaluation. Before shipping:

• Power the unit off. Continued boot attempts on a unit with a failing drive cohort or a crashed storage pool can compound the problem.
• Do not run the DSM “Storage Pool Repair” or “Volume Repair” function in an attempt to fix the issue. These can work on cleanly-degraded arrays and can make crashed pools harder to recover.
• Do not run btrfs check, btrfs scrub, or DSM’s filesystem check on a unit where the data matters and you don’t have current backups.
• Do not initialize, reset, or rebuild the storage pool from the Storage Manager. The reset writes new metadata that overwrites the old.
• Do not insert replacement drives into a unit that has dropped its array offline. DSM may attempt an automatic rebuild against the wrong members.
• Do not run a DSM upgrade in an attempt to fix the problem.
• Label each drive with its bay position before removing it from the chassis. Bay order matters for Synology reconstruction.
• Note your DSM version (DSM 5, 6, or 7) and your DiskStation model number. If you’ve enabled encrypted shared folders or encrypted volumes, have the passphrase or key file ready — we cannot recover encrypted data without it.
• Ship the full set of drives together, in original or equivalent anti-static packaging. We don’t need the DiskStation chassis or the power supply.

Open a case or call and you’ll reach our recovery team. The initial scoping call covers feasibility, recovery approach, and turnaround.

Open a Synology recovery case →

Single-bay Synology recoveries (DS115, DS118, DS119j) operate on our standard “no data, no charge” engagement: if the recovery is unsuccessful, you don’t pay for the work. Multi-bay Synology recoveries (any unit with two or more drives in a redundant configuration) carry an engineering deposit to cover the reconstruction work, with the full price disclosed in the quote before you authorize the recovery.

Prefer to talk to someone first? Call 1-877-624-7206 during business hours (M–F 8 am–7 pm, Sat 10 am–3 pm Central), or schedule a 15-minute consultation with a client advisor.