QNAP NAS Data Recovery Service

How We Recover Data from a Failed QNAP NAS

1. Free evaluation: We document your QNAP model, QTS or QuTS hero version, RAID level, number of members, encryption status, and any prior recovery attempts.
2. Member imaging: We image each member drive with PC-3000 or DeepSpar. If a drive has a mechanical or electronic fault, it gets a head swap or PCB work before we image it.
3. RAID metadata capture: We read mdadm superblocks (QTS) or ZFS uber-blocks and vdev labels (QuTS hero) from the member images. These contain the array geometry needed for reconstruction.
4. Offline array reconstruction: Using Data Extractor Express RAID Edition, we assemble the virtual array from cloned images. RAID parameters (stripe size, parity rotation, member order, data offset) are verified against the captured metadata.
5. Filesystem extraction: The EXT4 or ZFS filesystem is mounted from the reconstructed virtual array. Files are extracted, verified for integrity, and copied to the target media.
6. Delivery: We put your recovered data on your target drive or ship it back to you.

Common QNAP Error Messages and Failure Modes

• Inactive storage pool: QTS marks the storage pool inactive when it can't put together what sits underneath it: the mdadm RAID array, or the LVM layer on top of that array. This can follow a power loss, multiple disk errors, or a failed RAID rebuild. The data remains on the member drives.
• Degraded RAID Group: One or more member drives have dropped out of the array. If a second drive is weak, a rebuild can push it past the point of recovery. If that data is irreplaceable and you don't have a verified backup, power the NAS down instead.
• Failed Firmware Update / DOM Corruption: QNAP's Disk on Module (DOM) is a small internal flash device that stores QTS. A failed update can corrupt the DOM and leave the NAS unable to boot. Your data volumes are stored on the member drives, not the DOM. Our walkthrough of a bricked QTS firmware update covers why partition 1 configuration-database corruption desyncs the management UI while the partition 3 user data stays intact.
• Drive Not Detected / SMART Errors: Individual member drives developing bad sectors or firmware faults. These need professional imaging with tools like PC-3000 to extract readable data before reconstruction. When the unit reports QNAP drives not recognized across several bays at once after a failed firmware update, that's partition 1 configuration-database corruption. It isn't several drives failing mechanically at the same time.
• Red Status LED / Red Drive Bay LEDs: The chassis system status indicator is an aggregate signal for the whole unit, so it cannot name the member drive that is implicated. Per-disk identity comes from the per-bay drive indicators, the Storage & Snapshots manager inside QTS, & the system logs; at the block layer the member metadata settles it, meaning the mdadm superblocks on QTS or the ZFS vdev labels on QuTS hero. The pattern-by-pattern breakdown sits in our QNAP red light error triage guide. The light does not change the order of operations: image every member read-only first, then reconstruct offline, the same NAS array recovery process we run on every multi-bay unit.

What Do QNAP's Storage Terms Actually Mean?

QTS

QNAP's standard operating system. Linux kernel with mdadm software RAID, LVM2 thin or thick provisioning, and ext4 on top. Runs on consumer and SMB models such as the TS-453D and TS-673A.

QuTS hero

QNAP's ZFS-based operating system. Replaces the entire mdadm + LVM2 + ext4 stack with native OpenZFS. Runs on the TS-h and TVS-h models (TVS-h674, TS-h886, TS-h2490FU and similar).

SnapSync

It's a QuTS hero feature that copies data block by block from a primary unit to another QNAP NAS. In real-time mode, every write to the source also goes to the destination. Scheduled SnapSync runs at set intervals instead.

DOM (Disk on Module)

It's a small internal flash device on the QNAP motherboard. It stores the QTS or QuTS hero boot image. It does not store user data. A failed firmware update can corrupt the DOM and prevent the unit from booting while leaving member-drive data intact.

QuLog Center

It's QNAP's logging tool, and it collects your logs in one place. It keeps the event log, which records system, security, and application events, and it keeps the access log.

Storage Pool

