Quick Answer

My Synology says Volume Crashed. What do I do first?

Power the NAS down now and do not click Repair in Storage Manager. Volume Crashed means one of two things: the mdadm software RAID lost too many members, or the Btrfs filesystem on top has a damaged tree root (parent transid verify failed). Repair rebuilds onto the target drive and overwrites the data and historical Btrfs roots that recovery needs. We image every drive, reassemble the SHR/mdadm and LVM stack read-only from the clones, and extract Btrfs or ext4. All work happens at our Austin, TX lab. Free evaluation, no data = no charge.

Synology Volume Crashed Data Recovery

Your DiskStation is showing a red Volume Crashed banner and asking you to repair or reinitialize. Before you touch a single button, power the unit down. We recover crashed Synology volumes through Synology NAS data recovery that separates mdadm software-RAID damage from Btrfs filesystem corruption, because the two failures look identical on screen and need opposite handling. Every drive is cloned through a write-blocker before any analysis begins, and all work happens at our Austin, TX lab. Free evaluation, no data = no charge.

FREE ESTIMATE Mail-In Service

Author01/16

Written by

Louis Rossmann

Founder & Chief Technician

Updated July 2026

15 min read

Two Failures02/16

What Does Volume Crashed Actually Mean?

Volume Crashed is one banner covering two unrelated failures, and DSM does not tell you which one you are looking at. Synology stacks standard Linux layers, and the crash can originate at the software RAID layer or one layer up at the filesystem. Knowing which decides everything that happens next, so the first forensic job is reading the logs and the on-disk metadata, not pressing a button.

Scenario A: mdadm array degraded or superblock corrupt: The mdadm array lost more members than its level tolerates, or the members' superblocks disagree after an unclean shutdown. Each Synology data partition carries an mdadm 1.2 superblock at a 4KB offset recording the RAID level, device order, and event count. When those event counts diverge, mdadm refuses to assemble and the volume reads as crashed at the block layer.
Scenario B: Btrfs tree root damaged after power loss: The array assembles cleanly, but the Btrfs filesystem on top has a broken tree root. The logs show parent transid verify failed: a B-tree node has a generation number that does not match the transaction ID its parent expects, usually after an unexpected power loss or a dropped NVMe write cache. The RAID is healthy; the filesystem will not mount its current root.

The DSM error message is the same in both cases. A lab that treats every Volume Crashed as a RAID problem will force a rebuild on a machine whose RAID was never broken, and finish destroying a filesystem that was one read-only command away from coming back. We test which layer failed before any reconstruction touches the data.

Storage Stack03/16

How Is a Synology SHR Volume Actually Built?

An SHR volume is a stack of standard Linux layers, not proprietary silicon. Synology DiskStation Manager is a Linux distribution, and SHR is a management overlay on top of the same software RAID that has shipped in the Linux kernel since 2001. A healthy array reassembles on a vanilla Linux workstation with no Synology hardware in the loop. Each layer can crash on its own, which is why naming the layer matters.

Volume Crashed: One DSM banner covering two unrelated failures: either the mdadm software RAID lost more parity members than its level can tolerate, or the Btrfs filesystem on top has a damaged tree root after an unexpected power loss. Recovery paths differ; identifying which failure occurred is the first forensic step.
mdadm --assemble --readonly: The command that brings an SHR or standard Linux mdadm array up in read-only mode against write-blocked clone images. It reconstructs the RAID array in RAM without writing a single byte to the physical member drives, which is the distinction between safe forensic assembly and a destructive rebuild.
SHR-1: Synology Hybrid RAID with single-parity redundancy: a RAID 1 mirror on two drives, or RAID 5 on three or more. Tolerates one member loss. Because it uses standard Linux mdadm, a healthy SHR-1 array assembles on any Linux workstation with mdadm --assemble --readonly.
SHR-2: Synology Hybrid RAID with dual-parity redundancy, equivalent to RAID 6. Tolerates two missing members before the array can no longer assemble, versus one missing member for SHR-1 or RAID 5.

