My Synology says Volume Crashed. What do I do first?
Power the NAS down now and don't click Repair in Storage Manager. Synology gives two main causes of a crashed volume. One is drive problems, like the mdadm software RAID losing too many members. The other is file system errors, like a damaged Btrfs tree root, which shows up as parent transid verify failed. 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 recovery fee.
Synology Volume Crashed Data Recovery
Your DiskStation is showing a Volume Crashed banner. Before you touch a single button, power the unit down. We recover crashed Synology volumes. As part of our Synology NAS data recovery, we separate mdadm software-RAID damage from Btrfs filesystem corruption. We clone every drive through a write-blocker before any analysis starts, and all work happens at our Austin, TX lab. Free evaluation, no data, no recovery fee.
What Does Volume Crashed Actually Mean?
Synology gives two main causes of a crashed volume: drive problems and file system errors. A Synology volume is a stack of standard Linux layers, and the crash can start at the software RAID layer or one layer up at the filesystem. Which one failed changes everything we do next. So the first job is reading the logs and the metadata on the disks, 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 a member's event count trails the others, mdadm leaves that member out. If too few members are left, the array won't 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. That means a B-tree node has a generation number that doesn't match the transaction ID its parent expects. It happens after an unexpected power loss or a dropped NVMe write cache. The RAID is healthy. The filesystem won't mount its current root.
We find out which layer failed before any reconstruction touches the data.
Both scenarios assume DSM booted and read the storage stack at all. If the unit never finishes starting up and the power LED keeps blinking blue instead of going solid, DSM never loaded, and you cannot tell Scenario A from Scenario B until the members are read outside the chassis.
If that boot failure is a chassis fault in the motherboard or the power supply, the SATA members and their mdadm arrays stay intact behind the dead unit. A dying member that hangs POST puts the fault back inside the storage stack. Separating a dead chassis from a dead array is the first fork in NAS recovery triage, and on a Synology blinking blue light unit it sends the members to an offline read rather than the volume to a repair.
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 ships in the Linux kernel. 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. Our Synology SHR hybrid RAID recovery walkthrough breaks down how the mdadm, LVM, and Btrfs or ext4 layers degrade, why a rebuild can eject a healthy drive, and how the stack is reconstructed read-only.
- Volume Crashed
- The DSM status for a crashed volume. Synology gives two main causes. One is drive problems, like the
mdadmsoftware RAID losing more members than its RAID level can tolerate. The other is file system errors, like a damaged Btrfs tree root after an unexpected power loss. Each takes a different recovery, so the first thing we do is find out which one happened. 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 withmdadm --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
- Member drives carry
md0, the RAID 1 system mirror that holds the DSM operating system and logs, and data partitions frommd2up. A mixed-capacity SHR adds partitions, so the layout isn't identical on every drive. On most models md0 mirrors across every drive, which is why DSM keeps booting after one drive dies. - 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 builds several mdadm arrays across drive-size bands, for example
/dev/md2and/dev/md3. LVM joins them into one volume group, andvgchange -ayactivates it. The volume group's name and how many logical volumes it holds depend on the layout. - 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. - 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. 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, those uncommitted dirty writes are gone for good. The SATA HDD array underneath is left holding an incomplete, out-of-sync Btrfs filesystem. That crashes the volume as a 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-rootandbtrfs restore, never an in-placebtrfs 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.
Why Won't mdadm Reassemble the Array After a Crash?
One reason is the mdadm Events counter. Each member keeps that count, and it goes up every time the array completes a successful metadata update. You don't have to guess at it. mdadm --examine 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 array stopped because mdadm's freshness check left a lagging member out.
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 rebuilds the missing member from parity, stripe by stripe. Then it writes the result onto the replacement drive. That's a real write to a physical drive, not to some scratch area.
A read-only virtual assembly off write-blocked clones never writes a single byte to the members. A degraded rebuild writes the rebuilt member onto the replacement drive. A read-only assembly computes the same logical volume in RAM from clone images and leaves every physical block alone. That's why we reconstruct off clones and never resync an original.
Why Did My Synology Eject a Healthy Drive and Crash the Volume?
Sometimes a volume crashes because the controller ejected a drive that was never actually dead. One cause is a Shingled Magnetic Recording (SMR) drive. SMR drives pretend to be normal hard drives, but they stall for tens of seconds under sustained writes.
During a rebuild, 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 doesn't wait that long. When the SMR drive goes silent, 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.
An NVMe read/write cache on a prosumer unit is another trigger. 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.
Should I Click Repair in Synology Storage Manager?
No. Repair triggers a rebuild that reads every sector of the surviving members end to end and writes reconstructed data onto the target drive.
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 has no second parity to fall back on, so the data in that stripe is gone.
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 tell panicked users to run mdadm --assemble --force to push a degraded array back online.
That command writes metadata to the original members, as the events-counter section above describes. We read superblocks off write-blocked clones and reconcile them offline instead.
Repair Only Exists for a Degraded Pool, Not a Crashed One
DSM doesn't offer the button in every state. SHR-1 and RAID 5 survive one missing member, and SHR-2 and RAID 6 survive two.
| Degraded Pool | Crashed Volume | |
|---|---|---|
mdadm array and data | Still assembles. The data is still readable with reduced redundancy. | If drives caused the crash, too few members remain for mdadm to assemble the array. |
| Repair button in DSM | Offered. It only shows up when the pool is degraded. | Not offered. Synology says you can't repair a crashed pool yourself. |
| What Repair or a resync acts on | Resyncs parity onto a replacement drive, which is the job it was built for, though that resync still reads every surviving member end to end and a single unrecoverable read error on a single-parity set has no second parity to cover it. | If drives caused the crash, there's no running array left for a repair or a resync to work on. |
Can photorec or testdisk Recover a Crashed Synology Volume?
photorec and testdisk are open-source tools. 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 drives sustained reads across drives that are already marginal.
- 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.
Image first, scan second. Running recovery tools directly on a degraded array puts sustained read load on failing drives. 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.
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. This is why imaging precedes scanning.
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 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?
Not by rebuilding again. The math that crashed the first rebuild hasn't 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's a worst-case number from the manufacturer's specification, not a schedule, and real-world drives often do far better. 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. On a single-parity set there's no second parity to reconstruct that stripe.
mdadm logs the unreadable block and carries on, but the data in that stripe is gone, which is why a rebuild that was supposed to heal the array instead hands it back with holes.
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.
Parity depth and member count change the arithmetic; they don't change the conclusion. SHR-1 is single parity, a RAID 1 mirror on a two-drive capacity band and a RAID 5 set on bands of three or more drives, so it carries the same single-parity exposure that makes a degraded RAID 5 rebuild dangerous.
SHR-2 carries a second parity block like RAID 6 and tolerates two missing members before the array stops assembling. A wider pool in an enterprise Synology chassis adds imaging line items, and every member still gets imaged before anything recomputes parity.
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. 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 Does DSM 7.2 Volume Encryption Change a Crashed-Volume Recovery?
DSM 7.2 added full-volume LUKS encryption (aes-xts-plain64) managed by an Encryption Key Vault, which puts a cryptographic failure mode on a crashed volume on top of the mdadm and Btrfs layers. The wrapped key in the vault changes the safe recovery sequence, covered on the encrypted Synology volume recovery page.
Is Your Volume Crashed, or Locked After a DSM Update?
Ask that before anything else. A crashed volume is a block-layer or filesystem problem on the disks, at the mdadm or Btrfs layer. A locked volume is one where DSM won't open the LUKS container, because the Encryption Key Vault that holds its key wasn't available.
Synology dates DSM 7.4.1-90080 to 2026-07-23 and states in the release notes for it that "KMIP client authentication now requires certificates issued by a private CA", with Synology default certificates, the QuickConnect certificate, and public-CA certificates no longer accepted for that authentication. It reaches the units whose vault authenticates to a remote key server; a vault kept locally on the unit is not doing KMIP client authentication at all.
Rolling the firmware back is not on the table either, since Synology attaches this to the release: "After installing this update, you will not be able to downgrade to a previous DSM version." Synology documents that manual unlocking is required when the key vault is unavailable, so the work sits on the certificate and key side, covered on the DSM 7.2 key vault and .rkey unlock page.
A locked banner tells you what DSM did, not what shape your array is in. Whether the members read clean, whether the mdadm superblocks agree, and whether the LVM headers still describe the volume are questions the banner does not answer. We settle them on the bench: image every member first, assemble the SHR/mdadm and LVM stack read-only from the clones, then work the key question against those images. Running a repair or a migration to clear the banner writes fresh metadata onto the disks and can take out the layer you still need.
How Do You Recover a Crashed Synology Volume?
We image every member through a 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. We never modify your original drives. Don't treat these steps as a do-it-yourself procedure. One 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: We clone each member through a write-blocker with
ddrescue, a PC-3000 Portable III, or a DeepSpar Disk Imager. Marginal drives get conservative retry profiles, and we never write to the originals. - 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.
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. Decrypting it also needs the volume key material. Without that, the reassembled array gives you ciphertext, which is why encrypted Synology volume recovery is its own process.
Assembling One md Band Leaves a Mixed-Capacity SHR Volume Group Incomplete
A mixed-capacity SHR isn't 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. It then joins those arrays with Linux LVM into one volume group.
Assemble only one md band and the LVM layer sees an incomplete volume group, so the logical volume won't activate and the filesystem never appears, even though every drive imaged cleanly.
When the Superblocks Are Gone: Geometry From Content, Not Metadata
One member losing its superblock is survivable, because mdadm assembles the array degraded from the surviving members' copies. The worst case is every member's mdadm 1.2 superblock being zeroed or corrupted. With no superblock left anywhere, mdadm --examine reports no md superblock. The native RAID parameters are gone, and mdadm can't assemble the array 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.
What If My Crashed Synology Was Hosting iSCSI Targets?
A Synology file-level iSCSI LUN is not a physical partition on the drives; it is a file inside the hidden @iSCSI directory, which Synology documents as holding LUNs and their snapshots, 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 LUN file inside it 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@iSCSIdirectory. - 4. LUN container file
- The LUN is extracted as a file from the recovered host filesystem, out of the
@iSCSIdirectory. - 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 LUN 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.
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 don't recover anything usable, there's no recovery fee under our no-fix-no-fee guarantee. That same two-part split governs NAS recovery pricing across member count and RAID level, where a larger array adds imaging line items instead of a second reconstruction fee.
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
Head Swap
Bench diagnosis found the read/write heads have to be replaced. Clicking can also come from firmware, the preamp, or the spindle
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'll provide one. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.
Sealed helium drives are on their own price list, $200–$5,000+. When a head swap or platter repair opens one, we refill it with helium. That adds $400–$800, and the donor has to be an exact match. Helium drive prices
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.
No data, no recovery fee. If we can't recover usable data from your crashed Synology, there's no recovery fee 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?
Is the Repair button in Storage Manager only for a degraded volume, not a crashed one?
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?
What if the mdadm superblock is gone, not just out of sync?
Why does assembling my mixed-capacity SHR give an incomplete or missing 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.
Localized Clean Zone
Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.
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 showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.
See the particle counter test at the benchSince 2008
Established
As Featured In
Related services
Related Recovery Services
Volume Crashed, Storage Pool Degraded, SHR reconstruction, and Btrfs/EXT4 recovery.
Recovery for 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: eCryptfs shared folders and DSM 7.2 LUKS volume encryption.
SHR is mdadm plus LVM plus Btrfs or ext4. How SHR degrades, why rebuilds eject healthy drives, and how the stack is reconstructed read-only.
Rackmount RackStation and all-flash FlashStation units, DSM 7.2 LUKS volumes, and large degraded arrays imaged member-by-member.
POST never completes, so the power LED keeps blinking blue and DSM never loads. Intel Atom C2000 erratum AVR54 or a failed power supply stops the chassis before the storage pool mounts, leaving the mdadm/SHR arrays intact.
Synology showing a Volume Crashed banner?
Free evaluation. No data, no recovery fee. Ship your drives from anywhere in the U.S.