How Do You Tell Whether a QuTS Hero Pool Still Has Its Data Integrity?
Three per-vdev counters & one file list. zpool status reports READ, WRITE, & CKSUM counts for every member of every vdev, & zpool status -v names the files whose blocks no longer reconstruct. We read all four out of a read-only import of the cloned images, not out of the live unit.
What the zpool status counters actually report
READ & WRITE are the plain ones: both count I/O errors reported by the device itself. CKSUM is the counter that decides whether you have a drive problem or something upstream of the drive. A non-zero CKSUM count means the device returned data that failed its checksum, which is silent corruption rather than a refused read.
A member showing CKSUM errors while reporting no I/O errors at all more often indicates cabling, an HBA, or memory than the disk. That distinction changes the whole case, because swapping the suspect drive fixes nothing when the corruption arrives over the path into it.
The permanent-errors list ends the argument. zpool status -v lists files with unrepairable errors; that data is gone, & the remedy for those specific files is a restore from a backup or a snapshot, not another scrub.
QNAP's own QuTS hero documentation directs administrators to "use the Storage & Snapshots utility" & warns that "Using ZFS CLI commands on your QuTS hero NAS is not supported and should be avoided." That warning is right about the live unit, so we take the counters from a read-only import of write-blocked clones instead.
| Telemetry field | What it actually tells us |
|---|
| READ | I/O errors the device itself reported. A climbing count marks a member that gets imaged before anything else in the pool is touched. |
| WRITE | The same class of device-reported I/O error on the write path, which is why we read this counter from a clone instead of from a pool that is still accepting writes. |
| CKSUM | The device returned data that failed its checksum: silent corruption. Non-zero here on a disk reporting no I/O errors points more often at cabling, an HBA, or memory than at the disk. |
| Permanent errors file list | Files with unrepairable errors. That data is gone; those specific files come back from a backup or a snapshot, & no amount of further reading changes it. |
ZFS self-healing needs surviving redundancy
Detecting corruption & repairing it are two different capabilities, & QNAP's feature pages market self-healing without stating the precondition. ZFS repairs a bad block as long as there is at least one good copy of that block that matches the checksum.
That good copy comes from a redundant vdev: a mirror, or a RAIDZ vdev whose redundancy is still intact. A RAIDZ vdev that has already lost its redundancy to a failed member has no surviving parity to rebuild that block from. The checksum mismatch is still caught; it surfaces as an unrecoverable read instead of a silent repair, which is the class of error the permanent-errors list is reporting.
No scrub & no resilver until every member is imaged
A scrub reads every allocated block in the pool & verifies every checksum. A resilver does more than verify: it copies data from one disk to another to regain consistency, where scrubbing checks that everything is as it should be & does some maintenance. Both operations ask an already-marginal surviving member to serve every allocated block it holds.
The mechanics of what that read load does to a same-batch vdev are in the resilver-triggered cascading drive failure walkthrough above. The rule that follows from it is short: clone every member first, then scrub the clones.
Snapshot retention limits inside a QuTS hero pool
A QuTS hero snapshot is an object inside the pool, not a copy parked somewhere else. It is enumerated with zfs list -t snapshot against an imported pool, the same dependency a zvol has on this platform: the pool assembles first, then the objects inside it become addressable.
That makes retention strong against one class of damage & silent about another. For a file sitting in the permanent-errors list, or a dataset an administrator overwrote, a pre-damage snapshot is the restore path. For corrupt vdev labels, dead member drives, or a broken uberblock ring, it is not; those get reconstructed offline before any snapshot is readable at all.
Plan retention around that split. Redundancy inside the chassis buys availability & uptime rather than data protection, so a copy that outlives a pool which won't import has to live off that pool: a replication target, or a discrete offline backup. Adding more snapshots to the same pool doesn't change that.
