ZFS pool recovery

“cannot import: insufficient replicas”

This message is alarming, but it rarely means your data is gone. It means ZFS can't currently assemble enough of a vdev to open the pool. If the disks are still readable, the pool can usually be imported read-only and copied off.

zpool import tank
cannot import 'tank': insufficient replicas
        Destroy and re-create the pool from a backup source.
zpool import
   pool: tank
  state: UNAVAIL
status: One or more devices could not be opened.
 config:
        tank          UNAVAIL  insufficient replicas
          raidz1-0    UNAVAIL  insufficient replicas
            sda       ONLINE
            sdb       FAULTED  too many errors
            sdc       UNAVAIL

What it actually means

A vdev lost more devices than its redundancy allows

ZFS groups your disks into vdevs. A raidz1 survives one lost disk, raidz2 survives two, a mirror survives all-but-one, and a single-disk vdev survives none. When a vdev loses more members than that, ZFS can't read it, so the whole pool refuses to import and reports insufficient replicas.

The part worth knowing: a device shows as FAULTED or UNAVAIL for many reasons that are not a dead disk. A loose cable, a drive that dropped off the controller, renamed device nodes after a reboot, damaged labels, or an interrupted write can all look identical to real failure. In those cases the data is still on the platters, and the pool can be reassembled.

Before you touch anything

The moves that turn a recoverable pool into a dead one

Each of these writes to the disks. On a pool that is barely holding together, a single write can overwrite the last intact copy of your data for good.

✗A forced writable import (zpool import -f without read-only). It replays the intent log and advances the transaction group, which can bury the last good state.
✗zpool clear to make the errors go away. It writes new metadata over the damaged pool.
✗zpool replace or a resilver onto a disk that was actually fine. It rebuilds from the degraded data and overwrites a good drive.
✗A scrub. It tries to repair in place, which is the opposite of what you want before the data is safely copied off.

What the tool does instead

Read-only, rewound to the last healthy transaction group

ZFS keeps a history of transaction groups (TXGs). When the most recent one is damaged, the pool often imports cleanly a few TXGs back. The tool reads every uberblock on your disks, lists the recent TXGs, and imports the pool read-only at the newest one that assembles. It never writes to your disks and never touches the original data.

zfs-rescue txgs tank
         TXG  WRITTEN (UTC)
     8460773  2026-05-01 13:26:40   <- newest, damaged
     8460772  2026-05-01 13:26:35
     8460771  2026-05-01 13:26:30
zfs-rescue walk tank
>> TXG 8460773 failed, trying the next older one
>> imported 'tank' read-only at TXG 8460772
Copy the data off now, preferably to another machine:
  rsync -aHAX /mnt/zfs-rescue/tank/ user@backup:/rescue/tank/

Runs on any Linux with OpenZFS installed (TrueNAS, Proxmox, Ubuntu, Debian). A single static binary, no install.

Most pools come back

In the majority of these cases the drives are healthy and your files are intact — the pool simply can't reassemble itself after a dropped or reordered drive, damaged labels, an interrupted write, or a corrupted newest TXG. Rewound read-only to the last good transaction group, pools like these mount and copy off cleanly.

When no software can help

If more disks are truly dead than the vdev's redundancy allows, the data that lived only on them is gone, and honest recovery stops there. The tool will tell you which devices it can and can't read.

Get the tool

$100one-time · USD

Static Linux binary · read-only by design · free to re-run on every pool you own

Buy and download

Facing this right now and not sure it's safe to proceed? Power the machine down and leave the disks alone until you've read the two terminals above. Questions before buying: support@norwegiandatarescue.no