NAS Data Recovery for Synology and QNAP Systems

How Much Does NAS Data Recovery Cost?

NAS recovery uses a two-tiered pricing model: a per-member imaging fee for each individual drive in the array, plus a final array reconstruction fee of $400-$800. For example, a 4-bay NAS means four separate imaging fees plus the reconstruction fee. If we cannot recover your data, there is no charge.

What Is NAS Data Recovery and When Is It Needed?

NAS data recovery is the process of extracting files from a failed or degraded network-attached storage device by imaging each member drive independently and reconstructing the RAID array, filesystem metadata, and shared folder structures offline from the clones.

• NAS devices from Synology, QNAP, and Buffalo run Linux software RAID (mdadm) or ZFS under their own management layers. When the storage pool degrades or the volume crashes, the vendor's web interface often offers only destructive options: reinitialize, recreate, or force-repair.
• Common triggers include a second member drive failing during a rebuild, firmware updates that corrupt RAID metadata, and accidental LUN or volume deletion.
• To recover it, we image each member on PC-3000 or DeepSpar hardware, detect the RAID parameters (stripe size, parity rotation, member order), and reassemble the array virtually from the cloned images.

What Symptoms Indicate a NAS Needs Professional Recovery?

NAS failure symptoms range from "Volume Crashed" and "Storage Pool Degraded" warnings to inaccessible shared folders and stuck rebuilds. The correct response to every symptom is the same: stop all write activity, power down the NAS, and avoid forced rebuilds or reinitialization.

• Volume crashed / Storage pool degraded: Don't force a rebuild on failing members. Its sustained reads can push a marginal drive into failure. Power down and stop writes.
• Cannot access shared folders: Don't accept prompts to repair or recreate. Initialization overwrites critical RAID metadata.
• Multiple disk errors in logs: Avoid swapping drive order or hot-plugging repeatedly. Label drives and preserve original slot assignments.
• Drives showing as offline: Don't keep power-cycling.
• RAID rebuilding stuck: Power down immediately.
• Encrypted volumes inaccessible: Have encryption keys and passwords available. We keep data offline and under chain-of-custody.

If your NAS uses ZFS and zpool import is failing with I/O errors, see our ZFS pool import I/O error recovery guide. For Synology-specific "Volume Crashed" diagnostics, see the Synology volume crash recovery guide.

If a rebuild was already attempted on weakening members, read about how forced NAS RAID rebuilds cause permanent data loss. For NAS units reporting a degraded storage pool, we image each member before any reconstruction.

Why SSH-Based Recovery Software Endangers Degraded NAS Drives

SSH-based NAS recovery software reads every member through the NAS operating system, and it has no per-head control over how a failing drive gets read. When the heads are degrading, those sustained reads push a marginal drive toward mechanical failure.

A hardware imager like the DeepSpar Disk Imager handles each head differently depending on how degraded that head is, and it runs customizable read algorithms.

SSH-based software has none of these controls.

If your NAS has mechanical symptoms (clicking, intermittent disconnects, slow access on specific shares), power it down. Don't turn on SSH recovery utilities. The drives have to come out, go onto imaging hardware, and get cloned sector-by-sector before anyone attempts a reconstruction.

How Do We Recover Data from a Failed NAS?

We recover NAS arrays using a six-step image-first workflow: document the configuration, clone each member on PC-3000 or DeepSpar imaging hardware, capture RAID metadata, reconstruct the array offline from images, extract files, and deliver verified data.

1. Free evaluation and diagnostic: Document NAS model, RAID level (SHR, RAID 5, RAID 6, etc.), member count, encryption status, and any prior rebuild or repair attempts. No experiments run on original drives.
2. Forensic imaging: Clone each member drive using PC-3000 and DeepSpar hardware. Donor part transplants are performed for members with mechanical failures before imaging begins.
3. Metadata capture: Copy RAID headers and superblocks. Record stripe sizes, parity rotation, member offsets, and filesystem type (Btrfs, EXT4, XFS, ZFS).
4. Offline array reconstruction: Assemble the virtual array from cloned images only. Validate parity consistency and filesystem integrity across the reconstructed volume.
5. Filesystem extraction and recovery: Rebuild or correct the filesystem on the clone, carve fragmented files where needed, and verify priority data such as shared folders, virtual machines, and databases.
6. Delivery: We copy the recovered data to your target media and check file integrity with you.

