If your QNAP NAS has unmounted its storage pool, fallen victim to DeadBolt, Qlocker, or eCh0raix ransomware, locked you out after a QTS firmware update, or refused to import its volumes after a QuTS Hero migration, you’ve reached the right team. QNAP is one of the two dominant prosumer and small-business NAS brands we see at the lab (alongside Synology), and QNAP cases represent a substantial share of the NAS recovery work we handle — both because the deployed fleet is so large and because QNAP units have been disproportionately targeted by ransomware campaigns over the past five years. Gillware has been recovering data from QNAP TS-series, TVS-series, and TS-h-series units since the early QTS releases, from our ISO 5 Class 100 cleanroom in Madison, Wisconsin. QNAP cases are scoped at intake by an engineer who has handled the failure mode you’re looking at — not by a generic sales gate. See also our NAS data recovery hub.

Open a QNAP recovery case →

How QNAP NAS Devices Work

QNAP ships two architecturally distinct NAS operating systems on the same general hardware lineup, and identifying which one your unit was running is the first step in scoping a recovery.

QTS — the original QNAP operating system. The standard QNAP operating system that ships on most consumer, prosumer, and small-business models. QTS is built on an embedded Linux kernel with the QNAP-specific management layer (QTS itself), running mdadm software RAID with LVM volume management and ext4 as the filesystem. Storage pools sit on top of mdadm arrays, with thick or thin volumes layered on top of the storage pool. This stratified architecture is similar in spirit to Synology’s DSM but with QNAP-specific layout and management choices throughout.

QuTS Hero — the ZFS-based variant. Released in 2019 and now standard on the TS-h-prefix models, QuTS Hero replaces the mdadm-plus-ext4 stack with ZFS. The storage pool is a ZFS pool with raidz, raidz2, raidz3, or mirror vdev topologies. Filesystem-level features like checksumming, copy-on-write snapshots, compression, deduplication, and self-healing are native to ZFS rather than added by the management layer. QuTS Hero recovery has fundamentally different characteristics than QTS recovery because ZFS pool imports, vdev fault states, and ZFS-specific corruption modes are different from anything in the QTS lineage.

Model lineup we recover. The active QNAP fleet we see is dominated by the TS-series desktop NAS line. Common two-bay models include the TS-228A, TS-230, TS-233, TS-251, TS-251D, TS-251+, TS-253, TS-253D, TS-253Be, and TS-264. Common four-bay models include the TS-431, TS-431P, TS-431X, TS-431KX, TS-453, TS-453Be, TS-453D, TS-453Bmini, and TS-464. Common six- and eight-bay models include the TS-653, TS-653D, TS-664, TS-832X, TS-832PX, and TS-873A. Common older models still in deployment include the TS-209, TS-219, TS-410, TS-419, TS-509, TS-559, and the TS-x10 / TS-x12 / TS-x19 / TS-x20 generations from the 2010 through 2015 production window. The TVS-series (TVS-471, TVS-672, TVS-872, TVS-h1288X) is the prosumer/SMB tier with more capable hardware; we also see TVS units regularly. QuTS Hero ships on TS-h-prefix models including the TS-h973AX, TS-h1290FX, and the TVS-h-prefix variants.

The administrative surface. QNAP’s web interface is accessible through the unit’s IP address on the local network, with QNAP’s Qfinder Pro utility used for discovery and initial configuration. Snapshots, storage pools, volumes, and shared folders are all administered from the same web interface. SSH access is available but disabled by default. Events are written to QTS or QuTS Hero system logs accessible through the web interface, and several distinct failure states surface in those logs with QNAP-specific terminology that we cover below.

QNAP Failure Conditions That Lead to Data Loss

The patterns below are the ones that disproportionately bring QNAP cases to our lab.

Storage pool unmounted (QTS). The most common QTS error state we see. The Storage & Snapshots admin panel reports the storage pool as “unmounted” or “inactive,” shared folders are inaccessible from the network, and the unit may show the volume in red. The underlying cause is usually multi-drive failure beyond the pool’s redundancy, mdadm superblock damage on a single drive that escalated, or ext4 filesystem corruption that QTS couldn’t navigate cleanly. The data on the underlying drives is generally intact — the path through QTS to it is what’s broken.

Storage pool offline / pool faulted (QuTS Hero). The ZFS equivalent of the QTS storage pool unmounted state. The pool reports a faulted or unavailable status, the vdev backing the pool shows missing or faulted members, and the dataset cannot be mounted. ZFS pool faults are different from mdadm RAID failures in that ZFS may continue to operate degraded across a wider range of conditions before declaring the pool faulted — but once the pool faults, the recovery path is fundamentally different from anything in the QTS world.