1. Physical disks and partitions: Every member drive is partitioned the same way: md0 (a roughly 2.4 GB RAID 1 mirror across every drive holding the DSM operating system and logs), md1 (a RAID 1 swap partition), and md2 and up (the data). Because md0 mirrors across all drives, DSM keeps booting after one drive dies, which can mask how degraded the data array already is.
2. mdadm software RAID: The data partitions are combined into Linux mdadm arrays. SHR is a layout overlay, not proprietary hardware: SHR-1 is a RAID 1 mirror on two drives or RAID 5 on three or more, and SHR-2 is RAID 6. A healthy array assembles with mdadm --assemble --readonly on any Linux box.
3. LVM logical volume: The Storage Pool is an LVM volume group on top of the mdadm device. Mixed-capacity SHR stacks several mdadm arrays across drive-size bands (for example /dev/md2 and /dev/md3) and joins them with LVM into one logical volume, activated with vgchange -ay.
4. Btrfs or ext4 filesystem: The filesystem sits on the logical volume. Btrfs is copy-on-write and keeps a strict metadata hierarchy: superblock, chunk tree, root tree, filesystem tree, extent tree. A broken link anywhere in that chain produces parent transid verify failed and is Scenario B from the previous section.
5. NVMe read/write cache (optional): Cache-equipped prosumer models such as the DS920+, DS1520+, and DS1621+ can add an M.2 NVMe SSD read/write cache. This cache layer logically sits between the LVM logical volume in layer 3 and the Btrfs or ext4 filesystem in layer 4. This is the only optional layer in the stack, which is why the base configuration is four layers and a cache build is five. In writeback mode a written block lands only on the NVMe cache and is flagged dirty until it is flushed down to the SATA array. When the cache SSD drops off the PCIe bus, often because a consumer-grade controller firmware panics under sustained writes, those uncommitted dirty writes are gone for good and the underlying SATA HDD array is left holding an incomplete, out-of-sync Btrfs filesystem that crashes the volume, the Scenario B failure, even when every SATA member is physically healthy. The writes that lived only in the cache are lost, and recovery reconstructs the array's Btrfs read-only to the most recent consistent generation with btrfs-find-root and btrfs restore, never an in-place btrfs check --repair. The model-specific steps for a cache failure live on the DS920+ recovery page.

If a recovery firm tells you SHR is a closed black box only their proprietary tool can read, that is marketing, not engineering. The truth is the opposite: the standard, open nature of the stack is exactly what makes a careful read-only reconstruction possible. The danger is never the format; it is letting the wrong tool write to it.

Events Counter04/16

Why Won't mdadm Reassemble the Array After a Crash?

The usual reason is the mdadm Events counter, a number each member records every time the array completes a successful metadata update. Reading it is forensic, not a guess. mdadm --examine /dev/sdX3 reads the version 1.2 superblock at the 4KB offset on each data partition and prints that member's Events count alongside the RAID level and device order.

When a member drops out (an SMR timeout, an unclean shutdown), its Events counter stops advancing while the surviving members keep writing and incrementing theirs. On the next boot mdadm compares the counts across every member. A drive whose Events count trails its peers is treated as non-fresh and excluded from assembly, because reusing its stale blocks would corrupt the array.

If that exclusion pushes the array past its parity tolerance (one missing member on SHR-1 or RAID 5, two on SHR-2 or RAID 6), the array will not assemble and DSM reports Volume Crashed. The drive itself is usually intact; the array stopped because the freshness check fenced off a lagging member.

The dangerous shortcut is mdadm --assemble --force, which bypasses the freshness check and rewrites the lagging member's Events count up to match the active members. On original customer drives that rewrite is destructive in place and risks Btrfs corruption when stale blocks no longer agree with the tree. It is safe only against write-blocked clone images.

We image first, then read every superblock with mdadm --examine off the clones, reconcile the Events counts offline, and bring the array up with mdadm --assemble --readonly.

Why a DSM Repair Resync Overwrites Data a Read-Only Assembly Never Touches

The destructive part of a rebuild is the md resync, and it happens one layer below the filesystem where most people are looking. When DSM Repair, or a manual mdadm --assemble followed by a resync, brings a degraded SHR or RAID 5 pool back online, the md layer recomputes parity stripe by stripe and writes parity back to the member drives. That write lands on the physical members, not on some scratch area.

Now make the array mathematically inconsistent, which is exactly what a crash does, or let one member throw a read error mid-resync. The md layer recomputes a parity value from the wrong inputs and writes that bad parity over blocks that were still good.

On a copy-on-write Btrfs volume, those overwritten blocks include the historical generation roots a read-only recovery walks back to. The resync does not skip them; it treats them as ordinary stripe data and stamps recomputed parity straight through them.

A read-only virtual assembly off write-blocked clones never writes a single byte to the members. The distinction is precise, not rhetorical: an md resync writes recalculated parity back onto the member devices, while a read-only assembly computes the same logical volume in RAM from clone images and leaves every physical block untouched. That is the entire reason we reconstruct off clones and never resync an original.

SMR Timeouts05/16

Why Did My Synology Eject a Healthy Drive and Crash the Volume?

A volume often crashes because the controller ejected a drive that was never actually dead. The usual culprit is a Shingled Magnetic Recording (SMR) drive, the kind that pretend to behave like normal drives but stall for tens of seconds under sustained writes.