Consumer NAS vs. Enterprise NAS: How Drive Architecture Affects Recovery

Recovery complexity depends on the hard drive architecture inside the NAS chassis. Consumer-grade NAS arrays populated with SMR drives and enterprise arrays using helium-sealed drives present different mechanical and firmware challenges during imaging.

Consumer NAS Arrays and SMR Drive Complications

SMR overlaps data tracks to increase capacity. On Western Digital drive-managed SMR drives, a second-level translator keeps track of where those writes landed.

When that translator is damaged, the drive reads zeros in every sector. We have to repair the firmware problem before sector imaging returns user data. This adds a firmware repair step to every affected member in the array.

Enterprise NAS and Helium-Sealed Drive Recovery

We handle helium-sealed drives in-house, including the mechanical work, the helium refill, and platter cleaning.

CMR vs SMR Drives for NAS: Which Belongs in an Array?

CMR drives belong in a NAS array; device-managed SMR drives do not. The difference is how the platter is physically written, & it decides whether a rebuild finishes or whether a healthy drive gets kicked out of the array partway through.

How CMR and SMR Write the Platter Differently

CMR lays each magnetic track down side by side with a guard gap between tracks, so the drive can overwrite any single track in place without disturbing its neighbors.

SMR overlaps the tracks like roof shingles to pack more data onto the same platter. The overlap is what creates the problem: you can no longer rewrite one track without re-writing the shingled band of tracks stacked on top of it.

To hide that penalty, an SMR drive keeps a small CMR cache zone, a strip of non-overlapping tracks where incoming writes land first, then drains those writes into the shingled area during idle time.

The WD Red SMR drives are device-managed (DM-SMR), meaning the drive handles all of this internally & presents itself to your NAS as an ordinary hard drive.

Why Do SMR Drives Drop Out of a NAS Rebuild?

A DM-SMR drive gets ejected mid-rebuild because the rebuild never gives it idle time to empty its cache. A RAID rebuild or ZFS resilver is a sustained, hours-long stream of writes.

The CMR cache zone fills, & with no idle window to drain it, the drive is forced into aggressive shingle-band rewrites while writes keep arriving. Those rewrites push command latency to 30 to 60 seconds, well past the Linux kernel & RAID controller command timeout.

The array interprets a timeout from a mechanically healthy drive as a dead member & drops it, which can collapse a single-drive failure into a degraded or failed array.

The drive that just got kicked out is usually fine. The platters, heads, & motor are healthy, & the firmware just couldn't answer in time. A clicking head-crash drive fails the opposite way. That's why we image every member with imaging hardware (a DeepSpar Disk Imager, or a PC-3000 Portable III or Express) before any array reassembly. We don't force the live NAS to rebuild onto a drive that keeps timing out.

RAID is not a backup. A NAS array keeps you running with no downtime when a single drive dies. It does nothing for a second drive failing during the rebuild, a ransomware run, an accidental delete, or a controller failure. The drive architecture you pick changes how likely that rebuild is to survive, but it never turns the array into a backup copy.

CMR vs SMR for NAS: Side-by-Side Comparison

The recovery-cost rows reflect the extra firmware work an SMR translator demands. SMR (Shingled Magnetic Recording) drives require more work at the firmware and head-swap tiers due to their overlapping track architecture. Both figures are per evaluated member, billed individually for each drive that needs the work; a free evaluation comes first, & if we recover nothing you owe $0.

CMR (Conventional Magnetic Recording)

Data tracks sit side by side without overlapping, so any track can be overwritten in place. Write speed stays steady through a RAID rebuild.

SMR (Shingled Magnetic Recording)

Data tracks overlap like roof shingles to raise density. Rewrites force whole shingled bands to be re-written through a small CMR cache zone; once that cache fills under sustained writes, the drive stalls long enough for a NAS to time it out & eject it.

What to Check Before You Build or Rebuild an Array

Check the exact model number before you trust a drive in an array, because the WD Red label alone doesn't tell you whether a drive is CMR or SMR. The plain WD Red drives in 2TB, 3TB, 4TB, & 6TB capacities are DM-SMR (WD20EFAX, WD30EFAX, WD40EFAX, & WD60EFAX).

WD Red Plus is CMR at every capacity in the line.

If an SMR drive has already dropped out & corrupted its translator, don't force the NAS to assemble or rebuild onto it. Forcing the assembly marks failed members as working so the array can start. The mdadm manual warns that an array that needs --force may contain data corruption.

