QNAP NAS Recovery Singapore

QNAP NAS units run QTS over RAID and LVM (often thin-provisioned) volumes on ext4. When QTS reports a crashed or unmounted volume — or a thin pool fails — the underlying data is usually intact and recoverable, but QTS will offer to "reinitialise" or "recover", which can overwrite what we need. QNAP has also been a repeated ransomware target (DeadBolt, Qlocker), where recovery focuses on unaffected copies and originals rather than decryption.

CBL reconstructs QTS/LVM and the ext4 filesystem directly from the member disks in our lab, so your shared folders and backups come back safely.

Almost every unrecoverable QNAP that reaches our bench was recoverable a few hours earlier. These are the actions that closed the door, and the mechanism behind each one.

• Inserting a fresh disk and letting QTS rebuild. A rebuild writes parity across every member. If the array was assembled in the wrong order, or a surviving member has bad sectors, it calculates wrong data and writes it permanently over good data. See RAID 5 failure recovery.
• Running a file-system check on the live volume. e2fsck and QTS's own repair option write corrections straight to the volume. When the LVM layer underneath is what is actually damaged, those corrections land at the wrong offsets and multiply the damage.
• Pulling every disk out to have a look. Bay order is part of the array definition. Once the disks are shuffled and unlabelled, the original order must be worked out by analysis — time that lands on your quote.
• Updating firmware to fix a fault. A QTS update rewrites the system partition mirrored across all members. If the volume was already unmountable, the update will not fix it; it only adds writes.
• Pointing desktop recovery software at the raw disks. Windows tools do not understand Linux md RAID or LVM. They see unformatted disks and offer to initialise them — one accepted prompt writes a fresh partition table over the array headers.

Warning signs, and what each one usually indicates

QNAP rarely fails silently. The difficulty is that the message on screen and the actual fault are often two different things.

• "Volume is not active" or "Volume crashed". QTS can see the disks but cannot mount the file system on them — usually a member has dropped out of the RAID group, or the LVM metadata mapping the volume onto the pool is damaged. The files themselves are normally untouched.
• Shares vanish but the web interface still loads. The QTS system partition is mirrored across every disk, so the appliance stays alive while the data volume does not. That is a good sign: the disks are still spinning and readable.
• Continuous beeping and a red status LED. A member has failed or been ejected. In a single-redundancy array you are now one failure from losing the volume outright, which is exactly why leaving it running is the risk.
• Boot loop. Usually a corrupt firmware image or a failing internal flash module rather than a data problem. The data disks are typically fine.
• Free space collapses and the volume flips to read-only. A thin-provisioned pool has run out of blocks to allocate and QTS has frozen it. Deleting files often does not release space, because the pool must reclaim it first.
• Clicking or grinding from one bay. Mechanical failure inside a member drive. That disk needs cleanroom work before it can be imaged.

People search for this problem in half a dozen ways, and nearly all of them describe the same situation: a QNAP that will no longer hand over its files. If any of the phrases below match what you typed, you are in the right place.

"QNAP data recovery", "QNAP NAS recovery Singapore"

These are the same service. QNAP data recovery means extracting your shared folders from the member disks, whether the fault is a failed drive, a broken array, a damaged file system or corrupt firmware. The word "NAS" adds nothing technical — it only tells us the disks lived in a network appliance rather than a PC. What genuinely changes the work is the number of bays, the RAID level, and the volume layout underneath.

"QNAP repair" versus "QNAP recovery" — the distinction that matters

This is the confusion worth settling, because the two jobs pull in opposite directions.

• Repair puts the appliance back into service. Swapping a disk, letting QTS rebuild the array, reinstalling firmware. Every one of those steps writes to your disks.
• Recovery gets the data out. We never write to your disks. We image them, then reconstruct the array and file system from the copies, with your NAS switched off throughout.

An IT vendor asked to "fix the NAS" will reasonably reach for repair first, because that is the brief they were given. If the data is not backed up elsewhere, ask for recovery first and repair afterwards. Once a rebuild has run across a degraded array, some of what we would have used is already gone.

"QTS volume recovery", "volume is not active", "volume crashed"

These are QNAP's own words, straight from the Storage & Snapshots panel. QTS volume recovery is what people call the job of bringing a volume back after QTS marks it inactive, degraded or crashed. Confusingly, QTS also has its own button labelled "Recover" — not the same thing, and on a damaged thin pool it can write over the very structures a lab would use.

"QNAP" is a brand, not a single design. Two units on the same shelf can store data in completely different ways — and that, rather than the model number on the front, decides how the recovery runs.

Model families we see most often

• TS-series desktop units — TS-231, TS-431, TS-453, TS-673 and variants. Two to eight bays, QTS on ext4, and the most common unit on our bench.
• TVS and TVS-h units. Often fitted with SSD cache. If write caching was enabled, data that never reached the array may exist only on those SSDs, so send them in too.
• TS-h models running QuTS hero. ZFS instead of ext4, and a different reconstruction path entirely.
• Rackmounts and TL/TR expansion chassis. More members to image, and a volume spanning an expansion unit will not assemble without those disks.

QTS on ext4 versus QuTS hero on ZFS

A standard QTS unit stacks three layers: a Linux md RAID group, LVM above it, and an ext4 file system inside. Each can fail independently, and each is rebuilt separately from the disk images. Ext4 is well documented and forgiving, which is why logical outcomes on QTS are usually good. QuTS hero swaps LVM and ext4 for ZFS — stronger in normal service, but when a pool refuses to import there is no quick file-system repair. Recovery means parsing the pool structures directly: slower work, less predictable, and we say so up front. The login banner tells you which you have.

Storage pools, thick volumes and thin volumes

Most QNAP volumes live inside a storage pool. A thick volume reserves its capacity up front, so its blocks sit in predictable places. A thin volume allocates blocks only as data is written, so the map of where each block physically lives is itself a structure on the disks — damage that map and perfectly healthy drives, full of intact data, can still be unreadable. Thin volumes are the harder case, and we check that map before quoting rather than after. Static volumes skip the pool layer and are the simplest of the three. For other brands see NAS data recovery, or Synology recovery for how SHR and Btrfs differ.

QNAP has been targeted by ransomware strains like DeadBolt and Qlocker. We're honest about this: modern strong encryption generally can't be decrypted without the key. What we can often recover is data from snapshots, unaffected volumes, and pre-encryption originals. Isolate the NAS, don't pay blindly, and let us assess it. See ransomware data recovery.

DeadBolt and Qlocker are not the same attack

Qlocker did not encrypt files in the usual sense — it swept shared folders into password-protected 7-Zip archives and deleted the originals. Deleted originals can sometimes still be carved from the disks, so these cases are worth assessing. DeadBolt encrypted files in place and replaced the QTS login page with a ransom screen. Both reached the NAS through internet-exposed QNAP services, not through anyone opening an attachment.

What a QNAP ransomware case looks like in our lab

We do not decrypt, and we will not pretend otherwise. What we do is image every disk, then work through everything the attacker did not reach:

• QNAP snapshots — often the best outcome, because they sit outside the normal write path and are frequently untouched.
• Volumes and USB backup drives that were not mounted at the time of the attack.
• Pre-encryption remnants. Where the malware wrote new files and deleted the originals, those original blocks may still sit unallocated on the disks.

Sometimes that adds up to most of the data. Sometimes it is very little. You get the honest answer after the free diagnosis, not before it.

Three routes people take with a dead QNAP. Here is what each one can actually do for you.