During a rebuild or a scrub, the drive's small Conventional Magnetic Recording cache zone fills up and the drive freezes for 30 to 60 seconds while it reorganizes overlapping shingled tracks.

The Linux kernel does not wait that long. It expects a drive to answer within a short Time-Limited Error Recovery (TLER) window. When the SMR drive goes silent past that window, mdadm reads the silence as a dead member and drops it from the array.

On a single-parity SHR-1 or RAID 5 set that has already lost redundancy, dropping one more member crashes the volume even though the ejected drive is mechanically fine and reads perfectly on a bench.

The other common trigger on prosumer units is an NVMe read/write cache. When a dirty NVMe cache drops off the PCIe bus mid-write, the uncommitted writes are gone and the underlying Btrfs is left with an incomplete transaction, which lands you in Scenario B with a parent transid verify failed root.

In both cases the array members are healthier than DSM thinks, which is exactly why imaging them before any rebuild is the difference between full recovery and loss.

Repair Danger06/16

Should I Click Repair in Synology Storage Manager?

No. The Repair Volume and Auto Repair buttons are presented as safe automated fixes, and on a crashed array they are the single most common reason a recoverable case becomes unrecoverable. Repair triggers a rebuild that reads every sector of the surviving members end to end and writes reconstructed data onto the target drive, which is precisely the wrong thing to do to a degraded set.

Two things go wrong. First, the rebuild has to read marginal drives end to end, and a latent unreadable sector encountered during that full-surface read can crash the array outright with no second parity to fall back on.

Second, the rebuild overwrites the target drive end to end, and if that target is the ejected but mechanically intact member, the write destroys data that was still readable on it, including on a Btrfs volume the historical copy-on-write generation roots that read-only recovery depends on. The buttons do not just risk failure; they actively consume your recovery options.

The same warning applies to the command line. Forum threads routinely tell panicked users to run mdadm --assemble --force to push a degraded array back online.

Force-assembly rewrites the superblock of a surviving member to match the stale state of the others, which can destroy the one good copy of the metadata you needed. We read superblocks off write-blocked clones and reconcile them offline instead.

Recovery Tools07/16

Can photorec or testdisk Recover a Crashed Synology Volume?

photorec and testdisk are open-source tools that scan raw block devices for file signatures (file carving). They can recover files from damaged filesystems, but they carry real risks when run against live or degraded arrays. Running them directly on a degraded array can trigger additional reads that stress failing drives and provoke mdadm to attempt resync operations.

photorec scans raw sectors for known file headers (JPEG, PDF, DOCX, etc.) and extracts files regardless of filesystem state. It does not preserve filenames or directory structure.
testdisk analyzes partition tables and can sometimes rebuild a damaged partition map or recover a deleted partition.
On Btrfs, file carving with photorec is less effective because copy-on-write scatters file extents across the device. Large files are often fragmented in ways that photorec cannot reconstruct.

Image first, scan second. Running recovery tools directly on a degraded array can trigger additional reads that stress failing drives, cause rapid mechanical degradation of weak read/write heads, or provoke mdadm to attempt resync operations. For irreplaceable data, create write-blocked images of every drive using ddrescue before running photorec, testdisk, or any other scanning tool. Work from the images, not the source drives.

The mechanism is worth spelling out. Running photorec directly on a live md device of a degraded SHR array issues sustained sequential reads across every surviving drive. A drive that is already reporting SMART warnings can develop additional bad sectors under that read load. mdadm then kicks the drive from the array entirely, and a single-drive degraded failure escalates to a double-drive failure. This is why imaging precedes scanning.

Btrfs Roots08/16

My Synology Says parent transid verify failed. How Is That Recovered?

That message means the RAID is fine and the Btrfs filesystem on top has a damaged tree root, so the recovery is a filesystem job, not a RAID job. Btrfs is copy-on-write: it never overwrites a metadata block in place, it writes the new version elsewhere and updates a pointer. That design is the reason older, consistent versions of the metadata trees usually still survive on disk after a crash, because nothing erased them.

The correct response is to walk back to one of those earlier generation roots and read from it. btrfs-find-root locates the historical roots by generation number, and btrfs restore extracts files against a chosen root without ever writing to the volume. We run both against a write-blocked image, so the original drives are never modified and we can try multiple generation roots until the directory tree comes back clean.

What we never do is run btrfs check --repair. That command writes new metadata in place, and the in-place write is exactly what destroys the surviving historical roots. The same goes for a forced read-write mount.