Power the NAS down & leave the drives alone. We image that member first, using the same WD firmware workflow we use to rebuild a corrupted translator before sector imaging begins.

WD My Cloud Data Recovery: What the Linux Layout Means for Your Files

The WD My Cloud name covers several products that store data in completely different ways. Knowing which one you have decides whether the data is plaintext ext4 you can read on a Linux box or ciphertext locked behind a bridge chip.

Multi-Bay My Cloud NAS Units Run mdadm and ext4

The multi-bay My Cloud enclosures run an embedded Linux operating system that stores your shares on mdadm software RAID with an ext4 filesystem on top. They don't encrypt the platter through a bridge chip.

Unless you explicitly turned on software volume encryption in the dashboard, the data is plaintext ext4 that mounts directly in a Linux recovery rig once each disk is imaged.

That doesn't mean you should pull the disks & drop them into a new enclosure. The array geometry lives in the mdadm metadata on the disks, & a different enclosure or a forced rebuild can overwrite that metadata & the partition layout before you ever see your files. We image every disk first on PC-3000 or DeepSpar hardware, then assemble the array read-only from the clones with mdadm.

See the WD My Cloud recovery page for the model-by-model breakdown.

My Book and My Passport USB: Bridge-Chip AES, Shucking Yields Ciphertext

Single-drive WD My Book & My Passport USB enclosures are the opposite of a My Cloud. Many of them route the drive through a USB-to-SATA bridge chip (JMicron & Symwave families are common) that encrypts the platter with AES, even when you never set a password.

If you shuck the drive, remove it from the enclosure & connect it straight to a desktop, you get ciphertext, not your files.

Shucked drives have a second trap, even when encryption isn't involved. A drive with the optional SATA 3.3 Power Disable feature treats pin 3 of the SATA power connector as a power-disable pin. It won't power up on a power supply that drives 3.3V on pin 3.

Our Western Digital recovery workflow handles the bridge & the power-disable pin together.

My Cloud Home: Content IDs and an index.db, Not a Normal Share

The My Cloud Home is its own case & catches people who expect a normal My Cloud. It renames every file you upload to a 64-character hexadecimal content ID on disk. Your real filenames, folders, & the mapping back to those content IDs live in a SQLite database (index.db).

Image the disk & you find a directory full of hex-named blobs that look like garbage until index.db is parsed to reattach the original names. We pull the content IDs & reconcile them against index.db so files come back with their real names & folder structure intact.

A single-bay My Cloud Home holds one SATA drive with no RAID underneath, so it clones at the sector level like any other single drive. Our My Cloud Home index.db rebuild starts from that clone and ends with the SQLite mapping reattached to the blobs.

NAS Ransomware Recovery: Deadbolt, QLocker, and eCh0raix

NAS-specific ransomware (Deadbolt, QLocker, eCh0raix) targets Internet-exposed Synology and QNAP devices by locking shared folder files. The underlying RAID geometry usually remains intact, and recovery focuses on filesystem-level forensic extraction from cloned member images rather than paying the ransom.

QNAP tied QLocker to vulnerabilities it had patched in QTS and in Multimedia Console. Unit 42 found an eCh0raix variant delivered to QNAP devices through CVE-2021-28799. Deadbolt encrypted files on QNAP devices with AES-128 and replaced the QNAP login page with its ransom screen. QLocker moved files into password-protected 7-Zip archives.

eCh0raix targeted both Synology and QNAP devices.

1. Power down the NAS. We image every member at intake.
2. We clone each member on PC-3000 or DeepSpar hardware.
3. We look for Btrfs or ZFS snapshots taken before the attack and extract the files they hold from the clones.

For broader ransomware recovery scenarios beyond NAS devices, see our ransomware data recovery service.

How Do You Recover a Buffalo TeraStation Stuck in Emergency Mode?

Buffalo TeraStation's Emergency Mode is usually a firmware boot failure rather than a data failure. The recovery path is offline reassembly of the mdadm array from cloned members, followed by read-only XFS extraction with xfs_db and xfs_logprint. Running xfs_repair -L on the original drives can lose user files.

Buffalo network appliances run standard Linux mdadm. The data volume is predominantly XFS, with ext4 on some units. When firmware corruption hits the boot partition on the member drives, the TeraStation drops into Emergency Mode.