The top-level container that aggregates one or more RAID groups under LVM2 on QTS or under a ZFS pool on QuTS hero. Volumes are carved out of a storage pool. A pool reporting as inactive does not mean the data is gone; it means the management layer cannot assemble the lower layers.

Qtier Auto-Tiering

A block-level tiering layer that relocates hot blocks from the HDD storage pool to an SSD group. Because those blocks are moved rather than copied, the HDD tier is structurally incomplete without the SSD tier. Failure of the SSD tier requires both the HDD members and the SSD drives to be sent in together. This is a different feature from a read-only SSD cache, which holds copies and can fail without leaving gaps on the HDDs.

Static Volume

A volume that consumes the full capacity of the underlying RAID group. No storage pool above it. Does not support snapshots or Qtier.

Thick Volume

A flexible volume inside a storage pool that reserves its full declared size at creation. QNAP builds it with its own "thick" LVM segment type. Stock Linux LVM doesn't recognize that segment type and won't activate the volume.

Thin Volume

A flexible volume that allocates blocks on first write through the LVM dm-thin target. The mapping is a binary B-tree in the hidden _tmeta device, not in the standard VGDA.

QTS vs QuTS Hero: What Changes for Recovery?

Knowing which operating system the unit ran before failure determines the first hour of work. QTS jobs start with mdadm --examine on cloned images. QuTS hero jobs start with vdev label inspection via zdb -l. The underlying RAID data recovery principles are the same; the metadata structures are not.

What happens to the data inside a TR-series QNAP expansion when the bridge chip fails?

QNAP lists the main chip on both as a micro processor with hardware RAID. That chip sits between the member drives and the USB-C uplink.

The bridge handles whichever RAID or JBOD abstraction that chassis advertises, and the array geometry (stripe size, member order, parity rotation if any) is configured by the bridge silicon.

When the bridge board dies, we either swap in a donor board on matching hardware or reconstruct the array in software from cloned images. We use Hakko FM-2032 and Atten 862 stations for the bridge-board work when a donor-swap is the right call.

When does moving QNAP drives to a new chassis destroy the array?

If you move the drives from a dead QTS chassis into a working one, it can ask to initialize them. Accept that prompt and QTS builds a new array over the member set. The previous superblocks are gone the moment it finishes.

There is no software recovery from that point; the chunk size, member order, and data_offset that were stored in those superblocks have to be reconstructed by other means, and a wrong guess at any one of them yields a striped reconstruction full of garbage that can look superficially like a partial filesystem.

Putting a QTS member set into a unit running QuTS hero, or the other way around, goes wrong in a different way that's just as destructive. The receiving OS doesn't recognize the other storage stack at all, and it will prompt you to initialize the drives into its own format. The fix in both cases is the same: don't put the drives into any working QNAP chassis until they've been imaged.

Our procedure is simple. We refuse to insert original member drives into any working QNAP chassis.

We image each member on a PC-3000 Portable III or PC-3000 Express. We run mdadm --examine on the cloned images to read the metadata version, recover the data_offset value, confirm the chunk size, and confirm the member order before any --assemble attempt.

The same metadata-overwrite trap applies on Synology and TerraMaster chassis under different brand names; the fix is the same on all of them.

QuTS Hero ZFS Specifics: Snapshots, SnapSync, RAID-TP, and Deduplication Risk

ZFS Snapshots and Transaction Group Rewind

ZFS is copy-on-write. It batches writes into transaction groups (txg) and doesn't overwrite the previous version until it's reclaimed. Snapshots are cheap pointers to older txg states.

When a pool fails to import, the most recent uberblock may point to an incomplete txg, but older uberblocks still reference fully consistent txg states. On cloned member images we read all valid uberblock copies (ZFS maintains a circular uberblock array in each of the four vdev labels), identify the newest self-consistent txg, and import the pool read-only against that state using flags of the form zpool import -F -o readonly=on -R /altroot.