Every Btrfs step we take is read-only, because on a copy-on-write filesystem the survivors are the whole point. The same read-only generation-root method drives our wider Btrfs filesystem recovery work, regardless of whether the volume sat on a Synology or a bare Linux host.

Rebuild Math09/16

Can Data Be Recovered After a Failed Synology Rebuild?

Frequently, but not by rebuilding again, because the math that crashed the rebuild has not changed. A rebuild on a degraded SHR-1 or RAID 5 array must read every surviving member end to end to recompute the missing data. Consumer drives carry a worst-case rating of one unrecoverable read error per 10 to the 14th bits read, which works out to roughly 12.5 TB.

That figure is a warranty floor, not a schedule: most drives read far past it without a single error. But on a large array the cumulative read of a full rebuild raises the odds of striking a latent unreadable sector on a surviving member, and on a single-parity set there is no second parity to reconstruct that stripe.

The controller hits the error, cannot continue, and aborts, which is why a rebuild that was supposed to heal the array instead finishes it off. This is not a hypothetical; it is the documented physics behind RAID data recovery on every modern array.

The safe path is to never recompute parity on the originals. We image each member with ddrescue, PC-3000 Portable III, or DeepSpar Disk Imager first, then reconstruct the array virtually from the clones, where a read error costs nothing and the physical drives are never written.

Where the array geometry has to be rediscovered, we reconstruct it with Data Extractor Express RAID Edition on the cloned images. A redundant array buys you uptime, not a backup; once redundancy is gone, the only safe move is imaging.

Migration Risk10/16

Is It Safe to Move My Crashed Drives Into a New DiskStation?

Only if the original failure was a dead power supply or a broken chassis, which a crashed volume usually is not. Moving the drives works when the disks and their metadata are intact and only the box died. It is disastrous when the crash came from metadata corruption, because the new unit will try to take ownership of the drives.

When you insert crashed drives into a new Synology and choose Migrate or Repair, DSM rewrites the md0 system partition and attempts a forced import of the arrays. If the array metadata is damaged, that import fails, and DSM then commonly offers a fresh install that permanently overwrites the data partitions.

The metadata needed to reconstruct the volume is small, specific, and irreplaceable, and these migration workflows are exactly what overwrites it. Power off, label each drive by its bay number, and image before anything else reads or writes the disks.

DSM 6.x vs 7.x11/16

How Do DSM 6.x and 7.x Differ in Volume Crash Behavior?

The DSM version running on the NAS changes what the user sees when a volume fails and what DSM will do on its own after a reboot. DSM 7.x added automated storage pool repair that can begin a rebuild without user confirmation, converting a degraded state into a Volume Crashed state on marginal hardware.

DSM 6.2 ships mdadm 3.4-era utilities. Degraded storage pools require an explicit Repair click in Storage Manager. The OS does not start a rebuild on its own.
DSM 7.0 and later add an automated pool repair workflow on supported models. After a reboot with a replacement drive inserted, DSM can begin resync without user confirmation. On healthy hardware this is convenient; on a degraded array with a marginal SMR drive, it can turn a degraded state into a crashed state.
DSM 7 also introduced the Storage Pool 2.0 layout on newer units. The partition offsets for the data array changed from partition 3 to different offsets on some models, so diagnostic commands that worked on DSM 6 (mdadm --examine /dev/sdX3) may need to target a different partition on DSM 7.
Btrfs support is mandatory for Snapshot Replication in DSM 7; more DSM 7 volumes use Btrfs than DSM 6 volumes did. Btrfs metadata damage after a power loss is a more common failure mode on DSM 7 units as a result.
DSM 7.2 added full-volume LUKS encryption (aes-xts-plain64) managed by an Encryption Key Vault, which introduces an additional cryptographic failure mode on a crashed volume on top of the mdadm and Btrfs layers. The LUKS header at offset 0 and the wrapped key in the vault change the safe recovery sequence, covered on the encrypted Synology volume recovery page.

If the unit runs DSM 7 and shows any degraded or warning status, power it off before the next scheduled reboot. Auto Repair can be disabled under Storage Manager settings, but it ships enabled by default; an auto-resync onto a marginal drive is a common cause of degraded-to-crashed escalation during unattended overnight reboots.

Process12/16

How Do You Recover a Crashed Synology Volume?

We image every member through a hardware write-blocker, identify whether the failure is at the mdadm layer or the Btrfs layer, reassemble the SHR/mdadm and LVM stack read-only 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 can end the recovery.