NASNavigator then shows the device as Unformatted, even though the user data is usually still intact.

If you pull the drives, assemble the array on a workstation with mdadm --assemble, and then run xfs_repair -L on the assembled volume, you zero the XFS log, even if it's dirty.

The xfs_repair manual says that loses every metadata update that was in progress at the time of the crash, which may cause significant filesystem damage. It also says zeroing the log should only be a last resort. A Buffalo TeraStation in Emergency Mode hasn't reached that point.

On a Buffalo TeraStation we image every member through imaging hardware (PC-3000 Portable III or DeepSpar Disk Imager). We assemble the cloned set with mdadm --assemble --readonly so nothing writes to the assembled array. Then we look at the XFS state with xfs_logprint before deciding whether the log can be replayed cleanly.

When the log is intact we mount the assembled image read-only and copy files out. When the log holds incomplete transactions we read the B+tree directly with xfs_db in read-only mode, walking inode chunks and directory blocks by hand to extract files without ever writing back to the clone. Either way, the original member drives sit on the shelf untouched, so a second attempt is always possible if the first pass missed a directory subtree.

Emergency Mode

The firmware state a Buffalo TeraStation or LinkStation enters when firmware corruption hits the boot partition on its member drives. NASNavigator reports the unit as Unformatted. Emergency Mode is a boot failure, not a data failure: the XFS user volume on the member drives is usually intact.

xfs_logprint

The XFS utility that prints the log of an XFS filesystem. We run it against the assembled mdadm image to determine whether the log holds complete transactions (safe to replay) or partial transactions (require direct B+tree extraction with xfs_db).

Which NAS Filesystems and RAID Modes Do We Support?

We recover data from Btrfs, EXT4, XFS, and ZFS filesystems across Synology SHR/SHR-2, standard RAID 0/1/5/6/10, and QNAP QuTS hero ZFS pools. Each filesystem requires different metadata parsing and reconstruction techniques.

Synology SHR / SHR-2

Synology Hybrid RAID uses mdadm with variable-size partitions to mix drive capacities. SHR-2 adds dual parity equivalent to RAID 6. We parse the custom partition layout and mdadm superblocks from each member image.

Btrfs on NAS

Btrfs stores metadata in a tree structure across members. We reconstruct the chunk tree and device tree from imaged copies to locate and extract files.

ZFS (QNAP QuTS hero)

QNAP's QuTS hero uses ZFS. We clone the members and attempt a read-only pool import. If the newest pool state is damaged, zpool import's recovery mode can return the pool to an importable state by discarding the last few transactions. See our ZFS pool recovery guide. QuTS hero units running native ZFS rather than the QTS md and LVM stack are handled under QNAP QuTS hero ZFS pool recovery.

EXT4

QNAP QTS, WD My Cloud NAS units, and legacy ReadyNAS OS4/OS5 units store their data on ext4, and Synology offers it as a volume option. EXT4 journal recovery and inode reconstruction from degraded arrays is a standard part of our workflow.

XFS

Most Buffalo TeraStation and LinkStation units store their data on XFS. XFS allocation group headers and B+ tree metadata are reconstructed from member images during recovery.

Encrypted Volumes

Recovery of encrypted volumes requires the original encryption key or passphrase. Without it, the data cannot be decrypted regardless of array condition.

Advanced Offline Reconstruction Mechanics

Once each member is imaged and the RAID layer is virtually reassembled from clones, filesystem-level damage determines the reconstruction approach. Each filesystem stores metadata differently, and the wrong repair command on the wrong filesystem type will overwrite the structures needed for recovery. EXT4 journal replay, Btrfs chunk tree reconstruction, and ZFS Uberblock rollback are each handled from cloned images.

Once each member is imaged and the RAID layer is virtually reassembled from clones, the filesystem-level damage determines the reconstruction approach. Each filesystem stores metadata differently, and the wrong repair command on the wrong filesystem type will overwrite the structures needed for recovery.

• EXT4 journal replay: When an EXT4-based NAS (such as WD My Cloud NAS units) crashes mid-write, we can replay its jbd2 journal up to the latest commit record. We replay the committed transactions from the cloned array image to restore inode consistency and reconstruct orphaned directory entries on the clone.
• Btrfs chunk tree and subvolume reconstruction: Btrfs uses a chunk tree to convert its logical addresses to physical addresses on the underlying device. We extract from the clones with read-only tools such as btrfs-find-root and btrfs restore.
• ZFS Uberblock rollback: On QNAP QuTS hero devices, each ZFS vdev label ends in an array of uberblocks that is updated as transaction groups commit. When the newest state points at damaged metadata (causing pool import I/O errors), zpool import's recovery mode can discard the last few transactions to get the pool importable again. We run it against the clones.