DeadBolt ransomware. The most consequential ransomware campaign targeting QNAP. Starting in January 2022 and continuing across multiple waves through 2022 and 2023, DeadBolt exploited a series of vulnerabilities in QNAP firmware (CVE-2022-27593 and others) to gain access to internet-exposed QNAP units, encrypt user files with the .deadbolt extension, and overwrite the QTS admin login page with a ransom demand. QNAP issued multiple emergency firmware updates that effectively force-applied patches and broke some functioning configurations as a side effect. Recovery from DeadBolt depends on the variant, the time window between infection and detection, and whether snapshots from before the encryption exist and are reachable — DeadBolt did not always destroy snapshots, and pre-event snapshots are sometimes the cleanest path back to a known-good state. Where snapshots aren’t available, file-level forensic recovery can sometimes resurrect files that were partially written during the encryption process.

Qlocker ransomware. An earlier QNAP-targeting campaign from April 2021 that took a different approach: instead of encrypting files in place, Qlocker bundled user files into 7-Zip archives protected by a generated password. The original files were deleted after the archive was created. Recovery options depend on whether the underlying ext4 free space has been overwritten in the time since — the deleted source files are sometimes still recoverable from the filesystem’s free regions if the unit hasn’t been heavily used since the event.

eCh0raix and Muhstik ransomware. QNAP has been hit by recurring eCh0raix waves (2019, 2020, intermittent through 2024) and by Muhstik (2019-2020). The exposure surface in each case has been a different unpatched CVE in QTS, and each wave has produced its own set of file extensions, ransom demands, and pre-encryption file deletion patterns. Recovery scoping starts with identifying which variant hit the unit and what its specific file-handling behavior was.

QTS update failure or QuTS Hero migration issues. QTS updates are usually low-risk, but several specific QTS 5.0 and QTS 5.1 builds have been documented as causing post-upgrade volume mount failures on units that had been running stably on QTS 4.x. The migration path from QTS to QuTS Hero is more involved — QuTS Hero requires reformatting the storage pool (ZFS replaces ext4), so the migration is not in-place. Cases that come to us are typically units that attempted an unsupported migration or that hit corruption during a supported migration, with the data partition in an inconsistent state.

Long beep at boot followed by hang. The QNAP chassis emits beep codes during boot. A long single beep followed by the unit failing to reach a usable state is the signature firmware-corruption or boot-failure pattern. The data on the drives is generally intact; the QTS firmware on the system partition is what’s failing to load. We see this pattern on aging units where the system partition has accumulated errors, and on units where a power event interrupted a write to the firmware region.

Multi-drive failure beyond fault tolerance. The same condition that takes down standard RAID arrays applies to QNAP. QTS pools on RAID 5 tolerate one drive failure; RAID 6 and SHR-2-equivalent configurations tolerate two; raidz on QuTS Hero tolerates one per vdev; raidz2 tolerates two. We see this pattern most often on units in service for five to ten years with the original drive cohort. First drive fails, the pool drops to degraded, the user inserts a replacement drive and starts a rebuild, a second drive fails mid-rebuild, and the pool drops to unmounted. Surviving drives are often only partially failed, which is why cleanroom imaging frequently resurrects enough of a failed-status drive to make recovery possible.

SMR drive issues on TS-251D, TS-253D, TS-453D, and similar. Several QNAP models from the 2019 through 2022 production window were sold with or commonly populated by shingled-magnetic-recording (SMR) consumer drives that handle the rebuild workload poorly. On a degraded SMR-equipped array, the rebuild operation generates sustained random write patterns that SMR drives can’t keep up with, leading to timeouts that QTS interprets as drive failures. The result is a “second drive failure” during rebuild that is sometimes an actual failure and sometimes the SMR drive being unable to keep up with the rebuild I/O. Either way, the pool drops offline. Recovery requires correctly identifying which drive was actually first-failed versus which was timeout-flagged and assembling from the imaged set accordingly.

Snapshot pool corruption on QuTS Hero. ZFS snapshots on QuTS Hero are integrated into the storage pool itself — they share the pool’s vdev topology and metadata structures. When the snapshot subsystem hits a corruption pattern that ZFS can’t navigate — from a partial write during a power event, from a bug in a specific QuTS Hero build, or from filesystem-level damage that propagated — the pool can become unimportable even though the underlying vdev members are intact. Recovery requires ZFS-specific tooling and an understanding of QuTS Hero’s snapshot semantics, both of which are outside the scope of generic NAS recovery tools.