Free evaluation: We document the model, the DSM error state and logs, the SHR or RAID level, the filesystem, and whether the crash sits at the mdadm or Btrfs layer. There are no diagnostic fees and this triage decides the recovery path.
Write-blocked imaging: Each member is cloned with ddrescue, PC-3000 Portable III, or DeepSpar. Marginal and SMR drives get conservative retry profiles so imaging captures the maximum without accelerating wear, and the originals are never written.
Superblock analysis: We read the mdadm 1.2 superblocks at the 4KB offset off the clones, reconcile device order and the most recent consistent event count, and determine stripe size and parity rotation. Where geometry must be rediscovered we use Data Extractor Express RAID Edition against the images.
Read-only array assembly: We assemble the array with mdadm --assemble --readonly and activate the LVM volume group with vgchange -ay, never touching the physical drives.
Filesystem extraction: For a healthy filesystem we mount it read-only and copy the data. For a damaged Btrfs tree we work read-only with btrfs-find-root and btrfs restore against historical generation roots, never an in-place repair, because copy-on-write means in-place repair destroys the older roots that recovery depends on.
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.

The same reconstruction logic applies whether the crash was at the RAID layer or the filesystem layer, and whether the chassis is a two-bay or an eight-bay. A crashed Synology volume is one slice of the wider NAS data recovery work we handle, and the member-by-member imaging mirrors any single hard drive data recovery case we run.

If the crashed volume was also encrypted, reassembling the array is only the first step. Decryption additionally requires the volume key material: the eCryptfs or LUKS wrapped key, specifically the .wkey file on the Btrfs volume and the machine.key on the synoboot partition. Without it the reassembled array yields ciphertext, which is why encrypted Synology volume recovery is its own process.

Reconciling LVM Metadata Across a Mixed-Capacity SHR

A mixed-capacity SHR is not one md array, and treating it like one is how a partial recovery happens. To use the unequal space on, say, a 4 TB plus two 8 TB build, DSM carves the drives into capacity bands and builds a separate standard mdadm array on each band, the md2 and md3 arrays named in the storage-stack section above. It then joins those arrays with Linux LVM into one volume group, named vg1000, with a single logical volume on top carrying the Btrfs or ext4 filesystem.

When the volume crashes, the LVM physical-volume and volume-group descriptors can desync across those bands. Assemble only one md band and the LVM layer sees an incomplete volume group, so the logical volume will not activate and the filesystem never appears, even though every drive imaged cleanly. The fix is to rebuild the LVM layer against the cloned images, not against the originals.

We scan the assembled clone arrays for physical volumes and reread the group descriptors with pvscan, restore the vg1000 group metadata from its on-disk backup with vgcfgrestore, and only then activate the logical volume with vgchange -ay. Every step runs against images, so a desynced descriptor on one band can be reconciled without ever writing LVM metadata back to a physical member.

When the Superblocks Are Gone: Geometry From Content, Not Metadata

The worst case is a member whose mdadm 1.2 superblock has been zeroed or corrupted. With no superblock, mdadm --examine returns nothing and the native RAID parameters are gone, so the array cannot be assembled by mdadm at all. A force assembly has nothing to act on. The geometry has to be rediscovered from the data itself.

We read the cloned images at the block level and run hex-level content analysis: locate filesystem and metadata signatures across the members, and from where each signature lands derive the RAID role, the member order, the chunk size, and the parity rotation. With those parameters recovered we de-stripe the array virtually from the clones.

This is the genuine ACE Lab array tool, Data Extractor Express RAID Edition on the PC-3000, doing reconstruction software work that stays separate from the imaging stage and never writes to a physical drive.

iSCSI LUNs13/16

What If My Crashed Synology Was Hosting iSCSI Targets?

A Synology iSCSI LUN is not a physical partition on the drives; it is a sparse file named EP_DAT_00000 sitting inside a hidden @iSCSI/EP/ directory on the same Btrfs or ext4 volume the rest of this page reconstructs. That single fact decides the whole recovery, because the LUN cannot be reached until the volume underneath it is back, read-only.

The dependency runs one direction only. The same read-only SHR/mdadm and LVM reassembly and Btrfs or ext4 extraction described in the sections above has to complete first, on cloned images, before the @iSCSI directory and the EP_DAT_00000 file are even visible. The layers stack like this:

1. mdadm RAID set: The member partitions assemble read-only with mdadm --assemble --readonly off the clones, exactly as for a non-iSCSI crash.
2. LVM volume group: The volume group is activated with vgchange -ay against the assembled array, never against the original drives.
3. Btrfs or ext4 host filesystem: The host filesystem is traversed read-only. On a crashed Btrfs tree that means btrfs-find-root and btrfs restore against a historical generation root, which is what surfaces the @iSCSI/EP/ directory.
4. The EP_DAT sparse-file container: EP_DAT_00000 is extracted as a file from the recovered host filesystem. It is the LUN, stored as one large sparse file, not a block device on the disks.
5. The mounted block device: The extracted file is attached as a loop device with losetup -P, which scans the partition table the initiator wrote and exposes each partition as its own device. Mounting that partition device finally surfaces the initiator-side filesystem inside, typically NTFS or ext4.