iSCSI LUN and Virtual Machine Recovery on NAS Storage

Enterprise Synology and QNAP deployments host iSCSI targets for VMware ESXi, Proxmox, and Hyper-V. When the NAS fails, iSCSI LUNs are raw block devices containing their own internal filesystems (such as VMFS or NTFS), not partitions of the NAS filesystem. Recovery is two-stage: reconstruct the NAS filesystem from clones, then parse the raw LUN images.

Enterprise Synology and QNAP deployments host iSCSI targets for VMware ESXi, Proxmox, and Hyper-V hypervisors. When the NAS fails, iSCSI LUNs are not visible as standard shared folders. On Synology, a file-level LUN is a file on the underlying Btrfs or ext4 volume, under the hidden @iSCSI directory. Recovery requires a two-stage logical extraction.

1. Reconstruct the underlying NAS filesystem (Btrfs, EXT4, or ZFS) from cloned member images to locate the files representing each LUN.
2. Parse the filesystem the host put inside each LUN image, such as VMFS on an ESXi host or NTFS on a Windows host. We extract .vmdk, .vhdx, and flat image files directly from the reconstructed block layer without relying on the NAS operating system to mount damaged LUNs.

For NAS arrays where an iSCSI LUN was accidentally deleted, we scan unallocated space on the member images for orphaned file headers. For virtual machine recovery from server environments, the same LUN extraction workflow applies whether the host was a dedicated server or a NAS acting as a SAN target.

mdadm, LVM, and ZFS Configuration Recovery Parameters

NAS arrays store their geometry in on-disk metadata that must be parsed before any filesystem can be mounted. We detect these parameters from cloned images rather than trusting the NAS operating system, which protects against cases where the vendor configuration database has desynced from the actual array state, including mdadm superblock versions, LVM physical volume headers, and ZFS vdev labels.

NAS arrays store their geometry in on-disk metadata that must be parsed before any filesystem can be mounted. We detect these parameters from cloned images rather than trusting the NAS operating system, which protects against cases where the vendor configuration database has desynced from the actual array state.

mdadm Superblock Versions and Safe Commands

Linux mdadm stores RAID parameters in a superblock whose position depends on its version. Per md(4), version 0.90 is written into a 64K-aligned block that starts at least 64K and less than 128K from the end of the device. Version 1.0 sits between 8K and 12K from the end, on a 4K boundary.

Version 1.1 sits at the start of the device. Version 1.2, the modern default, sits 4K from the start.

When superblocks are intact, we read them with mdadm --examine /dev/sdX to print the metadata stored on each device. For virtual assembly we use mdadm --assemble --readonly to start the array read only. We never use mdadm --create on a recovery target because it writes new metadata to each device and starts a resync. When superblocks are missing, we scan for filesystem magic bytes to determine the data offset and reconstruct the geometry virtually.

LVM Physical Volume and Volume Group Metadata

QNAP QTS and Synology SHR both layer LVM above mdadm. By default the LVM2 label sits in the second sector of each physical volume. When LVM metadata is damaged, we parse the raw PV headers on the clones to rebuild the VG layout.

ZFS Vdev Labels, Uberblocks, and DDT RAM Requirements

ZFS writes four copies of the vdev label on each disk, two at the start and two at the end.

The second half of each label is an array of uberblocks, updated whenever a transaction group commits. We read the vdev labels directly from cloned members to reconstruct the pool topology, then look for the newest intact uberblock.

ZFS deduplication creates a Deduplication Table, and holding it in ARC takes roughly 1 to 5 GB of RAM per 1 TB of deduplicated data. The DDT is stored on disk and read on demand, so a pool whose DDT doesn't fit in RAM still imports. iXsystems says loading the table on demand can take days after an import or reboot. That's a RAM-sizing problem, and the platters aren't at fault. Reading existing data doesn't need the DDT.