Failed migration between models. A common QNAP failure: an owner with a working older QNAP (TS-251, TS-431) buys a newer model (TS-464, TS-664) and migrates the drives expecting a seamless transfer. QNAP documents migration paths and compatibility, but field cases that arrive at our lab are the ones outside the documented paths, or inside the documented paths that didn’t complete cleanly. Symptoms include the destination QNAP refusing to recognize the storage pool, prompting to reinitialize the drives, or appearing to import but mounting inaccessibly.

Container Station and Virtualization Station data. QNAP supports running Docker containers (Container Station) and full virtual machines (Virtualization Station) directly on the NAS. When the NAS fails, the container volumes and VM disk images that lived on the storage pool are part of the recovery scope, not separate from it. We routinely recover VMDK and QCOW2 disk images from QNAP storage pools alongside the conventional file shares. The container or VM contents inside those disk images are then accessible after the recovery, the same way they would be on a working NAS.

Encrypted shared folders. QNAP supports per-shared-folder AES-256 encryption. When a customer has enabled encryption on a folder, recovery requires the encryption passphrase or the exported encryption key. The encryption is real; the key cannot be recovered from the drives alone. Encrypted-folder QNAP cases need to ship with the passphrase or the key file, otherwise even a successful recovery delivers only encrypted data.

HBS 3 and Hybrid Backup Sync data. QNAP’s backup-and-sync stack (HBS 3, Hybrid Backup Sync) stores backup repositories on the NAS itself or on attached external drives. When the NAS fails, the backup repositories may be the cleanest recovery path back to a known-good state — particularly in ransomware scenarios where the live volume is encrypted but a backup repository wasn’t reachable from the ransomware’s path. Identifying which backup repositories exist, which are reachable, and which are intact is part of our recovery scoping.

Drive replacement and rebuild failures. A drive fails on a redundant QNAP array. QTS marks the pool degraded. The owner inserts a replacement drive and starts a rebuild from the Storage & Snapshots interface. The rebuild reads every surviving sector across the remaining members and copies into the new drive. If a read error appears on a surviving member during the rebuild, the rebuild aborts and the pool can drop to unmounted state.

Power surge and unclean shutdown. QNAP units handle unclean shutdowns reasonably well most of the time, but a sufficient power event can damage the controller board, multiple drives, or both. The pattern we see is “the QNAP came back up after the storm with two failed drives” — sometimes both are actually failed, sometimes only one is and the other has been flagged by QTS as a precaution. Cleanroom evaluation determines which drives are truly failed.

Older hardware reaching end-of-life. TS-209, TS-219, TS-410, TS-419, TS-509, TS-559 units from the 2009 through 2013 production window are now twelve to seventeen years old. Capacitor failures on the power supply boards are increasingly common, and the original drives in these units have long since aged past any reasonable expectation of continued service. We see these older QNAP units coming in with capacitor-failure power symptoms and drive cohort failures concurrent with hardware end-of-life.

One pattern worth naming separately. The standard QNAP Support and community-forum guidance for unmounted storage pools, post-update mount failures, and degraded RAID conditions is usually a combination of “run the storage pool repair function,” “reseat the drives in a specific order,” or “create a new pool and restore from backup.” Those steps work cleanly when the array is healthy underneath. When the underlying condition is multi-drive degradation, snapshot corruption on QuTS Hero, or a ransomware event where the snapshot history is the recovery path, the same steps destroy the data the customer called to save. The real decision in front of a downed QNAP is not “QNAP Support versus recovery shop” — it is “execute the documented repair now and accept whatever happens” versus “image the drives first and recover before any further controller-side action.”

How We Recover QNAP NAS Arrays

We never operate a failed QNAP NAS during recovery. Running a degraded array, attempting a storage pool repair, or letting the unit auto-rebuild during diagnostic work all risk turning a recoverable case into an unrecoverable one. Each drive is removed from the chassis, bay positions documented, and imaged on isolated, write-blocked hardware in our cleanroom. Physically damaged drives are repaired with donor parts as needed before imaging — head replacements, PCB swaps, firmware recovery, and platter burnishing where the surface has been damaged. We work from drive images for everything that follows; the originals stay shelved and untouched.