If the Btrfs extents physically holding the EP_DAT_00000 file are damaged, the file itself is imaged with ddrescue across the bad extents before it is mounted, so a few unreadable blocks inside the container do not abort the whole extraction. The work is the same forensic Btrfs filesystem recovery that drives the rest of this page, with one extra unwrapping step at the end.

Two pieces of forum lore get this wrong. The first says an iSCSI LUN is a physical partition you can carve straight off the member disks; it is not, because the LUN only exists as a file inside a host filesystem that has to be reconstructed first.

The second says a LUN can be recovered on its own without rebuilding the underlying array; it cannot, because there is no LUN to read until the SHR/mdadm, LVM, and Btrfs or ext4 layers below it are reconstructed.

RTO and RPO14/16

What Are Realistic RTO and RPO Numbers for Synology Recovery?

Businesses planning around a Synology failure need realistic numbers for Recovery Time Objective (RTO: how long until data is back in hand) and Recovery Point Objective (RPO: how much recent data is lost). The physics of sector-by-sector imaging set hard lower bounds that no amount of rush fee can compress.

Imaging time: ddrescue on a healthy 4 TB drive runs at roughly 120 to 180 MB/s sustained; a full pass is 6 to 10 hours. A drive with read errors runs 10x slower on the affected zones. Expect 1 to 2 calendar days to image a 4-bay SHR-1 with mixed drive health.
Array and filesystem work: mdadm reassembly from images, Btrfs or EXT4 mount testing, and file extraction add 4 to 12 hours for a healthy-metadata case; 1 to 3 days if the filesystem requires block-level carving.
Head swaps: If a drive has a failed head stack, allow 3 to 7 days per drive for donor sourcing, physical transplant, and adaptive re-imaging. Multiple bad drives extend this in parallel rather than serially.
Typical RTO: 3 to 7 calendar days for a healthy-drive SHR-1 recovery; 10 to 21 days for cases involving head swaps, severe Btrfs metadata damage, or large arrays (6 drives and up). The optional rush fee (+$100 rush fee to move to the front of the queue) moves a case to the front of the queue but does not change imaging throughput.
RPO: Snapshot replication (DSM 7) or Hyper Backup to a second device is the only way to reduce RPO below the last scheduled backup window. On-NAS snapshots survive a Btrfs volume crash only if the snapshot metadata is independently intact, which is not guaranteed. Treat the NAS itself as a single failure domain when planning RPO.

For business-critical arrays, pair the NAS with an offsite RAID backup target running a different filesystem and hardware generation so that a single firmware or controller bug cannot take down both copies at once.

Pricing15/16

What Does Volume Crashed Recovery Cost?

Crashed Synology recovery uses two line items: a per-member price based on each drive's physical and firmware condition, plus a single array reconstruction fee for the SHR/mdadm, LVM, and filesystem work. If we recover nothing usable, 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, billed per evaluated drive. A four-bay unit with one head-swap member and three logical-only members generates an individual line item for each evaluated drive, not a single opaque bundle.

Low complexity
Simple Copy
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$100
3-5 business days
Low complexity
File System Recovery
Your drive isn't recognized by your computer, but it's not making unusual sounds
File system corruption. Accessible with professional recovery software but not by the OS
Starting price; final depends on complexity
From $250
2-4 weeks
Medium complexity
Firmware Repair
Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond
Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access
CMR drive: $600. SMR drive: $900.
$600–$900
3-6 weeks
High complexity
Most Common
Head Swap
Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
$1,200–$1,500
4-8 weeks
High complexity
Surface / Platter Damage
Your drive was dropped, has visible damage, or a head crash scraped the platters
Platter scoring or contamination. Requires platter cleaning and head swap
50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.
50% deposit required
$2,000
4-8 weeks

Hardware Repair vs. Software Locks

Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.

No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.

Rush fee: +$100 rush fee to move to the front of the queue
Donor drives: Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.

The prices above are for standard hard drives, which covers most jobs. Helium-sealed drives (for example WD or HGST Ultrastar He and Seagate Exos X) must be resealed and refilled with helium in-house after the chamber is opened, so they price higher, in the $200–$5,000+ range. See helium drive pricing.

Array Reconstruction Fee