So for recovery we import the pool read-only. Running zdb -lu /dev/sdX against a member's block device prints that device's vdev labels and uberblocks. If the SLOG device fails after a sudden power loss, the synchronous writes that were in flight are gone for good. That loss has nothing to do with the pool structure, and nobody can get those writes back from the main vdevs.

For a pool that won't mount, we walk through the read-only import step by step in TrueNAS zpool import recovery.

How We Handle Encrypted NAS Arrays

We clone every member, reconstruct the RAID and LVM layers offline, then decrypt using the client-provided key. If the key is lost, the data can't be recovered.

1. Clone every member drive. Our recovery process for encrypted NAS volumes follows the same imaging-first workflow.
2. Reconstruct the RAID and LVM layers offline from the cloned images and assemble the encrypted volume.
3. Decrypt with the encryption key, passphrase, or exported key file you give us. If the key is lost, the data stays encrypted, and no lab can recover it, ours included.

Why Choose Rossmann Group for NAS Recovery?

Rossmann Group uses PC-3000 and DeepSpar imaging hardware in a single Austin lab with no evaluation fees. If we can't recover usable data, you owe $0.

NAS Recovery for IT Administrators, MSPs, and In-House IT Teams

Business NAS arrays carry production databases, client deliverables, and operational records that cannot be reconstructed from other sources.

Compliance Certifications

We aren't HIPAA certified, & we don't sign Business Associate Agreements.

We aren't SOC 2, ISO 27001, FedRAMP, or FERPA certified either. The controls we do have are documented on our data security page. If your compliance requirements mandate any of those certifications, use a lab that holds them.

Multi-Array Pricing

Per-array pricing follows the published per-member tiers and the $400-$800 array reconstruction fee documented in the pricing table above. RAID geometry sets the minimum member count, so RAID level effects on NAS recovery pricing maps each layout to the drives it puts on the invoice.

For enterprise rackmount arrays specifically (Synology RackStation, QNAP enterprise series, and full server platforms), the per-member logical work is identical to consumer arrays, but helium-sealed mechanical work uses helium HDD pricing. Helium cost: $400-$800 additional for head swap and surface damage tiers. This covers the helium refill required after opening the sealed chamber. TrueNAS and FreeNAS rackmount units running OpenZFS pools are covered under TrueNAS server data recovery.

Expedited Turnaround

A $100 rush fee moves your work to the front of the queue.

Rush priority doesn't shorten mechanical work or donor sourcing, because head swaps and donor matching have physical lead times.

Engagement Inquiry

Email help@rossmanngroup.com or call (512) 212-9111 with the array list, RAID level, member count, drive models if known, and any prior rebuild or repair attempts.

There's no diagnostic fee. The evaluation is free. For RAID-only engagements where the array is built directly on a server controller (not a NAS appliance), the same intake workflow applies.

Lab Data Recovery by Rossmann Repair Group

NAS Recovery by Manufacturer

We recover data from Synology, QNAP, Buffalo, ASUSTOR, Unraid, TerraMaster, WD My Cloud, Netgear ReadyNAS, and Drobo devices. Each manufacturer uses a different storage stack, RAID implementation, and filesystem layer, and we match the recovery workflow to the architecture of the failed device.

QNAP TS-Series and QuTS Storage Architecture

QNAP devices use a multi-layered storage stack that complicates recovery beyond standard RAID reconstruction. A QNAP running QTS uses the Linux md driver for basic RAID redundancy, then wraps the array in LVM (Logical Volume Manager) for volume management. QuTS hero models replace that md and LVM stack with native ZFS.

When a QNAP fails, the built-in QTS/QuTS repair options try an in-place reconstruction that writes to members that are already degraded. We start by pulling the drives and imaging each one on PC-3000 hardware.

From the cloned images, we virtually reassemble the md-raid array, manually parse LVM physical volume headers and logical volume records, and locate the actual filesystem layer (EXT4 on QTS, ZFS on QuTS hero). Only after all metadata layers are verified do we extract files from the reconstructed volume.

Synology Hybrid RAID (SHR) and Btrfs Reconstruction

Synology DiskStation Manager (DSM) uses SHR (Synology Hybrid RAID) to allow mixed-capacity drives in a single storage pool. SHR works by partitioning each drive into multiple segments and creating separate mdadm arrays from matching-size partitions, then combining them under LVM. SHR-2 adds dual parity (functionally equivalent to RAID 6) for two-drive fault tolerance.

This multi-layer partitioning means a Synology with mixed drives may contain several separate mdadm arrays stitched together, each with different member assignments.

