Synology DS920+ Data Recovery
Your DS920+ shows Volume Crashed after an NVMe M.2 cache failure, an SMR drive timeout during rebuild, or a Btrfs metadata corruption. The mechanical drives are often healthy; the crash is in the filesystem layer. We recover DS920+ arrays through member-by-member imaging, NVMe dirty cache extraction, and offline SHR reconstruction. All work happens in our Austin lab. Free evaluation; no data = no charge.
Why does a DS920+ crash even when the hard drives are fine?
The DS920+ supports M.2 NVMe SSD caching. When configured as read/write cache, dirty Btrfs metadata and uncommitted file blocks stay on the NVMe drive until flushed to the SATA HDDs. If the NVMe SSD fails or drops from the PCIe bus, those uncommitted blocks vanish. The mechanical drives now contain an incomplete filesystem tree, so DSM reports Volume Crashed even though the HDDs spin up perfectly. Recovery requires imaging the NVMe cache SSD with PC-3000 SSD, extracting the dirty blocks, and merging them back into the reconstructed SHR array offline.
What Just Happened to Your DS920+
DS920+ failures are almost always logical, not mechanical. The drives spin. The heads read. The problem is in the layered stack of mdadm RAID, LVM, Btrfs, and NVMe cache that sits between your files and the platters.
The DS920+ is a 4-bay NAS with two M.2 2280 NVMe slots for SSD caching. Under DSM, it builds a storage stack: partitions, mdadm software RAID, LVM volume groups, optional NVMe flashcache, and finally Btrfs or ext4. Any of these layers can fail independently. When they do, DSM shows Volume Crashed. Understanding which layer failed drives the recovery plan.
NVMe Dirty Cache Dropout
Consumer NVMe SSDs in the M.2 slots lack power-loss protection capacitors. Under sustained write load, the controller can panic, overheat, or exceed its write endurance. When the cache drive disappears, uncommitted Btrfs metadata and dirty file blocks are lost. The HDDs hold a filesystem with missing tree nodes. DSM cannot mount it; Volume Crashed appears immediately.
Competitors do not mention this failure mode because they treat NAS recovery as generic hard drive repair. The NVMe cache layer is invisible to their standard workflow. We image the failed M.2 SSD with PC-3000 SSD, upload controller microcode to SRAM to bypass corrupted firmware, and extract the dirty cache extents for offline merge.
SMR Drive Timeout During Rebuild
WD Red DM-SMR drives and similar shingled models write data to overlapping tracks. Their internal CMR cache zones handle random writes, but sustained sequential writes during an SHR rebuild overflow the cache. The drive stalls for 30 to 60 seconds while reorganizing shingled data.
The Linux kernel interprets this stall as a dead drive and ejects the SMR member from the mdadm array. A degraded SHR-1 array that loses one more member during rebuild crashes the entire pool. The ejected drive is often physically healthy; it just needs imaging at a slower pace with timeout overrides.
Btrfs Tree-Root Corruption
Btrfs is copy-on-write. Every write creates a new tree generation rather than overwriting old blocks. When power is lost during a transaction, or when the NVMe cache dies mid-commit, the newest generation tree becomes inconsistent. Standard Linux btrfs-check and btrfs-restore tools fail because they depend on a complete metadata tree to walk the filesystem.
Recovery requires working from write-blocked images and parsing raw Btrfs device trees at the hex level to locate intact file data blocks. Snapshot subvolumes may still be traversable even when the live tree is damaged, giving us multiple historical recovery points.
DSM Update Firmware Lockouts
Recent DSM updates introduced stricter drive compatibility checks. If uncertified NVMe SSDs are used for cache or storage pools, DSM can deactivate them on reboot. The Storage Manager then shows SSD Cache 1 crashed or the storage pool as uninitialized. The user data on the HDD partitions remains intact, but the configuration database on partition 1 has been rewritten.
Blindly running synosystemctl scripts or issuing vgchange commands via SSH can permanently destroy LVM mappings. The safe path is to power down, label every drive by bay, and ship the unit for offline reconstruction.
All four failure modes share the same first rule: do not click Repair, Migrate, or Initialize in DSM. Every one of those operations writes to the drives and destroys metadata we need for recovery. Power the unit down, label the drives by bay number, and preserve the current state for imaging.
Common Misconceptions About DS920+ Data Recovery
High-priced national competitors treat the DS920+ as a generic four-bay NAS. Their pages list the model alongside fifty others, then pivot to cleanroom marketing and fabricated success rates. Not one of them explains the NVMe cache failure physics, the SMR timeout mechanism, or the mdadm plus LVM plus Btrfs stack that actually holds your data.
- SHR is not a black box
- Your DS920+ runs standard Linux mdadm software RAID with an LVM layer on top and Btrfs or ext4 as the filesystem. SHR is a management convenience, not a proprietary hardware format. Any recovery lab claiming they need special Synology hardware to read your array is either uninformed or selling fear. We assemble SHR arrays on a Linux workstation with mdadm --assemble --readonly and read the data directly.
- NVMe cache failures are recoverable
- When a competitor tells you the volume is unrecoverable because the NVMe cache died, they are describing the limits of their own workflow, not the physics of your data. The dirty blocks on the failed M.2 SSD can often be extracted with controller-level microcode upload, then merged back into the reconstructed array. We have recovered DS920+ volumes that other labs declared lost because they never attempted NVMe cache extraction.
- SMR drives are not dead; they are just slow
- A DS920+ that crashed during rebuild because an SMR drive timed out does not necessarily have a dead drive. The SMR member may be physically healthy but ejected by the kernel for stalling too long. We image SMR drives with custom timeout profiles that read at the drive's actual pace, not mdadm's schedule. Once imaged, the array reconstructs normally from clones.
- RAID is not your backup
- The DS920+ provides drive redundancy through SHR-1 or SHR-2, but redundancy is not data protection. A ransomware attack, accidental deletion, controller-induced parity pollution, or a cascading multi-drive failure from the same manufacturing batch destroys data across all members simultaneously. If you do not have an independent backup of critical data, fix that after recovery. We will say this on every RAID and NAS page because it is the single most destructive misconception in consumer storage.
How Much Does DS920+ Recovery Cost?
DS920+ recovery uses per-member pricing based on each drive's physical condition, plus an array reconstruction fee that covers SHR/mdadm detection, LVM reassembly, Btrfs extraction, and NVMe cache block merge if needed. If we recover nothing, you owe $0.
Per-Member Drive Pricing
Each of the four SATA drives and the M.2 NVMe cache SSD is priced individually against the same five-tier schedule used for individual hard drive data recovery. A typical DS920+ with one failed NVMe cache, two healthy HDDs, and one HDD with bad sectors generates individual line items for each evaluated member, 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.
Helium-sealed drives (8TB and larger NAS or server drives such as Toshiba MG08, Seagate Exos, and WD Ultrastar) are quoted on a separate tier. See helium drive pricing.
Array Reconstruction & Cache Extraction
Covers SHR/mdadm parameter detection, LVM volume group reconstruction, virtual assembly from cloned images, Btrfs filesystem extraction with snapshot traversal, and NVMe dirty cache block merge if a cache SSD was involved. The final figure depends on the number of members, whether mixed-capacity SHR complicates the LVM layer, and whether the NVMe cache requires controller microcode upload for extraction. Confirmed at the free evaluation alongside per-member line items.
On a typical DS920+ with a failed NVMe cache and three healthy SATA members, the invoice itemizes one NVMe SSD extraction line, three file-system or simple-copy HDD lines, and the array reconstruction fee. Every drive is priced as its own line so you can see exactly what each member required.
No Data = No Charge. If we cannot recover usable data from your DS920+, you owe nothing under our no-fix-no-fee guarantee. Optional return shipping is the only potential cost on an unsuccessful case.
How We Recover Data from a Crashed DS920+
We image every member drive through a hardware write-blocker with PC-3000 or DeepSpar, reassemble the SHR/mdadm and LVM stack from the cloned images, extract Btrfs or ext4 offline, and merge NVMe dirty cache blocks if a cache SSD was involved. The original drives are never modified.
DS920+ recovery follows an image-first, offline reconstruction workflow. Each SATA member and any M.2 NVMe cache SSD is connected through a hardware write-blocker and imaged before any analysis begins. Your original drives are never modified. All RAID reconstruction and filesystem extraction happen on cloned images.
- Free evaluation: We document your DS920+ serial, DSM error state, SHR configuration, filesystem type, NVMe cache setup, and any prior recovery attempts. You ship the unit or the labeled drives to our Austin lab.
- Write-blocked imaging: Each SATA member is imaged with PC-3000 Portable III or DeepSpar Disk Imager through a hardware write-blocker. Drives with weak heads or bad sectors get conservative retry profiles. The failed NVMe cache SSD is imaged with PC-3000 SSD using controller microcode upload if the NAND is accessible.
- Mechanical repair (if needed): SATA members that click, beep, or refuse to spin require clean-bench head swaps with matched donor parts before imaging can proceed. This is done in our 0.02 micron ULPA-filtered clean bench.
- RAID/SHR reconstruction: We read mdadm superblocks from the cloned SATA images, determine stripe size, parity rotation, and member order. For mixed-capacity arrays, we also reconstruct the LVM volume group from physical extents. Virtual assembly runs against images, never against originals.
- Filesystem extraction: Once the virtual array is assembled, we mount and extract the Btrfs or ext4 filesystem. For Btrfs, we traverse subvolume trees and recover snapshots where applicable. If an NVMe cache was present, we merge the extracted dirty cache blocks back into the volume geometry before extraction.
- 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 imaging hardware and clean bench used on individual hard drives applies to every DS920+ member. The difference is the layered reconstruction: mdadm parameters, LVM volume groups, Btrfs tree roots, and optionally NVMe cache block mapping. Each layer must be correct before the next layer can be addressed.
How Does SHR Store Data on the DS920+
SHR is standard Linux mdadm plus LVM plus Btrfs or ext4, with a thin Synology management wrapper. Your data lives on Partition 3 of each drive, protected by mdadm RAID superblocks and optionally wrapped in an LVM volume group for mixed-capacity arrays.
The DS920+ partitions every drive identically. Partitions 1 and 2 hold DSM system files and swap. Partition 3 holds your data. Under SHR, the data partitions are combined into mdadm arrays, then concatenated through LVM into a single logical volume, and finally formatted with Btrfs or ext4. Understanding this stack matters because a Volume Crashed error can originate in any layer.
| Layer | Technology | What It Does | Failure Mode |
|---|---|---|---|
| Physical drives | 4x SATA HDDs, 2x M.2 NVMe optional | Stores raw sectors. | Head crash, bad sectors, SMR timeout, NVMe controller panic. |
| Partitions | GPT partition table | Separates DSM system (1, 2) from user data (3+). | Partition table corruption from DSM reinstall or forced migration. |
| RAID | Linux mdadm (SHR-1 or SHR-2) | Combines partitions into redundant arrays. | Superblock corruption, member ejection, stale RAID metadata. |
| Volume manager | LVM (for mixed-capacity SHR) | Joins multiple mdadm arrays into one logical volume. | Volume group metadata loss, physical extent misalignment. |
| Cache | NVMe read/write flashcache (optional) | Buffers hot data and metadata before HDD commit. | Dirty block loss on controller failure; incomplete Btrfs tree. |
| Filesystem | Btrfs (default) or ext4 | Manages files, directories, snapshots, quotas. | Tree-root corruption, missing chunk tree, snapshot damage. |
A Volume Crashed error on the DS920+ can start at any layer in this table. If the NVMe cache layer fails, the filesystem above becomes inconsistent even though the RAID layer below is intact. If an SMR drive stalls in the RAID layer, the volume manager and filesystem above lose access to the array. Recovery requires diagnosing which layer failed first, then addressing that layer before reconstructing the ones above it.
Synology DS920+ Recovery FAQ
Can a failed M.2 NVMe cache really crash the entire DS920+ volume?
Will replacing the NVMe cache SSD fix the Volume Crashed error?
Are WD Red SMR drives safe in a DS920+?
Is SHR on the DS920+ a proprietary format that only Synology can read?
Is it safe to click Repair in DSM Storage Manager on a crashed DS920+?
What if two drives failed in my DS920+ SHR-1 array?
How long does DS920+ recovery take?
How do I ship a DS920+ for recovery?
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 make sure your hard drive is handled safely and properly. 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
Louis Rossmann's well trained staff review our lab protocols to ensure 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
Full Synology recovery service for all DSM models, SHR arrays, and Btrfs/ext4 filesystems.
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.
NVMe and SATA SSD recovery for failed controllers, worn flash, and firmware corruption.
DS920+ showing Volume Crashed?
Free evaluation. No data = no charge. Ship your drives from anywhere in the U.S.