If snapshots still exist, datasets can be rolled back to any retained snapshot. If an attacker or administrator issued zfs destroy on snapshots before we imaged the drives, those snapshots are gone; the underlying txg blocks may still exist on disk but no longer have a reference pointer.

SnapSync Replication Gaps

SnapSync is QNAP's block-level replication to another QNAP NAS. It runs in real time or on a schedule.

We image both source and destination and extract whichever side holds the more complete data. SnapSync replication is not a substitute for a full backup; if both units fail within a replication window, the destination may hold less data than the source.

Snapshot

A pointer to a frozen view of a ZFS dataset at one point in time. Lives in the same pool as the live data and shares storage with the live dataset through copy-on-write block sharing. Cheap to create. Useless if the pool itself fails to import.

SnapSync

QNAP's block-level replication from a primary QNAP to a destination unit on a schedule or in real time. The copy sits on a pool on another QNAP NAS. Survives the loss of the source pool. The destination is itself a ZFS pool with its own import requirements; we image both source and destination when one side fails mid-transfer.

RAID-TP (Triple Parity) Recovery

RAID-TP is ZFS raidz3 exposed through the QuTS hero interface. It tolerates the loss of any three drives. A RAID-TP pool with three simultaneous failures is still recoverable because the parity math can reconstruct the full stripe from the remaining members; however, a fourth failure during reconstruction is terminal.

When customers bring us a RAID-TP array with three dead drives, we image the surviving members first and rebuild the virtual pool offline before attempting anything on the damaged drives. This avoids converting a recoverable three-drive failure into an unrecoverable four-drive failure.

Deduplication and the DDT

QuTS hero supports inline block-level deduplication. The deduplication table (DDT) is an on-disk ZAP object that maps the hash of every deduplicated block to its physical location. It's stored in pool metadata.

You need roughly 1 to 5 GB of RAM per TB of deduplicated data to keep the DDT in ARC. If it doesn't fit, deduplicated writes and deletes slow down to on-demand disk lookups. The pool still imports. Reading existing data doesn't need the DDT, so a read-only import is the recovery path. If you run dedup, document the dedup ratio and dataset list before shipping the drives.

What Happens When a QuTS Hero ZIL or SLOG Device Fails?

If a QuTS hero pool loses its dedicated SLOG (Separate Intent Log) device during a sudden power loss, the pool itself usually still imports, but the synchronous writes that were acknowledged in the final seconds before power loss are gone.

ZFS batches writes into transaction groups (txg) & flushes a whole txg to the main pool at once. The ZFS Intent Log (ZIL) records synchronous writes, the kind databases, iSCSI targets, & NFS exports demand, so the write can be acknowledged to the client before the next txg actually lands on the pool.

By default the ZIL lives in-pool on the main vdevs. An in-pool ZIL survives power loss because those records were written to stable pool storage. A dedicated SLOG vdev moves the ZIL off the main disks to cut latency.

A dedicated SLOG holds writes that were already acknowledged but haven't been flushed to the main pool yet. If a non-protected SLOG drops those records when the power dies, they're gone. No command brings them back, because they were never written anywhere else.

Losing the SLOG does not destroy the pool. The on-disk pool is consistent at the last committed txg. Modern OpenZFS imports a pool with a missing or failed log device using zpool import -m, which brings the pool online & drops only the unflushed ZIL.

Forum advice that a lost SLOG means the whole pool is gone is wrong; it confuses an isolated log-device loss with the loss of a primary data vdev. The L2ARC read cache and the ZIL/SLOG write log are two different devices doing two different jobs.

So here is what is & is not recoverable. The pool, & everything committed through the last good txg, is recoverable. The handful of seconds of synchronous writes that lived only on a dead, non-protected SLOG & were never flushed to the main pool are not recoverable by any software command, because they were never written to the main pool in the first place. We will tell you that honestly rather than promise something the physics does not allow.

Our diagnostic starts the same way every ZFS job does. We image every surviving pool member using the PC-3000 Portable III or PC-3000 Express, or a DeepSpar Disk Imager.

