NAS Symptom Recovery
QNAP Firmware Update Failure Recovery
Your QNAP NAS won't boot after a firmware update, or QTS shows an empty storage pool. A failed firmware update can corrupt the internal DOM flash and the configuration database on partition 1 of the member drives. The storage pool on partition 3 stays intact. We remove the drives, image each one through a write-blocker, reconstruct the mdadm or ZFS array offline, and extract your files. No data, no fee.
Does a failed QNAP firmware update destroy my data?
No. A failed firmware update can corrupt the internal DOM flash and the configuration database on partition 1 of the member drives, which makes QTS report an empty pool. The storage pool on partition 3 stays intact. If QTS offers to initialize the drives and you accept, initialization overwrites your RAID superblocks.
What Actually Fails During a QNAP Firmware Update
QNAP keeps most of the QTS firmware your NAS starts from on an internal DOM flash device. A firmware update writes the new image onto that DOM, & if the write gets interrupted, it can leave the DOM corrupted.
Internal DOM Flash
The DOM (Disk on Module) is a small flash storage device built into the NAS itself.
Your data on partition 3 is not being updated.
Known Bad QNAP Firmware Releases
QNAP has pulled releases before. QTS 5.2.2.2950 was withdrawn over issues with device functionality. There's also a problem that isn't tied to any single release. The Bay Trail J1800 and J1900 boards used by the TS-251, TS-451, and TS-651 have Intel's LPC clock degradation defect.
Recovery means bypassing the DOM entirely and reading the member drives directly.
Does QSA-26-10 Explain a Dead QTS 5.2.7 or QuTS hero h5.2.8 Unit?
Nothing in QNAP's advisory says so. QSA-26-10, dated 2026-06-17, lists QTS 5.2.7 & QuTS hero h5.2.8 among its affected releases. QNAP says CVE-2026-26241 is an excessively long filename, sent during chunked file uploads, that triggers a stack-based buffer overflow, "causing the affected CGI process to crash." CVE-2026-24720 needs an authenticated attacker, & QNAP says the result is high CPU & memory use that degrades system responsiveness.
The advisory describes no write to the DOM, to the md9 configuration array built from partition 1 of each member, or to partition 3 where your files live. A unit on an affected build that won't boot after an update, or that boots to an empty storage pool, gets diagnosed from the DOM & the member drives the same way as a unit on any other build.
QNAP's firmware recovery documentation gives a DOM test that needs no drives: "If NAS is not able to boot up without drives installed, and no long beep sound after 2-4 minutes, this means the firmware on the DOM has failed." With the bays empty, that test can't write anything to the members. A unit that passes it has a DOM that loads, so the investigation moves to the member drives & the partition 1 configuration database they carry.
If your unit still boots on an affected build, copy the data somewhere else before you install the patch; RAID isn't a backup.
Does QNAP firmware recovery touch the member drives?
No. QNAP's NAS Recovery Guide for the TS-328, TS-x28A, and TS-x30 series has you pull every drive tray before you boot a USB boot drive to recover the firmware. The procedure never reaches partition 3, where your data lives.
On the TS-328, TS-x28A, and TS-x30 series, QNAP's instruction is to hold the USB copy button and then press the power button to power the NAS on from the recovery disk. Check the guide that lists your model before you start.
Recovery Mode writes the DOM, never partition 3
QNAP only has you run firmware recovery when Qfinder Pro still can't detect the unit with all hard drives removed. The drives are out of the chassis during the recovery, so it doesn't touch Partition 3 on the member drives. A successful reflash leaves the mdadm arrays & their ext4 contents physically intact.
One detail separates this failure from a bay-level fault. When the partition-1 configuration database is damaged, QTS reports the entire pool at once as empty or uninitialized. The unit can't read the map that ties that pool to the mdadm arrays underneath it. If your QNAP boots QTS normally and shows one or more individual bays as empty, that's a different starting state. That is the fault covered on our QNAP drives not recognized page.
How Initialization After DOM Recovery Overwrites Array Metadata
If QTS offers to initialize the drives or create a new storage pool and you accept, initialization overwrites the array metadata on the member drives.
- Initialization writes new superblocks. Fresh RAID metadata lands on partition 3 of every drive. Under mdadm 1.2 the superblock sits 4 KB from the start of the partition; under 1.0 it sits at the end.
If you see any prompt to initialize, create, or format the storage pool after a firmware brick: power off the unit. Remove the drives, label each one with its bay number, and contact us.
QNAP Member Drive Partition Layout
On a QTS member drive, partition 1 carries the configuration database mirror and partition 2 the swap array. Partition 3 holds your data. Understanding this layout explains why a DOM failure does not affect your files.
| Partition | md Device | Contents |
|---|---|---|
sdX1 | md9 | QTS system config mirror. RAID 1 across all drives. |
sdX2 | md256 | System swap RAID. The configuration database lives on md9, not md256. |
sdX3 | its own md array | User data storage pool. |
For data recovery, only partition 3 (sdX3) matters. This partition contains the mdadm RAID array that holds your files. On QTS systems it is managed through LVM2 with an ext4 logical volume. The system partitions hold the QTS configuration database (md9) and swap (md256). Neither is needed for user data extraction.
QTS vs QuTS Hero: Different Recovery Paths After a Firmware Brick
QTS and QuTS hero sit on completely different storage stacks. The recovery procedure depends entirely on which OS was running before the failure.
QTS Recovery: mdadm + LVM2 + ext4
Standard QTS models store data on ext4 volumes atop Linux mdadm RAID with LVM2 in the middle. After imaging each member drive, we read the mdadm superblocks from partition 3 using mdadm --examine. The superblock contains the RAID level, chunk size, layout, member order, and data offset. We then assemble the array read-only with mdadm --assemble --readonly, activate the LVM volume group with vgchange -ay, and mount the ext4 logical volume read-only to extract files.
The chunk size comes out of the superblock rather than out of an assumption. So does the metadata version, and it matters: 1.0 places metadata at the end of the partition with data offset 0; 1.2 places metadata 4KB from the start with the data pushed further in.
The 0.90 superblock is 4KB long. It sits in a 64KB-aligned block 64KB to 128KB from the end of the device, & its data offset is 0, same as 1.0. It also caps an array at 28 component devices, & on RAID level 1 and above each component device tops out at 2TB. So both 0.90 & 1.0 keep the metadata at the end & the data at the very front of the partition.
We pull the real version with mdadm --examine on each cloned image first, then assemble read-only with mdadm --assemble --readonly against that exact metadata version. The same offset discipline carries across every Linux mdadm array we rebuild, QNAP or not.
QuTS Hero Recovery: ZFS Pool Import
QuTS hero models like the TVS-h674 and TS-h886 run ZFS. Every vdev label carries a ring of uber-blocks, & ZFS writes a new one each time a transaction group commits. When a pool fails to import, we clone every member and use zdb to walk the uber-block ring, identifying the most recent consistent transaction group.
We import the pool read-only against the chosen transaction group with zpool import -T <txg> -o readonly=on. If the pool ran deduplication, holding the Deduplication Table in ARC takes roughly 1 to 5 GB of RAM per 1 TB of deduplicated data. The table is stored on disk and read on demand, so the pool still imports on a smaller recovery workstation, but loading it on demand can take days.
We do this work offline against write-blocked clones: parse the vdev labels and the uberblock ring, pick the transaction group to roll back to, and import read-only. A DIY attempt that forces a writable import on the original drives advances the ring past the transaction groups the recovery depends on, and that is not undoable.
Because zpool transaction rollback and uber-block analysis are a separate discipline from QTS mdadm reassembly, we keep the full procedure on our QNAP QuTS hero ZFS recovery walkthrough.
QuTS Hero Pool Import After a Brick
QuTS hero leans on the ZFS Intent Log (ZIL) to record synchronous writes before they land in the main pool. By default the ZIL is allocated from blocks within the main pool. It lives on a separate SLOG device only when one was configured, such as an NVMe drive in a TS-h886.
ZFS writes its state in numbered transaction groups, and every vdev label keeps a circular ring of uber-blocks pointing at recent TXGs. From the cloned member images we parse that ring to find the last TXG that fully committed before the failed update, then roll the pool back to it.
zpool import -F throws away the last few transactions to get the pool back to an importable state. Adding -X goes to extreme lengths to find a valid TXG, & it can roll the pool back to one that isn't guaranteed to be consistent anymore. To target a specific group we use zpool import -T <txg>. Anything written in the discarded groups is gone. That is a deliberate, accepted tradeoff, done read-only against the images, not a magic fix.
We pick the rollback target offline, before any import. We run zdb -l on each cloned member image to read its vdev labels, & add -u to see the uberblocks on that device too. Together they tell us which TXG is the safe place to land without touching the live disks.
Don't import the pool writable on the original disks until every one of them has been imaged. A writable import commits new transaction groups to the live disks and advances the uber-block ring. Each commit pushes one more of the older TXGs the recovery depends on out of the ring, until they're gone. The image-first, read-only ordering is mandatory.
We image every member drive on a PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager. All the uber-block parsing & pool import happens offline on the clones.
Can I Recover an iSCSI LUN from a Bricked QNAP?
A QNAP iSCSI LUN is not a separate disk you can pull out of a bay. It is carved out of the storage pool that sits on the partition-3 array, which a failed firmware update leaves intact. Getting the LUN back means rebuilding that array offline first, then addressing the LUN by its type.
Block-based & file-based QTS LUNs get their space from different places, & that's what decides where we go looking. A block-based LUN takes its space from the storage pool. A file-based LUN is created on a thick volume. Either way, the block device your initiator sees lives inside that pool or volume, not on a partition of its own. So does whatever the initiator formatted on it, like a VMware VMFS datastore or a database volume.
Block-Based and File-Based LUN Storage
- QTS block-based LUN
- Takes its space from the storage pool.
- QTS file-based LUN
- Created on a thick volume.
A failed update can corrupt the internal DOM & the partition-1 configuration database that maps pools to arrays. The user data on partition 3 stays intact, so the LUN & the block device virtualized inside it are still where they were.
Rebuilding the Array Before Reaching the LUN
Recovering an iSCSI LUN adds steps to the standard reconstruction. You rebuild the pool the LUN was carved out of, then present the LUN itself as a block device so the payload your initiator wrote becomes readable. The middle steps differ by LUN type.
- Image every member drive. We clone each disk on a PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager. Every later step runs on the clones, never the originals.
- Rebuild the array offline. On QTS we reassemble the
mdadmarray read-only & activate the LVM volume group against the images; on QuTS hero we import the ZFS pool read-only. We run the virtual array assembly & destriping on Data Extractor Express RAID Edition. - Establish which LUN type you are chasing. This decides everything downstream. A file-based LUN only shows up once we mount the volume it sits on or parse it offline.
- Take the path that type dictates. For a file-based LUN, we mount the underlying volume read-only, copy the image file onto recovery storage, then attach that copy as a loopback block device.
- Open the payload inside it. However the block device got exposed, it holds whatever the initiator wrote to it, such as a VMFS datastore or another filesystem. We read the individual virtual machines or files out of that layer last.
The payload layer is standard work once a stable block device is in hand; what decides the outcome is the offline array rebuild underneath it, the same discipline our QNAP recovery service applies to every pool.
Re-initializing the pool destroys the LUN with everything else
A LUN carries no separate protection. It is only as safe as partition 3. If QTS offers to initialize the drives or recreate the storage pool and you accept, QTS builds a fresh array over partition 3 and writes new superblocks over the array metadata.
Why Is My QNAP Stuck in a Boot Loop After an Update?
According to QNAP, a NAS that won't boot after a firmware update most likely has a problem with either the storage drives or the NAS itself. To tell which, QNAP says to boot it with the drives removed.
A unit that stays dark when you press the power button, with no fan spin and no beep, is reporting a different state. Start with a QNAP that will not power on instead.
Read the color, not only the blinking. An alternating red and green status LED is QNAP's signal for an active background operation: a disk format, an in-flight firmware write, a capacity expansion, or a RAID rebuild. If it keeps alternating with no update in flight, something else on that list is running, such as the box rebuilding a degraded array. That rebuild reads every sector of the surviving members while the array runs with reduced or no redundancy.
Red is a different report. A QNAP that comes up showing a red status light instead of a boot flash is reporting a critical condition. QNAP lists several conditions that turn it red, among them a failed disk, bad sectors, a degraded pool, a full disk volume, a system fan failure, and a hardware self-test error.
Power down the unit to stop the cycle and preserve the drives.
Is My QNAP Bricked by a Firmware Update or Hit by DeadBolt Ransomware?
DeadBolt hijacks the QNAP login page with a ransom note. A firmware brick does not. A genuine DOM brick is a failed write to the internal DOM flash. DeadBolt is ransomware that hijacked the web UI & encrypted your files in place. The recovery path is different for each.
DeadBolt replaced the device login & HTML web interface with a ransom page, so it read as an unexpected system screen.
QNAP then pushed forced firmware updates (version 5.0.0.1891) that stripped the ransom screen off the interface.
| What you check | Genuine DOM brick | DeadBolt ransomware |
|---|---|---|
| What actually failed | The firmware write to the internal DOM never finished. | A cryptographic attack ran against your files on the data volume. |
Partition 3 user data | Physically intact. The bytes were never rewritten. | Encrypted in place, with .deadbolt appended to affected files. |
| Internal DOM | Corrupt or incompletely written. This is the brick. | The unit boots QTS, which is how the ransom page reaches you at all. |
A genuine brick leaves your files where they were. Either the DOM write failed & the unit won't boot, or the Partition 1 config database that maps the pool to the mdadm arrays fell out of sync. In that second case QTS reports an empty pool because it can't find the mapping anymore.
The data on Partition 3 never changed. On QTS, that's the ext4 filesystem on an LVM2 volume.
DeadBolt is the opposite. It targeted internet-exposed QNAP & ASUSTOR units through a claimed zero-day, hijacked the device login & HTML web UI, & replaced it with a ransom page, which is why it presents as an unexpected system screen. It encrypted user files in place on Partition 3 & appended the .deadbolt extension.
The damage is in the interface & in your files. A unit hit this way still boots, which is the practical difference from a brick that never gets that far.
Why the recovery path splits here
For a genuine brick we image every member through a write-blocker first. On QTS we then rebuild the Partition 1 config mapping & reassemble the mdadm plus LVM2 plus ext4 stack. On QuTS hero we import the OpenZFS pool from the clones, with an uberblock & transaction-group rollback only when the pool needs one. The array assembly runs on Data Extractor Express RAID Edition against the images, never the originals.
For a DeadBolt case the work is different. We still image first & work read-only on clones, but the job is triage: identifying which datasets carry the .deadbolt extension & salvaging the unencrypted Partition 3 data, the files that escaped the encryption pass. We do not state that we decrypt .deadbolt files; we image the disks & report what is recoverable in the clear.
DeadBolt is the textbook reason a redundant array is not a backup. RAID gives you hardware availability & uptime; it does not protect your data. Ransomware writes to every member at once, so parity & mirroring spread the damage instead of containing it. Keeping your files safe from this kind of attack takes a discrete, offline copy.
How Do I Restore the QNAP Original Partition After DOM Recovery?
You don't restore the original partition by reflashing the DOM. The fix is to rebuild the pool-to-array mapping offline from cloned images. The data on Partition 3 never moved; what's missing is the configuration database on Partition 1 that tells QTS which mdadm array belongs to which storage pool. We reconstruct that mapping by reading the array metadata directly off the drives, not by asking QTS to guess.
The QTS configuration database on Partition 1 holds the map that links each high-level storage pool to its underlying mdadm array. At boot, QTS reads that database to locate & assemble your storage pools. When a failed firmware update corrupts partition 1, that's the mapping that falls out of sync.
Rebuilding the pool mapping offline from cloned images
We do all of this on write-blocked clones. Every member drive is imaged first & the originals are never modified, so the reconstruction runs against copies with no risk to your data.
- Clone each member drive. Image every disk through a write-blocker before anything else. All later steps run on the images, not the original drives.
- Read the array metadata. Run
mdadm --examineonPartition 3of each cloned image to reconstruct pool membership: which drives belong to the array, the RAID level, member order, & data offset. - Assemble the array read-only. Bring the array up with
mdadm --assemble --readonlyfrom the cloned images, with no possibility of a write reaching the disks. - Activate the LVM volume group. Run
vgchange -ayto activate the volume group (the Linux Logical Volume Manager layer that QTS stacks on top of the array) & expose the logical volume. - Mount the ext4 volume read-only. Then copy the files off the ext4 filesystem while it's mounted read-only.
The mapping QTS lost on Partition 1 gets rebuilt from the array metadata that still lives on Partition 3. The virtual array assembly & destriping runs on Data Extractor Express RAID Edition against the images. If you'd rather hand the whole stack to us, the QNAP recovery service covers QTS & QuTS hero units end to end.
How We Recover Data from a Firmware-Bricked QNAP
Every QNAP recovery follows an image-first workflow. Your original drives are never modified. All RAID assembly and filesystem extraction happens on cloned images.
- Free evaluation and model identification. We document the QNAP model, the QTS or QuTS hero version, the RAID level, the number of member drives, and any prior recovery attempts. We check whether the failure was a DOM corruption, a partition 1 config desync, or an accidental initialization.
- Write-blocked forensic imaging. We image each member drive on a PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager. We do head swaps on drives with mechanical issues on our 0.02 micron ULPA-filtered clean bench before imaging. If a drive needs board-level repair instead, we do that before imaging too.
- RAID metadata capture. For QTS we read the mdadm superblock off partition 3 of each cloned image, which gives us the chunk size, layout, member order, and data offset. For QuTS hero we read ZFS vdev labels and uber-blocks to identify valid transaction groups.
- Offline array reconstruction. We assemble the virtual mdadm array or import the ZFS pool from the cloned images on a Linux workstation. All reconstruction is read-only. The original drives remain untouched.
- Filesystem extraction and delivery. For QTS we activate the LVM volume group and mount ext4 read-only. For QuTS hero we import the ZFS pool with transaction group rewind if needed. Files are extracted, verified, and copied to your target media.
Those five steps aren't QNAP-specific. We image every member drive first & rebuild offline from write-blocked clones, the same discipline behind multi-drive NAS array reconstruction on any brand; what changes with QNAP is which metadata layer gets parsed once the images exist, mdadm superblocks & the LVM volume group on QTS versus ZFS vdev labels & transaction groups on QuTS hero.
How Much Does QNAP Firmware Failure Recovery Cost?
QNAP recovery follows our standard NAS recovery model: a per-drive imaging fee based on each drive's condition, plus an array reconstruction fee. Firmware-brick cases where the DOM failed but the drives are healthy typically cost less because no mechanical work is needed.
- 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
When we have to rebuild the array, there's a separate array reconstruction fee on top of per-drive imaging. If we recover nothing, you owe $0. There are no diagnostic fees.
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 benchQNAP Firmware Failure Recovery FAQ
Does a failed QNAP firmware update delete my data?
No. A failed firmware update can corrupt the internal DOM flash and the configuration database on partition 1 of the member drives. The storage pool on partition 3 stays intact.
Why is my QNAP stuck in a boot loop after a firmware update?
A firmware update writes the QTS firmware your NAS starts from onto the internal DOM flash. QNAP's firmware recovery guide covers units that won't start because the power went out or the network dropped during the update.
How do I recover data from a bricked QNAP NAS?
Power down the unit. Remove every drive and label each one with its exact bay number. Ship all drives to us. We image each member through a write-blocker, then assemble the mdadm or ZFS array from the cloned images on a Linux workstation. For QTS we activate the LVM volume group and mount ext4 read-only. For QuTS hero we import the ZFS pool read-only, & we only roll it back to an earlier transaction group when the latest one is damaged.
What is the difference between QTS and QuTS hero recovery after a firmware brick?
QTS uses mdadm RAID with LVM2 and ext4 on partition 3. Recovery requires reading mdadm superblocks, activating the volume group, and mounting the ext4 filesystem. QuTS hero uses OpenZFS.
What does the Fresh Install trap mean?
If QTS shows the pool as uninitialized and you click Initialize or Create New Storage Pool, QTS writes a fresh array over partition 3 of every drive. That overwrites the original superblocks.
Why won't my QuTS hero pool import after a firmware update?
Don't import the pool writable on the original disks. A writable import commits new transaction groups to the live disks and advances the uber-block ring, which pushes out the older TXGs the recovery depends on. The drives must be imaged first so technicians can parse the uber-block ring offline and roll the pool back to the last clean transaction group.
Can I recover an iSCSI LUN or virtual machine from a bricked QNAP?
A QNAP iSCSI LUN is not a separate disk you can pull from a bay. On QTS, a block-based LUN takes its space from the storage pool and a file-based LUN is created on a thick volume. A failed firmware update can corrupt the DOM and the partition 1 config database. The storage pool on partition 3 that holds the LUN stays intact. We image every member and rebuild the array offline read-only before reaching the LUN.
Is my QNAP bricked by a firmware update or hit by DeadBolt ransomware?
DeadBolt hijacks the QNAP login page with a ransom note. A firmware brick does not. A genuine DOM brick is a failed write to the internal DOM flash. A failed update can also corrupt the partition 1 config database that maps the pool to the mdadm arrays, but partition 3 user data stays physically intact. DeadBolt is ransomware that targeted internet-exposed QNAP and ASUSTOR units. It hijacked the device login and web UI with a ransom page, encrypted files in place on partition 3, and appended the .deadbolt extension. A unit hit that way still boots. QNAP then pushed forced firmware updates (version 5.0.0.1891) that removed the ransom screen. For a brick we image every member, then either rebuild the config mapping and the mdadm/LVM2/ext4 stack or import the QuTS hero ZFS pool read-only. We only roll the pool back to an earlier transaction group when its latest state is damaged. For DeadBolt we image first, then triage which datasets carry the .deadbolt extension and salvage the unencrypted partition 3 data. We do not claim to decrypt .deadbolt files.
Since 2008
Established
As Featured In
Related services
Need Recovery for Other Devices?
All NAS brands and RAID types
QTS, QuTS hero, ZFS pools
Backplane and config-DB faults
No LED activity or fan spin on power-up
ZIL, TXG, and uberblock rollback
Red LED and no-boot diagnostics
Unprompted rebuild and format states
RAID 0, 1, 5, 6, 10 arrays
Complete service catalog
QNAP bricked after a firmware update?
Power down, label your drives, and ship them to us. Free evaluation. No data, no fee.