Once we have a verified image of every drive, our reconstruction work begins. HOMBRE — Gillware’s in-house RAID and filesystem reconstruction software, built and maintained by the engineers who use it — inspects every single sector of every drive image, identifying the QNAP-specific partition layout, parsing mdadm superblock structures (for QTS) or ZFS labels and vdev metadata (for QuTS Hero), reconstructing the LVM and filesystem layers above, and assembling the storage pool virtually from the drive images. We don’t depend on a working QNAP chassis to read the data; HOMBRE reads it directly from the drives.

On QTS arrays specifically, HOMBRE reads the QNAP partition layout, reconstructs the mdadm RAID virtually, navigates the LVM volume group structure, and recovers the ext4 filesystem above it, including any thick or thin volumes that were configured on the storage pool. Where QNAP’s flexible volume system has created multiple volumes on a single pool, each is recovered independently. On QuTS Hero arrays, the recovery proceeds through ZFS pool import from the drive images, reconstruction of the vdev topology (raidz, raidz2, mirror as applicable), and dataset extraction including snapshot history when present.

On ransomware cases (DeadBolt, Qlocker, eCh0raix, Muhstik), the recovery scope expands to include identifying which files were touched by the ransomware, which file regions are recoverable from snapshot history that survived the event, and which files can be partially salvaged through forensic reconstruction of the pre-encryption state. Where backup repositories from HBS 3 or Hybrid Backup Sync survived on attached storage, those repositories are part of the recovery scope as well.

The engineers running this work see the failure modes catalogued above on a weekly basis. There is no QNAP condition on this page that we are encountering for the first time. HOMBRE assembles the array as a virtual volume from the images, and the filesystem layer is recovered against the assembled volume. The deliverable is a file list and an outcome you can act on, rather than a QNAP that’s been talked back into mounting and then expected to keep working.

Related Pages

By NAS brand: WD NAS · Synology · Buffalo NAS · Drobo · LaCie · FreeNAS / TrueNAS. Related topics: Ransomware recovery (especially relevant for DeadBolt, Qlocker, and eCh0raix QNAP cases). By RAID level: RAID 5 · RAID 6 · RAID 10. Return to the NAS data recovery hub for the full overview.

Start Your QNAP NAS Recovery

If your QNAP is offline and the data on it matters, the next step is to power it off and start a free evaluation. Before shipping:

  • Power the unit off. Continued boot attempts on a unit with a failing drive cohort or an unmounted storage pool can compound the problem.
  • Do not pay the ransom if you’ve been hit by DeadBolt, Qlocker, eCh0raix, or any other QNAP-targeting ransomware. Decryption is unreliable even when the ransom is paid, and recovery options through cleanroom reconstruction and snapshot history are often a better outcome than the gamble of paying.
  • Do not run the QTS “Storage Pool Repair” or “Volume Repair” function in an attempt to fix an unmounted pool. The repair tools can work on cleanly-degraded arrays and can make unmounted pools harder to recover.
  • Do not run zpool import, zfs rollback, or any ZFS recovery commands against a QuTS Hero unit’s drives. ZFS recovery operations are easy to issue and difficult to reverse.
  • Do not initialize, reset, or rebuild the storage pool from the Storage & Snapshots interface.
  • Do not insert replacement drives into a unit that has dropped its array offline.
  • Do not run a firmware update in an attempt to fix the problem — especially if you’ve been hit by ransomware. The post-incident QNAP firmware updates have broken some configurations as a side effect.
  • Label each drive with its bay position before removing it from the chassis. Bay order matters for QNAP reconstruction.
  • Note your model number, QTS or QuTS Hero version, and any ransomware variant (look at the file extensions and any ransom-note files left behind for ransomware identification). If you have encrypted shared folders, have the passphrase or key file ready — we cannot recover encrypted data without it.
  • Ship the full set of drives together, in original or equivalent anti-static packaging. We don’t need the QNAP chassis or the power supply.

Open a case or call and you’ll reach our recovery team. The initial scoping call covers feasibility, recovery approach, and turnaround.

Open a QNAP NAS recovery case →

Single-bay QNAP recoveries operate on our standard “no data, no charge” engagement: if the recovery is unsuccessful, you don’t pay for the work. Multi-bay QNAP recoveries (any unit with two or more drives in a redundant configuration) carry an engineering deposit to cover the reconstruction work, with the full price disclosed in the quote before you authorize the recovery. QuTS Hero ZFS recoveries and complex ransomware cases may carry higher engineering deposits reflecting the additional reconstruction work involved — all disclosed in the quote.

Prefer to talk to someone first? Call 1-877-624-7206 during business hours (M–F 8 am–7 pm, Sat 10 am–3 pm Central), or schedule a 15-minute consultation with a client advisor.