ZFS Pool Import Failed: I/O Error Recovery Guide

• 1.Physical drive failure: One or more drives in the pool have failed or are returning read errors on sectors that contain ZFS metadata. If the failed drive is part of a raidz group and the group has exhausted its parity tolerance, import fails.
• 2.Controller or cable issues: SATA/SAS cables degrade, controller ports fail, and HBA firmware can develop bugs. If kernel logs show ATA errors or device resets preceding the ZFS I/O error, the problem may be at the transport layer, not the drive.
• 3.Corrupted uberblock: ZFS stores a ring buffer of uberblocks on each vdev member. If the most recent uberblock is corrupted (from power loss during a TXG commit, for example), ZFS cannot determine the pool's last consistent state and refuses to import.
• 4.Insufficient vdev members: raidz1 tolerates one drive failure; if two or more drives are missing or faulted, the vdev becomes UNAVAIL. raidz2 tolerates two drive failures; three or more faulted drives exceeds its redundancy, and the import fails.

• 1.Read-only import: zpool import -o readonly=on poolname imports the pool without writing metadata to the member drives; no TXGs are synced and no ZIL is replayed. Add -o cachefile=none to prevent updating zpool.cache. However, a read-only import still forces massive random read I/O across every member drive to traverse the ZFS metadata tree. If any drive has suspected physical failure (clicking, slow response, I/O timeouts), image all drives with a hardware write-blocker first and import the cloned images instead. If ZFS can assemble the vdev tree, copy data to a separate destination immediately.
• 2.TXG rollback: If read-only import fails because the latest TXG is corrupt, try importing at an earlier transaction group: zpool import -T <txg-number> -o readonly=on poolname. Use the TXG numbers from zdb -l to find valid candidates. Each TXG represents roughly 5 seconds of writes at default settings.
• 3.Force import (unclean shutdown only): zpool import -f poolname tells ZFS to accept a pool that was not cleanly exported. ZFS replays the intent log (ZIL) and updates on-disk metadata. This is safe when all drives are healthy and the only issue is an unclean shutdown. If drives are failing, this writes to the drives and can overwrite recoverable metadata.

• 1.Multiple drives show I/O errors or SMART degradation. If more drives are faulted than the parity level allows (for raidz1, two or more; for raidz2, three or more), the pool has exceeded its redundancy. Further import attempts stress drives that are already failing.
• 2.Read-only import and TXG rollback both fail. If ZFS cannot find a valid uberblock across any TXG, the metadata damage extends beyond what standard import tools can handle. The on-disk data may still be intact below the metadata layer, but extraction requires ZFS-aware forensic tools.
• 3.Previous repair attempts did not resolve the issue. If you have already run zpool clear, zpool replace, or zpool scrub on the degraded pool without resolution, these operations wrote metadata updates to the drives. Image what remains before any further writes.
• 4.Drives are making abnormal sounds. Clicking, grinding, or repetitive seeking sounds indicate mechanical failure. Power the drive down immediately. These drives need to be imaged with hardware that can manage weak heads and bad sectors at a level ddrescue cannot reach.

For imaging, use ddrescue with a separate destination drive for each pool member. Work from the images for all subsequent recovery attempts. For drives with physical faults, professional NAS data recovery uses write-blocked connections and PC-3000/DeepSpar hardware to image drives that consumer tools cannot read, then reconstructs the pool offline from the images.

# dRAID config string grammar: draid[parity]:[data]d:[children]c:[spares]s
draid2:4d:11c:1s

#   parity   = 2   redundancy level per redundancy group (1, 2, or 3)
#   4d       = 4   data devices per redundancy group
#   11c      = 11  total member devices in the vdev
#   1s       = 1   distributed spare (sliced across all children, not a whole drive)

• 1.Failed SLOG device (ZIL loss): ZFS stages synchronous writes in the ZFS Intent Log (ZIL). When the pool has a dedicated Separate Intent Log (SLOG) device, the ZIL for sync writes lives on that SLOG until each record is committed into a transaction group (TXG) on the main pool. If the SLOG fails catastrophically following a sudden power loss, the in-flight synchronous writes staged on it cannot be replayed at import and are permanently lost. This is a stronger guarantee-break than an ordinary unclean shutdown, where the ZIL is intact and replayable. Only the unreplayed dirty sync writes are gone, not the whole pool. To import while discarding the missing log device, run zpool import -m poolname; -m accepts the loss of those unreplayed sync writes as the cost of bringing the pool online. Confirm the log vdev is the only missing device before using it. Forcing operations on drives that also show physical read errors is destructive because ZFS writes new dirty blocks over sectors you may still need.
• 2.DDT RAM exhaustion at import: Enabling ZFS deduplication builds a Deduplication Table (DDT) proportional to the pool's unique block count. The general engineering rule is roughly 5 GB of RAM per 1 TB of deduplicated data. For the pool to import, the DDT must load into the Adaptive Replacement Cache (ARC) in RAM. If the DDT exceeds available physical RAM, zpool import hangs and can trigger a kernel panic. It surfaces to the operator as a pool that will not import, which reads like an I/O error rather than the memory-pressure problem it actually is. On that hardware the pool stays unimportable until you add RAM, import on a machine with more RAM, or temporarily disable dedup. Imaging or replacing healthy drives changes nothing. Before attempting import, size the DDT against available RAM with zpool status -D poolname and zdb -S poolname, which prints the simulated dedup histogram and lets you estimate DDT size. ZFS dedup is never free: the RAM cost is a hard prerequisite for import, not an optimization.

Both paths misdirect drive-level troubleshooting because the member disks are fine. For TrueNAS pools built with a SLOG or dedup enabled, our layered ZFS reconstruction at the Austin, TX lab isolates the log-device and DDT variables before any write touches the members. See our TrueNAS data recovery service for how SLOG loss and DDT sizing factor into a full pool import.