QNAP Firmware Update Failure Recovery

Recovery Mode writes the DOM, never partition 3

A bricked DOM keeps the unit from booting QTS, so it cannot answer the network & will not show up in Qfinder Pro. The bare-metal firmware recovery happens before that: a USB boot reflash on x86, or a hardware-reset trigger plus a TFTP-style network reflash on ARM. That reflash writes only to the DOM or SPI boot flash. It does not touch Partition 3 on the member drives, so a successful reflash leaves the mdadm arrays & their ext4 or ZFS contents physically intact. Qfinder Pro comes in later, once the unit boots again, as the tool that applies standard QTS updates over the network.

A reflash on its own does not get you back to a mounted pool. The freshly written QTS boots factory-default, no longer maps the existing arrays on the drives, & presents an empty or uninitialized pool. That lands you straight in the Fresh Install trap documented below, where accepting the initialization prompt runs mdadm --create over your superblocks. The architecture detail changes how you enter recovery; it does not change the config-DB desync waiting on the other side.

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.

QNAP typically uses a 512K or 64K chunk size for RAID 5 and RAID 6 arrays. The superblock version matters: 1.0 places metadata at the end of the partition with data offset 0; 1.2 places metadata 4KB from the start with a data offset around 1MB. Specifying the wrong version shifts every block and produces garbage.

Older QTS 3.x-era arrays often carry the legacy metadata 0.90 superblock, & it is the easiest version to misread. The 0.90 superblock is 4KB long, sits in a 64KB-aligned block 64KB to 128KB from the end of the device, & carries data offset 0, the same as 1.0. It also caps the array at 28 component devices & a roughly 2TB component size, 4TB on newer kernels. So both 0.90 & 1.0 keep the metadata at the end & the data at the very front of the partition.

This is where a reconstruction goes wrong. Forcing a 0.90 or 1.0 array (data at offset 0) to assemble as 1.2 tells mdadm to expect data at a 1MB offset, so the ext4 & LVM headers land at the wrong place & you read garbage. 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 directly on partition 3 with no mdadm or LVM layer. ZFS maintains multiple copies of its uber-block in a circular array on each vdev label. 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 -F -o readonly=on. If the pool ran deduplication, the Deduplication Table must fit in RAM at import time; approximately 5 GB of RAM per 1 TB of deduplicated data. A pool that imported fine on a 128 GB host may kernel-panic on a smaller recovery workstation.

QNAP ships a customized QZFS fork with an altered on-disk indirect-block layout that the stock OpenZFS toolchain does not fully understand. This is why a DIY attempt with a plain zpool import on a vanilla Ubuntu or Debian OpenZFS host often refuses to assemble the pool even after you've targeted the correct transaction group for rollback. QNAP-aware methodology is required: we parse the vdev labels and uberblock ring offline from the write-blocked clones and rebuild the metadata mapping ourselves, rather than leaning on a native import that the proprietary layout blocks.

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 Metadata Inconsistency: Why the Pool Will Not Import After a Brick

QuTS hero leans on the ZFS Intent Log (ZIL) to record synchronous writes before they land in the main pool. ZFS is atomic copy-on-write, so an interrupted transaction group (TXG) commit is normally just discarded and the pool falls back to the last valid uber-block. The danger during a firmware brick is the DOM and member drives dropping or reordering writes with no power-loss protection, which leaves the on-disk metadata in an inconsistent state that the last uber-block cannot cleanly describe. You reflash the DOM, the OS comes back, and zpool import still returns an I/O error because ZFS cannot find a consistent point to mount from. On most QuTS hero units the ZIL is embedded in the pool itself. 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 and its more aggressive form zpool import -FX (an extreme rewind that runs an exhaustive search for a valid TXG) both work by discarding the newest transaction groups until they reach the last consistent on-disk state. 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. Running zdb -u against the raw member images enumerates the uber-block array, and zdb -l reads the vdev labels. Together they tell us which TXG is the safe place to land without touching the live disks.

Never run zpool import -f (force) on an inconsistent pool before imaging is complete. A forced import writes new transaction groups to the live disks and replays or discards the intent log, which mutates the metadata tree and advances the uber-block ring, pushing the historical TXGs that recovery depends on out of the ring one commit at a time until they are gone. The image-first, read-only ordering is mandatory.

Every member drive is imaged through a hardware write-blocker with the PC-3000 Portable III, PC-3000 Express, Data Extractor Express RAID Edition, or DeepSpar Disk Imager, and all uber-block parsing and pool import happens offline on the clones.

QNAP LUN types & where each one lives

QTS block-based LUN

Provisioned from the storage pool as a logical volume in the LVM stack, bypassing the host filesystem. There is no file to look for; the LUN is a slice of the volume group that sits on the partition-3 mdadm array.

QTS file-based LUN

An image file stored on an ordinary QNAP volume, alongside the shares you browse over SMB. QNAP does not publish one universal filename for that container, so any walkthrough telling you to search a QNAP volume for one fixed container name has nothing to key on.

QuTS hero block-based LUN

Backed by a ZFS volume, a zvol, inside the pool rather than by a file inside a dataset. It is reached through a pool import, not through a filesystem mount, which is why QuTS hero LUN work does not follow the QTS procedure.

None of the three is a partition, & none of them can be read by pulling one drive out of a bay & plugging it into a desktop. All three are carved out of the storage pool that sits on partition 3, so a LUN is exactly as recoverable as that array & no more. The failed update corrupts the internal DOM & desyncs the partition-1 configuration database that maps pools to arrays; it does not write to partition 3, so the LUN & the block device virtualized inside it stay where they were.

The multi-stage recovery: rebuild the array, then reach 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.

1. Image every member drive. Each disk is cloned through a hardware write-blocker with a PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager. Every later step runs on the clones, never the originals.
2. Rebuild the array offline. On QTS we reassemble the mdadm array read-only & activate the LVM volume group against the images; on QuTS hero we import the ZFS pool read-only. The virtual array assembly & destriping runs on Data Extractor Express RAID Edition, not on the imaging hardware.
3. Establish which LUN type you are chasing. This decides everything downstream. On QTS, lvs against the reassembled volume group lists the logical volumes it holds, & a block-based LUN is one of them. A file-based LUN surfaces only once the volume it sits on is mounted or parsed offline.
4. Take the path that type dictates. A block-based LUN on QTS is reached by activating its logical volume read-only against the reassembled partition-3 array; on QuTS hero the equivalent is reading the zvol that backs the LUN from a read-only pool import. A file-based LUN is reached the other way: mount the underlying volume read-only, copy the image file onto recovery storage, then attach that copy as a loopback block device.
5. Open the payload inside it. Whichever path exposed the block device, what it carries is whatever the initiator wrote there (a VMFS datastore, a VHD or VHDX, a raw filesystem), & the individual virtual machines or files are read 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.

Why the recovery path splits here

For a genuine brick we image every member through a hardware write-blocker, then rebuild the Partition 1 config mapping & reassemble the mdadm plus LVM2 plus ext4 stack on QTS, or import the QuTS hero OpenZFS pool from the clones via uberblock & transaction-group rollback. 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.