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. We recover DS920+ arrays through member-by-member imaging and offline SHR reconstruction. All work happens in our Austin lab. Free evaluation. No data, no recovery fee.
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.
DS920+ Logical Failure Modes
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 SSD cache, and finally Btrfs or ext4. Any of these layers can fail independently. Understanding which layer failed drives the recovery plan.
NVMe Dirty Cache Dropout
When the M.2 NVMe cache drive drops off the PCIe bus, it takes the uncommitted Btrfs metadata and dirty file blocks with it. The HDDs hold a filesystem with missing tree nodes. DSM can't mount it, and Volume Crashed shows up right away.
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. Changed tree blocks get written to new locations instead of over the old ones, so older generation tree roots are still sitting on the disk. If the NVMe cache dies in the middle of a commit, the newest generation is the one left inconsistent.
We recover from write-blocked images with two read-only tools, btrfs-find-root and btrfs restore, pointed at those older generation roots. Snapshot subvolumes may still be traversable even when the live tree is damaged, giving us multiple historical recovery points.
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. DSM keeps the volume's encryption key in the Encryption Key Vault, so the volume unlocks automatically at startup.
The vault lives either on the unit itself or on a remote KMIP server. When the vault isn't available, Synology says the way into the volume is the recovery key or the key vault password. Lose both and the volume can't be accessed, because there's no getting around aes-xts-plain64 without the key.
The recovery ordering is strict. We image every member through a hardware write-blocker first and never let the NAS rebuild.
We rebuild the mdadm and LVM stack offline. Then we use the recovery key to unlock the LUKS container offline, against the header on the cloned volume, and read the Btrfs filesystem read-only.
All four of these start with the same rule: don't click Repair or Migrate in DSM, because both of them write to the drives. Power the unit down, label the drives by bay number, and leave everything as it is for imaging.
Is Your DS920+ Locked by the DSM 7.4.1 KMIP Certificate Rule?
Synology narrowed which certificate a NAS may present when its Encryption Key Vault authenticates to a key server. The release notes state that "KMIP client authentication now requires certificates issued by a private CA. Synology default certificates, the QuickConnect certificate, and certificates issued by public CAs (e.g., Let's Encrypt, SSL.com, and Sectigo) are not supported for KMIP client authentication". That rule arrived in DSM 7.4.1-90080, which Synology's release notes date to 2026-07-23.
Settle where your vault lives before that rule means anything to your unit. Synology documents two vault locations: local to the unit and protected by a vault password, or held on a KMIP server.
If the vault does answer to a remote key server and the certificate it presents is no longer accepted, Synology documents the consequence in one sentence: "If the vault isn't available, the volume will stay locked". Locked is a key-availability problem.
Crashed is structural damage down at the mdadm or Btrfs layer. On this chassis, one cause is the M.2 NVMe read/write cache dropping off the PCIe bus and taking its uncommitted writes with it. That leaves broken Btrfs tree roots sitting on mechanically healthy drives, and it takes different work than a locked volume.
We never run btrfs check --repair, because repair mode edits B-trees in place and takes the historical roots with it.
Rolling DSM back doesn't open a locked volume either. Synology attaches a standing sentence to these releases: "After installing this update, you will not be able to downgrade to a previous DSM version". Since the firmware side doesn't go backwards, the work sits on the certificate and key side.
Either reissue the KMIP client certificate from a private CA, or unlock with something you already have: the key vault password, or the recovery key file you downloaded when the volume was created. We walk through the unlock steps on our DSM encrypted volume recovery page.
What Does a Repair Rebuild Do to the Three Surviving DS920+ Drives?
On a four-bay SHR-1 pool of equal-capacity drives, a Repair rebuild reads all three surviving drives so mdadm can recompute the missing member from parity. A pool already down one member has nothing left behind that parity to cover a sector the rebuild can't read.
Consumer drives carry a manufacturer rating of roughly one unrecoverable read error per 10^14 bits read, about 12.5 TB. That is a worst-case ceiling off a specification sheet, & drives routinely read well past it without ever returning one.
The figure that matters on a DS920+ is how much reading the rebuild demands. Rebuilding one member of an equal-capacity four-bay pool means reading the other three. Synology's Fast Repair, enabled by default on pools that hold volumes, skips the space the pool isn't using. A traditional rebuild reads the full capacity of all three. A mixed-capacity pool is built as several mdadm slice groups of differing widths, so the read falls on whichever members carry the groups the lost drive belonged to.
What Linux md does when it hits an unreadable sector mid-rebuild is narrower than the forum version of the story. mdadm records the bad block in its Bad Block Log & keeps going rather than aborting the resync.
The stripe is what you lose. With single parity there is nothing left to reconstruct that block from, so the rebuild doesn't stop, but the data in that stripe is gone. The same single-parity arithmetic governs every RAID 5 array recovery that reaches our bench.
The load is the second cost. A rebuild pins all three survivors at near-continuous sequential read for many hours, which is the workload that finishes off a member with weak heads or a growing bad-sector count. A drive that would have imaged cleanly beforehand can come off a rebuild needing donor heads, which moves it into mechanical hard drive recovery with clean-bench time & a donor hunt attached.
SMR ejection, covered in the failure-mode cards above, costs something specific during a rebuild. When the kernel drops a stalled surviving member mid-resync, a pool that was down one drive is now down two, past what SHR-1 tolerates, so the volume crashes rather than the rebuild pausing.
The ejected drive is often physically healthy. What a crashed rebuild leaves you with is a count of ejections, not a count of dead drives, and we settle which is which by imaging every member.
So here's the rule. Image every member through a hardware write-blocker first, with ddrescue, a PC-3000 Portable III, or a DeepSpar Disk Imager. Then we rebuild the mdadm, LVM, & Btrfs or ext4 stack offline from the clones. Data Extractor Express RAID Edition handles the mdadm structure analysis. We recompute parity against the copies, so a wrong parameter costs a rerun instead of your data. The array-level version of this reasoning sits on our SHR hybrid RAID page, & the same imaging-first order applies to every RAID array reconstruction we take in at the Austin lab.
Common Misconceptions About DS920+ Data Recovery
- 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.
- 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.
- RAID is not your backup
- The DS920+ provides drive redundancy through SHR-1 or SHR-2, but redundancy is not data protection. Ransomware, an accidental deletion, or a cascading failure of several drives from the same manufacturing batch wipes out data on every member at once. If you do not have an independent backup of critical data, fix that after recovery.
How Much Does DS920+ Recovery Cost?
We price a DS920+ recovery per drive, based on each drive's physical condition, plus an array reconstruction fee that covers SHR/mdadm detection, LVM reassembly, and Btrfs extraction. If we don't get any data back, there's no recovery fee.
Per-Member Drive Pricing
Each of the four SATA drives gets its own line, priced against the same five-tier schedule we use for individual hard drive data recovery, so you can see what each member required.
- 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
The reconstruction fee covers SHR/mdadm parameter detection, LVM volume group reconstruction, virtual assembly from cloned images, and Btrfs filesystem extraction with snapshot traversal. We confirm the fee at the free evaluation, alongside the per-member line items.
No data, no recovery fee. If we can't recover usable data from your DS920+, there's no recovery fee under our no-fix-no-fee guarantee. Return shipping is optional. If you want it, we bill it, and it's the only 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. Then we reassemble the SHR/mdadm and LVM stack from the cloned images and extract Btrfs or ext4 offline. 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.
- Mechanical repair (if needed): If a SATA member has a mechanical fault, we work on it with matched donor parts in our 0.02 micron ULPA-filtered clean bench before we image it. We identify the failed component on the bench.
- RAID/SHR reconstruction: We read mdadm superblocks from the cloned SATA images, determine stripe size, parity rotation, and member order. Every SHR pool carries an LVM layer, so we also rebuild the LVM volume group from its 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.
- 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.
Every DS920+ member goes through the same imaging hardware we use on individual hard drives. The difference is the layered reconstruction: mdadm parameters, LVM volume groups, and Btrfs tree roots. Each layer has to be right before we can work on the next one. 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 in the data partitions of each drive, protected by mdadm RAID superblocks and wrapped in an LVM volume group.
DSM formats each drive with a system partition, a swap partition, and data partitions, and your files live in the data partitions. Under SHR, the data partitions are combined into mdadm arrays, then concatenated through LVM into a single volume group, 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. |
| Partitions | Partition table | Separates the DSM system and swap partitions from the data partitions. | System partitions rewritten by Migrate or Repair after the drives move to a new chassis. |
| RAID | Linux mdadm (SHR-1 or SHR-2) | Combines partitions into redundant arrays. | Superblock corruption, member ejection, stale RAID metadata. |
| Volume manager | LVM (SHR) | Joins multiple mdadm arrays into one volume group. | Volume group metadata loss. |
| Cache | NVMe read/write SSD cache (optional) | Buffers hot data and metadata before HDD commit. | Dirty block loss and an incomplete Btrfs tree. |
| Filesystem | Btrfs 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+?
A file-level iSCSI LUN on the DS920+ is not a physical partition you can carve straight off the member disks. It is a file that lives inside the hidden @iSCSI directory, which Synology documents as holding LUNs and their snapshots, 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: Copy the LUN container file off the host filesystem to a healthy target.
- 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 LUN container file are damaged too, we take the same read-only forensic path we use on 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 container file to a healthy target before loop-mounting it.
Two ideas send people down dead ends. One is that a LUN is a physical partition you can carve directly off the member disks. It only exists as a file inside a host filesystem, and that filesystem has to be rebuilt first.
The other is that you can get the LUN back without rebuilding the SHR mdadm, LVM, and Btrfs or ext4 stack underneath it. There's no shortcut past the host volume. The container means nothing 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 LUN container file (ddrescue it instead
# if the container extents are marginal)
cp /mnt/recover/@iSCSI/<path-to-lun-file> /target/lun.img
# Loop-mount the extracted container read-only and read the inner FS.
# losetup -f takes the first unused loop device and --show prints
# which one it picked, so the partition is that device's p1.
losetup -fP --show /target/lun.img
mount -o ro /dev/loop<N>p1 /mnt/lunThese are diagnostics, not a repair guide. No btrfs check --repair.
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 degraded 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?
Is my DS920+ volume crashed, or is it locked after a DSM update?
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
DSM Volume Crashed across 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 DSM models, SHR arrays, and Btrfs/ext4 filesystems.
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.
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 recovery fee. Ship your drives from anywhere in the U.S.