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: 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.Damaged recent transaction groups: ZFS keeps a ring of uberblocks in each vdev label. On import it skips any uberblock that fails verification and uses the valid one with the highest TXG. A corrupt newest uberblock won't block import by itself. You only need to rewind to an older TXG when the pool won't import at that state.
• 4.Insufficient vdev members: raidz1 tolerates one failed drive. With two or more drives missing or faulted, the import fails. raidz2 tolerates two failed drives. Three or more faulted drives is past 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. 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. Take valid candidates from the TXG numbers zdb -lu lists. At default settings, zfs_txg_timeout=5s is the longest a TXG runs, and it can close sooner.
• 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.
• 3.Previous repair attempts did not resolve the issue. If you've already run zpool replace or zpool scrub on the degraded pool and it didn't fix things, both of them wrote to the pool. A replace resilvers onto the new device, and a scrub repairs damage it finds. Image what remains before any further writes.
• 4.Drives are making abnormal sounds. Clicking, grinding or repetitive seeking means a hardware fault. We find out which part failed on the bench, not from the sound. 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 and are permanently lost. 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. The -m flag 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.Slow DDT load after import: Enabling ZFS deduplication builds a Deduplication Table (DDT) proportional to the pool's unique block count. Holding the table in the Adaptive Replacement Cache (ARC) takes roughly 1 to 5 GB of RAM per 1 TB of deduplicated data. The DDT is stored on disk and read on demand, so a pool whose DDT does not fit in RAM still imports, but 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. That slow-motion load reads to the operator like a failed import rather than the memory-sizing problem it actually is. Imaging or replacing healthy drives changes nothing. Because the DDT is not needed to read existing data, a strictly read-only import with zpool import -o readonly=on poolname is the recovery path on undersized hardware. Before import, estimate the DDT size with zdb -e -S poolname. It simulates deduplication and prints the DDT it would build. zpool status -D only works on a pool that's already imported.

Both paths misdirect drive-level troubleshooting because the member disks are fine. See our TrueNAS data recovery service for how SLOG loss and DDT sizing factor into a full pool import.