Btrfs stores filesystem metadata in B-trees distributed across the underlying block devices. Recovering a Btrfs-on-SHR volume requires reconstructing each mdadm superblock from member images, reassembling the LVM layer, and then parsing the Btrfs chunk tree and device tree to map logical addresses to physical locations on the cloned images.

On Synology volumes formatted EXT4, we do journal-based recovery instead. We reconstruct the EXT4 journal and inode tables from the assembled array image.

We never perform in-place SHR rebuilds on degraded pools. On SHR-1, a second drive failing during the rebuild loses the array. We image first and reconstruct offline from the clones, which avoids that risk.

Enclosure-Level Hardware Risks by Brand

Each NAS brand has distinct enclosure-level risks that affect intake handling and recovery workflow. Understanding these risks before shipping prevents common mistakes such as shucking encrypted drives or initializing corrupted arrays.

Synology NVMe Cache Dropouts

On Synology Plus units, when an NVMe drive acting as a dirty write cache drops off the PCIe bus, its uncommitted writes are permanently lost. The hard drive array is left with an incomplete, corrupted Btrfs filesystem, and DSM reports it as Volume Crashed.

QNAP Partition 1 Corruption

QNAP stores the configuration database that maps storage pools to the mdadm arrays on partition 1 of the member drives. When a failed firmware update corrupts partition 1, the interface reports the pools as empty or uninitialized while the user data on partition 3 is intact. We reconstruct the array directly from the mdadm superblocks and LVM headers on the drive clones.

WD JMicron & Symwave Bridge AES

WD My Book and My Passport USB external drives apply always-on AES in the USB-to-SATA bridge chip (JMicron JMS561, JMS538S, or Symwave SW6316) even when the user never set a password. Shuck the drive and connect it directly to SATA, and you get ciphertext, not data. WD My Cloud NAS units are a different architecture: embedded Linux on mdadm & ext4 with no bridge-chip encryption. Unless the user enabled software volume encryption in the dashboard, the ext4 data is plaintext and a removed drive mounts directly in a Linux recovery rig. My Cloud Home is separate again: it renames every file to a 64-character hex content ID, with the original names and tree held in a proprietary SQLite index.db.

Buffalo's Emergency Mode

Buffalo TeraStation units enter Emergency Mode after firmware corruption on the boot partition. Power down immediately. TeraStation units predominantly use XFS over mdadm, and XFS metadata is sensitive to interrupted writes. That's why we do the replay offline, from the clones.

TerraMaster TOS Boot Corruption

TerraMaster TOS firmware corruption can leave the interface unable to recognize existing arrays, and then it prompts you to initialize the drives. The TRAID metadata (a wrapper around mdadm and LVM) may still be intact on the data partitions, but the initialization prompt is dangerous. We image every member before the NAS writes anything, then reconstruct the mdadm/LVM stack from the clones without trusting the corrupted boot metadata.

Proprietary Filesystem Claims vs Open-Source Reality

Synology DSM, QNAP QTS, TrueNAS, and Asustor ADM all run on documented open-source stacks: Linux mdadm, LVM, Btrfs, ext4, and OpenZFS. These filesystems have public source code.

Recovering them takes forensic parsing of those open-source formats. Proprietary vendor access doesn't come into it.

The same btrfs-find-root, zdb, and mdadm utilities are available to every qualified lab. What separates one lab from another is whether it diagnoses the fault accurately, publishes its prices, and images the drives in-house on PC-3000 and DeepSpar hardware instead of running network scanning tools.

A direct comparison of OpenZFS against controller-based hardware RAID is laid out in ZFS versus hardware RAID.

Recovery by Symptom

Lab Location and Mail-In Service

All NAS recovery work is performed in-house at our lab: 2410 San Antonio Street, Austin, TX 78705. For clients outside Austin, we accept mail-in shipments from all 50 states. Your drives stay in our lab under chain-of-custody from intake through delivery.

Walk-in evaluations are available Monday - Friday, 10 AM - 6 PM CT. For clients outside Austin, we accept mail-in shipments from all 50 states. Your drives stay in our lab under chain-of-custody from intake through delivery.

How We Handle Your Drives

NAS arrays contain business files, client deliverables, and records that cannot be re-created from other sources. Every drive that enters our lab follows the same custody protocol regardless of array size or data sensitivity.