On the cloned images we attempt zpool import -F to rewind to the last self-consistent txg, or zpool import -m to bring the pool up without the missing log device, & we inspect the ZIL records with zdb to confirm what the log actually held versus what reached the main pool before we commit to an import strategy. If your unit runs ZFS, our dedicated QuTS hero ZFS recovery guide walks through the rest of the pool-import decision tree.

QNAP Multi-Layer Storage Architecture: mdadm, LVM2, and Partition Offsets

Partition Layout on QNAP Member Drives

QTS partitions each member drive using a GPT layout with dedicated system partitions. Partition 1 holds the configuration database mirror, and partition 2 holds the swap array. These system partitions form their own small md arrays, and the configuration database mirrored across the drives lives on the /dev/md9 set built from partition 1.

Partition 3 on each drive (e.g., /dev/sda3) holds the user data. The mdadm superblock for the main storage pool lives within this partition boundary, not at the raw block device level.

LVM2 Layer Corruption and VGDA Metadata Loss

Once the mdadm array assembles from the partition 3 slices, QTS layers LVM2 on top of the md device. The LVM Physical Volume (PV) header is written directly to the assembled md device. At sector 1, the LABELONE magic string marks the start of the PV header, which contains a pointer to the Volume Group Descriptor Area (VGDA). The VGDA stores all volume group metadata in a ring buffer structure.

If someone runs pvcreate on the assembled md device, it overwrites the PV header and the VGDA. The mdadm array still reports as healthy and synchronized, but QTS reports the storage pool as inactive. The RAID layer is intact. The LVM layer above it is not.

Thick vs. Thin Provisioning: Different Recovery Paths

QTS supports both thick and thin LVM provisioning, and the recovery procedure differs between them.

• Thick provisioning: QNAP builds thick volumes with its own "thick" LVM segment type. Stock Linux LVM reports that as an unrecognised segment type and won't activate the volume.
• Thin provisioning (dm-thin): Virtual blocks are allocated on first write. The thin pool metadata lives outside the standard VGDA, in a binary B-tree inside a hidden logical volume (the _tmeta device). Check the pool type in the QTS storage manager, or on the images, rather than assuming which one you have.

We image every member drive through PC-3000 or DeepSpar imagers before touching any LVM metadata. All VGDA repair and thin pool reconstruction happens on cloned images, never on original media. QuTS hero replaces this entire stack with ZFS, which has its own pooling and volume management. The LVM architecture described here applies only to QTS.

What Happens When a QNAP Qtier SSD Tier Fails?

When QTS identifies "hot" data blocks with frequent read/write activity, it migrates them from the HDD RAID group to the SSD tier.

If you run Qtier, send us the HDD members and the SSD tier drives. The HDDs alone are not sufficient for a complete recovery.

QNAP Ransomware Recovery: Deadbolt, eCh0raix, and QLocker

• Deadbolt: It was first seen targeting QNAP in January 2022. QNAP's advisory QSA-22-24 links the campaign it detected on September 3, 2022 to CVE-2022-27593 in Photo Station. It lists fixed Photo Station builds for QTS 4.2.6 through QTS 5.0.1. Deadbolt encrypts files with AES-128-CBC and adds the .deadbolt extension. The samples Trend Micro analyzed are 64-bit Linux ELF files compiled in Go.
• eCh0raix / QNAPCrypt: It was reported brute-forcing QNAP NAS devices in July 2019. Unit 42 reported a 2021 variant whose attackers also used CVE-2021-28799, the improper authorization vulnerability in HBS 3, to deliver it. It encrypts files with AES in CFB mode and adds .encrypt to affected files.
• QLocker (CVE-2021-28799): Major campaign began the week of April 19, 2021. Unlike standard ransomware, QLocker does not use cryptographic malware. It runs the legitimate 7-Zip utility to move files into password-protected .7z archives, then deletes the originals. This means the original unencrypted files exist in unallocated space until overwritten.

Why You Should Never Initialize a QNAP Storage Pool After a Failure

