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.
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
mdadmarray 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.
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.
- 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), andmd2and 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 --readonlyon 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/md2and/dev/md3) and joins them with LVM into one logical volume, activated withvgchange -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 failedand is Scenario B from the previous section.
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.
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 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.
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.
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.
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.
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.
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 --readonlyand activate the LVM volume group withvgchange -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-rootandbtrfs restoreagainst 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.
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 --readonlyoff the clones, exactly as for a non-iSCSI crash. - 2. LVM volume group
- The volume group is activated with
vgchange -ayagainst 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-rootandbtrfs restoreagainst a historical generation root, which is what surfaces the@iSCSI/EP/directory. - 4. The EP_DAT sparse-file container
EP_DAT_00000is 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.
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.
What Are the Most Common Synology Volume Crashed Questions?
What does Volume Crashed mean on a Synology?
Should I click Repair in Synology Storage Manager after a volume crash?
Can I pull the drives out of my dead Synology and read them on a Linux PC?
Why did my Synology eject a healthy drive and crash the volume?
What is mdadm superblock corruption and how does it crash a Synology volume?
My Synology says parent transid verify failed. What is that?
Will btrfs check --repair fix my crashed Synology volume?
Can data be recovered after a failed Synology RAID rebuild?
Is it safe to move my crashed Synology drives into a new DiskStation?
Do I need to send all the drives from my Synology, or just the failed one?
How much does Synology Volume Crashed recovery cost?
Where is the recovery work performed and do you offer mail-in service?
What if my crashed Synology volume was hosting iSCSI targets?
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.
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 videoRelated services
Related Recovery Services
Volume Crashed, Storage Pool Degraded, SHR reconstruction, and Btrfs/EXT4 recovery for all DiskStation and RackStation models.
Recovery for all NAS brands including QNAP, Buffalo, Western Digital, and Asustor.
Hardware and software RAID array reconstruction for RAID 0, 1, 5, 6, and 10.
Individual HDD recovery From $100. Head swaps, firmware rebuilds, and platter imaging.
Copy-on-write tree-root recovery with btrfs-find-root and btrfs restore, never an in-place repair.
Decrypting a reassembled SHR volume with the .wkey and machine.key material, eCryptfs and DSM 7.2 LUKS.
Synology showing a Volume Crashed banner?
Free evaluation. No data = no charge. Ship your drives from anywhere in the U.S.