The array reconstruction fee is $400-$800. It covers SHR/mdadm parameter detection, superblock reconciliation, LVM reconstruction, virtual assembly from cloned images, and Btrfs or ext4 extraction including read-only generation root recovery. The final figure within that range depends on member count, RAID level, and mixed-capacity SHR complexity, and is confirmed at the free evaluation alongside the per-member line items.

No Data = No Charge. If we cannot recover usable data from your crashed Synology, you owe nothing under our no-fix-no-fee guarantee. There are no diagnostic fees. A rush fee of $100 moves a case to the front of the imaging queue. Optional return shipping is the only other potential cost on an unsuccessful case.

Faq16/16

What Are the Most Common Synology Volume Crashed Questions?

What does Volume Crashed mean on a Synology?

Volume Crashed is DSM telling you it can no longer present the volume, but it lumps two different failures under one banner. Either the mdadm software RAID lost more parity members than the level can tolerate and the array will not assemble, or the array is fine and the Btrfs filesystem on top of it has a damaged tree root after an unexpected power loss, which shows up as parent transid verify failed in the logs. The recovery path is different for each, so the first job is identifying which one you have before anyone touches the drives.

Should I click Repair in Synology Storage Manager after a volume crash?

No. Repair Volume triggers a rebuild that reads every sector of the surviving members end to end and writes reconstructed data onto the target drive. On a degraded array a single unrecoverable read error during that full-surface read can crash the volume outright, and the rebuild overwrites the target drive, destroying whatever was still readable on it including the historical Btrfs copy-on-write roots that recovery depends on if the ejected drive is reused. Repair is the most common reason a recoverable Synology becomes unrecoverable. Power the unit down and image first.

Can I pull the drives out of my dead Synology and read them on a Linux PC?

Often yes, because SHR is not proprietary. It is standard Linux mdadm aggregating drive partitions into RAID 1 or RAID 5 sets, LVM joining those into one volume group, and Btrfs or ext4 on top. A healthy array assembles on a vanilla Linux workstation with mdadm --assemble --readonly followed by vgchange -ay. The danger is doing this on the original drives. Read-only on imaged clones is safe; assembling the originals read-write, or letting a new NAS Migrate or Repair them, can overwrite the metadata you need.

Why did my Synology eject a healthy drive and crash the volume?

This is usually an SMR drive timeout. Shingled drives such as some WD Red models keep a small CMR cache that overflows during the sustained sequential writes of a rebuild or scrub. When the cache fills, the drive stalls for 30 to 60 seconds while it reorganizes shingled tracks. That stall exceeds the TLER window the Linux kernel expects, so mdadm reads the silence as a dead drive and ejects it. The drive is physically fine; the array crashed because of a timeout, not a head crash.

What is mdadm superblock corruption and how does it crash a Synology volume?

Every Synology data partition carries an mdadm 1.2 superblock at a 4KB offset that records the RAID level, member count, device order, and event count. If that superblock is damaged or its event counts diverge across members after an unclean shutdown, mdadm refuses to assemble the array and DSM reports Volume Crashed. The fix is forensic, not a button: read the superblocks off write-blocked clones, reconcile device order and the most recent consistent event count, and assemble a read-only virtual array. Running mdadm --assemble --force on the originals can overwrite a surviving member's superblock.

What if the mdadm superblock is gone, not just out of sync?

Then mdadm cannot help you, and the recovery shifts from reading metadata to deriving it. If a member's mdadm 1.2 superblock is zeroed or corrupt, mdadm --examine returns nothing and the native RAID parameters (level, member order, chunk size, parity rotation) are lost, so the array cannot be assembled by mdadm at all. We move to content analysis instead: read the cloned images at the block level, find filesystem and metadata signatures, and from where those signatures land derive each drive's RAID role, the member order, the chunk size, and the parity rotation. With those parameters recovered we de-stripe the array virtually. This is the genuine ACE Lab array tool, Data Extractor Express RAID Edition running on the PC-3000, working entirely against clone images so nothing is written to the original drives.

Why does assembling my mixed-capacity SHR give an incomplete or missing volume?

Because a mixed-capacity SHR is not a single array. DSM splits the unequal drives into capacity bands, builds a standard mdadm array on each band (the md2 and md3 arrays), and joins them with LVM into one volume group named vg1000 with a single logical volume on top. When the volume crashes, the LVM physical-volume and volume-group metadata can desync across the bands, so assembling only one md band yields an incomplete volume group and the logical volume will not activate. We reconcile the LVM layer against the cloned images: scan for physical volumes and reread the group descriptors with pvscan, restore the vg1000 group metadata from its on-disk backup with vgcfgrestore, then activate the logical volume with vgchange -ay. None of it touches the original drives.