1. When it initializes, QTS writes new mdadm superblocks to every member drive. The original superblocks, which contain RAID parameters like stripe size, parity rotation, and member ordering, are destroyed.
2. A new partition table replaces the existing one. The offsets to your data volumes are lost.
3. For QuTS hero (ZFS), initialization creates a new zpool with fresh uber-blocks and metadata. The original ZFS pool metadata is overwritten, and the Merkle tree linking to your data is severed.
4. Even a partial initialization makes recovery harder. The fewer writes to the original drives, the better the outcome.

If QTS presents an initialization prompt, power down the unit. Remove the drives and label each one with its bay number. The superblocks record member order. If they're damaged, we fall back on your bay labels. The same rule applies to every NAS recovery case: never accept a reinitialization prompt from any vendor's management interface.

Enterprise QNAP Deployments: RTO, RPO, iSCSI LUNs, and VMFS Carving

iSCSI LUN Recovery: Block-Level Reconstruction

QNAP serves iSCSI LUNs as either file-based images inside a storage pool volume or as block-based LUNs presented from the pool itself. When an iSCSI target database loses its LUN references, the underlying blocks are still on the array but the target daemon cannot locate them.

To recover the LUNs, we read the QNAP iSCSI target configuration off the cloned images and extract each LUN as a raw block image.

How does QNAP actually store a file-backed iSCSI LUN?

A QTS file-based iSCSI LUN is not a physical partition. It is a single large image file that lives inside a hidden LUN container directory on the underlying ext4 filesystem. Everything the iSCSI initiator sees as a raw block device is, on the NAS, just a large file sitting on a normal Linux volume. That distinction changes the recovery path, because there are two ways QNAP can back a LUN and they are extracted differently.

File-backed LUN

The LUN is a large image file stored on the ext4 volume that sits on top of the mdadm and LVM stack. To reach it you mount the ext4 volume and copy the file out as a raw block image.

Block-based LUN

The LUN is not a file sitting on a mounted volume; QNAP presents it from the storage pool itself. Confirm which of the two types you have from the storage manager or from the images before planning the extraction, because they are reached differently.

For the file-backed case the recovery is two distinct stages. Stage one reassembles the host stack: assemble the mdadm array and the LVM volume group from the cloned member images, then mount the ext4 volume read-only so no write ever touches the source. We start the array with mdadm --assemble --readonly against loop devices over the clones, never against the original drives. In that mode mdadm allows no writes, resync, recovery or reshape.

Stage two reaches the guest data inside the file. We find the LUN image file inside its container directory and extract it as a raw block image. Then we attach that image as a loop device with losetup and create device maps over its partitions with kpartx. At that point the guest filesystem inside the LUN (VMFS, NTFS, ReFS, ext4, or xfs) is reachable the same way it would be on a standalone disk.

VMFS and Guest Filesystem Carving Inside a LUN

Once we've recovered a LUN as a raw block image, it typically holds a guest filesystem: VMFS (VMware ESXi), NTFS (Windows Server), ReFS, or a Linux ext4/xfs. VMFS volumes hold VMDK files for each virtual machine; NTFS volumes hold VHDX files for Hyper-V.

On an isolated Linux host, we mount a VMFS volume straight from the recovered LUN image file with vmfs-fuse, or with vmfs6-fuse if it's a VMFS 6 volume. Otherwise we use loopback mounts. We then locate individual virtual disk files and extract the guest operating system's filesystem from inside the virtual disk. A LUN that holds VMFS makes the job two-layer: the outer layer is the QNAP storage pool, the inner layer is VMFS with VM disks. Both layers must be reconstructed in order before any guest data is readable.

RTO and RPO in Practice

Real RTO on a multi-drive QNAP enterprise case depends on the count of member drives, their condition, and whether guest-layer carving is required.

RPO is bounded by your snapshot and replication policy: if the last SnapSync or external backup ran two hours before the failure, RPO is two hours regardless of recovery duration. We report realistic RTO windows during the free evaluation rather than committing to figures that assume every variable breaks in the customer's favor.