ZFS Pool Import Failed: I/O Error Recovery Guide

Pool import reads vdev labels, uberblocks, and the Meta Object Set (MOS) from every vdev member to reconstruct the pool's in-memory state. An I/O error during this process means ZFS could not read at least one required metadata block.

• 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.

If drives and cables are healthy and the issue is at the ZFS metadata level, these import strategies proceed from least invasive to most. Always attempt read-only import first.

• 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 pending TXGs 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.

Stop attempting imports and image every drive if any of the following conditions apply. Further import attempts on failing hardware risk making the data unrecoverable.

• 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.