QNAP Red Status Light Error Data Recovery

When the partition-1 md9 config database is corrupted after a firmware update, QTS reports the pools as empty. The recovery path bypasses QTS entirely. We never boot QTS. We image every member drive write-blocked first, then work only on the clones, so the originals are never touched.

Assembling the data array directly is the safe move. Instead of mdadm --assemble --scan, we target partition 3 specifically:

mdadm -AfR /dev/md127 /dev/sda3 /dev/sdb3 ...

The --force flag makes mdadm mark members recorded as failed as working. That's why we only run it on the clones, never on your original drives. QNAP QTS arrays carry standard mdadm superblocks, so they assemble on a vanilla Linux workstation.

Next, activate the LVM2 volume group with vgchange -ay. Vanilla Linux often errors with Unrecognised segment type thick, because QNAP layers a proprietary thin and thick provisioning implementation over LVM2.

Standard Linux thin-provisioning-tools and the stock dm_thin_pool module cannot parse that custom metadata, so a vanilla workstation refuses to activate the volume group.

Reading the logical volume takes recovery software that understands QNAP's LVM2 structures, or moving the array onto a compatible QNAP host.

Finally, mount the ext4 logical volume read-only:

mount -t ext4 -o ro,noload /dev/mapper/<vg>-<lv> /mnt/recover

The noload flag is mandatory alongside read-only. Without it, ext4 replays a dirty journal even under -o ro, & that replay writes to the partition.

-o ro,noload skips the journal entirely. QTS never boots in this path; the files come straight off the reconstructed partition-3 array.

For QuTS hero (ZFS) units, this mdadm, LVM2, and ext4 path does not apply. ZFS pools need uberblock location and transaction-group (TXG) reconstruction, a separate toolchain. The filesystem determines the tooling: QTS units take the mdadm path above, QuTS hero units take the ZFS path, and the two are never mixed.

QuTS hero is the other QNAP operating system, & its data partition is a ZFS pool rather than the mdadm, LVM2, & ext4 stack QTS uses. If a QuTS hero pool won't import, the QTS mdadm, LVM2 & ext4 commands don't apply. You don't run mdadm or vgchange on a ZFS member.

The filesystem decides the tooling: QTS takes the mdadm path, QuTS hero takes the ZFS path below, & the two are never crossed.

Every ZFS vdev label carries a 128 KiB uberblock array, which has room for up to 128 uberblocks. They get rewritten as transaction groups (TXGs) commit. When the pool loads, ZFS takes the uberblock with the highest TXG.

When the transaction group it points to is corrupted, the import fails. The earlier uberblocks pointing at older, consistent TXGs are still sitting in the label ring, intact.

The recovery runs on cloned member images only. We image every drive write-blocked first, then work on the clones, so the original disks are never written to & never see a new-pool, Migrate, or Initialize prompt.

The zpool-import(8) man page says -T sets the txg to use for rollback.

One constraint decides how fast the pool comes back on a given machine: deduplication. If dedup was switched on, holding the Deduplication Table (DDT) in ARC takes roughly 1 to 5 GB of RAM for every 1 TB of deduplicated data.

The DDT is stored on disk and read on demand, so zpool import still finishes when the table is larger than physical RAM. What changes is speed: iXsystems documents that loading the table on demand can take days after an import or reboot, and every deduplicated write or deletion becomes a random disk read in the meantime.

ZFS dedup is not free: it is paid for in RAM, and on an undersized host it is paid for in time instead. Because the DDT is not needed to read existing data, the extraction runs read-only.