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. 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.
DS920+ Logical Failure Modes
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.
The NVMe cache layer is easy to overlook when NAS recovery is treated as generic hard drive repair. 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.
This dirty-cache dropout is the primary failure path behind a Synology blinking blue light, where the unit never finishes booting because the volume it expects to mount is inconsistent.
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.
DSM 7.2 LUKS Volume Encryption / Key Vault Loss
The DS920+ supports DSM 7.2 full volume encryption, which wraps the entire data volume in a LUKS container running in aes-xts-plain64 mode. To auto-mount at boot, DSM does not store your passphrase on the encrypted volume; it wraps the LUKS master key and keeps that wrapped key in the Encryption Key Vault.
The vault lives on the unencrypted mdadm system partition (md0, the RAID1 array built from partition 1 of the drives), or on a remote KMIP server. If that vault is corrupted or unreachable, or the auto-mount wrapped key is destroyed, and you never exported the recovery key, the data is mathematically unrecoverable: aes-xts-plain64 cannot be bypassed without the key.
The recovery ordering is strict. We image every member through a hardware write-blocker first and never let the NAS rebuild, because starting a rebuild on a degraded encrypted array can overwrite the LUKS header at the start of the volume.
We extract the wrapped master key from the cloned md0 system partition before any array reconstruction, rebuild the mdadm and LVM stack offline, decrypt the LUKS container offline against the header on the cloned volume, then read the Btrfs filesystem read-only.
All five 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
The DS920+ is often treated as a generic four-bay NAS. The failure modes that actually crash it are specific to its architecture: the NVMe cache failure physics, the SMR timeout mechanism, and the mdadm plus LVM plus Btrfs stack that holds your data. Each one drives a different recovery path.
- 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 claim that special Synology hardware is required to read your array is incorrect. We assemble SHR arrays on a Linux workstation with mdadm --assemble --readonly and read the data directly.
- NVMe cache failures are recoverable
- A failed NVMe cache does not make the volume unrecoverable. 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 offline.
- 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.
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 & 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. This is the same image-first method we apply to NAS data recovery across every brand and array type we handle.
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. The same layered diagnosis drives our Synology NAS data recovery work across every DSM model that runs SHR.
How Do You Recover an iSCSI LUN From a Crashed DS920+?
An Advanced iSCSI LUN on the DS920+ is not a physical partition you can carve straight off the member disks. It is a large sparse file named EP_DAT_00000 that lives inside a hidden @iSCSI directory on the SHR volume's Btrfs or ext4 filesystem.
You cannot reach that file until the full SHR stack this page already documents, the mdadm size bands bridged by LVM with Btrfs or ext4 on top, has been reconstructed read-only first. Recovering the LUN is the same SHR reassembly described in the recovery-process and SHR-architecture sections above, plus an extract-and-loop-mount stage on the end.
The extraction order ties directly back to the SHR reconstruction covered earlier:
- Reconstruct the SHR stack read-only: Image every member through a write-blocker, reconstruct each SHR mdadm size band read-only, and bridge the bands with LVM, exactly as for a non-iSCSI DS920+ crash. The LUN file cannot be touched until the host volume underneath it is assembled.
- Mount the host filesystem read-only: Mount the reconstructed Btrfs or ext4 host filesystem read-only & locate the hidden
@iSCSIdirectory that holds the LUN container. - Extract the container preserving sparseness: Copy the
EP_DAT_00000container off the host filesystem to a healthy target. A thin LUN is sparse, so only the allocated extents hold real data. A naive flat copy that fills the holes can balloon a thin LUN to its full provisioned size & exhaust the target drive, so the extract step preserves sparseness. - Loop-mount the extracted container: Attach the extracted file as a block device with
losetup -Pso the kernel scans the partition table the iSCSI initiator wrote inside the container, exposing the inner NTFS, ext4, or VMFS filesystem so the data can be read.
When the host Btrfs extents holding the EP_DAT file are themselves damaged, often from the NVMe dirty-cache dropout this page documents above, the forensic path is the same read-only one used for any damaged Btrfs tree. We work read-only with btrfs-find-root and btrfs restore against historical generation roots, and never run btrfs check --repair, because copy-on-write means an in-place write overwrites the older, still-valid tree roots that the extraction depends on.
If the container's own extents are marginal, we ddrescue-image the extracted EP_DAT file to a healthy target before loop-mounting it, because loop-mounting a damaged container off a failing host filesystem risks I/O hangs in the loop driver.
Two forum claims send people down dead ends. The first is that a LUN is a physical partition you can carve directly off the member disks: it is not, because it only exists as a file inside a host filesystem that has to be reconstructed first.
The second is that the LUN can be recovered without reconstructing the SHR mdadm, LVM, and Btrfs or ext4 stack underneath it. There is no shortcut past the host volume; the container has no meaning until the filesystem that stores it is mounted read-only.
Read-only forensic diagnostic (run against sector clones, never live drives)
# READ-ONLY DIAGNOSTIC. For sector-by-sector clones only,
# not live or degraded drives. The host SHR stack is already
# assembled read-only before any of this runs.
# Mount the reconstructed SHR host filesystem read-only
mount -o ro /dev/vg1/volume_1 /mnt/recover
# Locate the LUN container in the hidden @iSCSI directory
ls /mnt/recover/@iSCSI/
# Extract the EP_DAT container (preserve sparseness on a thin LUN,
# or ddrescue it first if the container extents are marginal)
cp /mnt/recover/@iSCSI/EP_DAT_00000 /target/lun.img
# Loop-mount the extracted container read-only and read the inner FS
losetup -fP /target/lun.img
mount -o ro /dev/loop0p1 /mnt/lunThese are diagnostics, not a repair guide. No btrfs check --repair, no in-place writes.
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?
Can a DS920+ encrypted volume be recovered if the Encryption Key Vault is lost?
How does DSM 7.2 volume encryption change the DS920+ recovery process?
How do you recover an iSCSI LUN from a crashed DS920+ volume?
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
DSM Volume Crashed across all Synology models: we separate mdadm superblock damage from Btrfs parent transid verify failed, image every member, reassemble SHR/mdadm and LVM read-only, and extract Btrfs or ext4. Do not click Repair.
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.
Rackmount and high-bay Synology recovery: enterprise SHR/RAID arrays, DSM 7.2 LUKS volumes, and large degraded pools imaged member-by-member.
DS920+ showing Volume Crashed?
Free evaluation. No data = no charge. Ship your drives from anywhere in the U.S.