My Synology says parent transid verify failed. What is that?

That message means the RAID assembled fine but the Btrfs filesystem on top has a broken tree root. Btrfs is copy-on-write and keeps a hierarchy of metadata from the superblock down through the chunk tree, root tree, and filesystem tree. When a power loss or a dropped NVMe write cache interrupts a transaction, a B-tree node ends up with a generation number that does not match what its parent expects, and Btrfs will not mount the current root. Recovery means walking back to an earlier consistent generation root with btrfs-find-root and extracting with btrfs restore, never btrfs check --repair.

Will btrfs check --repair fix my crashed Synology volume?

It is far more likely to finish the job the crash started. Btrfs is copy-on-write, which means older, consistent versions of the metadata trees usually still survive on disk after a crash precisely because nothing overwrote them. btrfs check --repair writes new metadata in place, and that in-place write is exactly what destroys those surviving historical generation roots. Professional Btrfs recovery stays read-only: btrfs-find-root locates the older roots and btrfs restore extracts files against them. We never run an in-place repair on a customer volume.

Can data be recovered after a failed Synology RAID rebuild?

Frequently, but not by rebuilding again. A rebuild on a degraded SHR-1 or RAID 5 array has to read every surviving member end to end. Consumer drives carry a worst-case rating of one unrecoverable read error per 10 to the 14th bits, roughly 12.5 TB read, and that is a warranty floor rather than a schedule. On a large array the rebuild can hit a latent unreadable sector with no second parity to reconstruct it, and abort. We image every member first, then reconstruct parity against the clones offline where a read error costs nothing and the originals are never written.

Is it safe to move my crashed Synology drives into a new DiskStation?

Only if the crash was a dead power supply or a failed chassis, which it usually is not. If the volume crashed because of metadata corruption, moving the drives into a new unit and choosing Migrate or Repair tells DSM to rewrite the md0 system partition and force-import the arrays. When that import fails, DSM commonly offers a fresh install that permanently overwrites the data partitions. The metadata needed to reconstruct the volume is small and irreplaceable, and these workflows are exactly what overwrites it. Image first, experiment never.

Do I need to send all the drives from my Synology, or just the failed one?

Send every drive from the chassis, in their bay order if you can label them. SHR-1 and RAID 5 tolerate one missing member, so the array can be reconstructed with a single drive absent, but every additional drive you provide widens the margin and improves the odds of a complete recovery, including the ones DSM marked as failed. A drive the controller ejected for an SMR timeout is often the most intact disk in the set. We image each member individually and reconstruct the array virtually from the clones, so a single missing drive can still be the difference between a full recovery and an incomplete one.

How much does Synology Volume Crashed recovery cost?

Two line items. Each member drive is priced against the same five-tier hard drive schedule by its physical and firmware condition, from a simple logical case up to a head swap, billed per evaluated drive. On top of that is a single array reconstruction fee that covers SHR/mdadm parameter detection, LVM reassembly, and Btrfs or ext4 extraction. There are no diagnostic fees and the evaluation is free. If we recover nothing usable, you owe nothing under our no-fix-no-fee guarantee.

Where is the recovery work performed and do you offer mail-in service?

All work is performed in-house at our lab at 2410 San Antonio Street, Austin, TX 78705. We are a single location with no franchises and no outsourcing. Nationwide service is mail-in: power the unit down, label the drives by bay number, pack them so the platters are protected, and ship them in. We image every member through a write-blocker on arrival and confirm the per-member and array reconstruction figures at the free evaluation before any chargeable work starts.

What if my crashed Synology volume was hosting iSCSI targets?

A Synology iSCSI LUN is not a partition on the drives. It is a sparse file named EP_DAT_00000 inside a hidden @iSCSI directory on the Btrfs or ext4 volume, so it cannot be read until that volume is back. We rebuild the SHR/mdadm and LVM stack read-only from cloned images and extract the host filesystem first, which is the only thing that surfaces the @iSCSI directory and the EP_DAT_00000 file. We then attach the recovered file with losetup -P so the partition table the initiator wrote is scanned, and mount the exposed partition device to reach the inner NTFS or ext4. If the Btrfs extents holding the file are damaged, we image the file itself with ddrescue before mounting it.

Data Recovery Standards & Verification

Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.

Validated Clean Zone

Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.

Transparent History

Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.

Media Coverage

Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.

Aligned Incentives

Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.

Technical Oversight

Louis Rossmann

Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.

We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.

See our clean bench validation data and particle test video

No Data, No Fee

Guarantee

2.49M+

Subscribers

4.9

1,837+ Google Reviews

Since 2008

Established

Repairs on Video

Full Transparency

As Featured In