TrueNAS ZFS Pool Import Failure Recovery

Why Does a TrueNAS Pool Refuse to Import?

When you import a pool, ZFS reads the vdev labels, and each label carries its own uberblock ring. The ZIL doesn't get replayed until later, when the datasets mount, and only on a writable pool.

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)

Does Losing the SLOG Destroy the Pool?

No. The SLOG is not where your data lives.

The SLOG is a Separate Log: it holds the ZFS Intent Log (ZIL) entries for synchronous writes only, and only for the seconds between the write and the next transaction group commit.

When a SLOG fails or is removed, the loss is bounded to in-flight synchronous writes since the last txg commit. OpenZFS defaults to a maximum of 5 seconds between TXG commits (configurable via zfs_txg_timeout). NFS sync commits and database fsync writes during that window are lost; everything that was already part of a committed TXG is on the main pool vdevs.

The import command for a pool with a missing log device is:

# Authorize import despite missing log device
zpool import -m -o readonly=on -N <pool-name>

The -m flag explicitly authorizes import without the log device. The -o readonly=on -N flags keep the operation forensic.

L2ARC is even less critical. L2ARC is a read cache backed by SSD; losing it never affects pool integrity. The pool imports normally without an L2ARC device.

How We Recover a TrueNAS Pool That Will Not Import

Every step operates on cloned images. No reconstruction runs against original drives. All work happens at the Austin lab.

1. Intake and topology documentation: We record the TrueNAS version (CORE or SCALE) and the pool topology (mirror, RAIDZ1, RAIDZ2, RAIDZ3, or multi-vdev). We also note the dedup state, whether there's a SLOG and L2ARC, the encryption (native ZFS or GELI), and the host RAM at the time of failure.
2. Write-blocked imaging: We image every member through a write-blocker. When a drive has bad sectors, we image it with head maps and conservative retry parameters. If a drive has a mechanical fault, we do a head swap on the 0.02 micron ULPA clean bench before we image it.
3. Vdev label parsing: We read all four label copies (L0, L1, L2, L3) from each member image. Labels contain the pool GUID, the vdev tree as nvlists, and the uberblock ring. Labels are cross-referenced across members to build a complete topology even if some members have label damage.
4. Uberblock ring analysis and TXG selection: The ring on each label is parsed with zdb. We find the highest TXG with a valid uberblock. If the pool won't import at that TXG, we walk the ring backward to the most recent consistent state.
5. Read-only forensic import on adequately sized hardware: We import the reconstructed pool with zpool import -o readonly=on -N from cloned images on a host sized for the DDT. The -N flag prevents automatic dataset mounting. The readonly property is what prevents ZIL replay and leaves the on-disk state untouched.
6. Dataset and zvol extraction: We extract datasets, zvols, and snapshots. We verify every block against its ZFS checksum. We mount zvols that back VMs as block devices and verify their guest filesystems independently.
7. Delivery: Recovered data is transferred to your target media.

What Do the ZFS Recovery Terms Mean?

DDT (Deduplication Table)

The on-disk index that maps every deduplicated block to its checksum and reference count. It is read on demand rather than loaded up front, and holding it in ARC costs roughly 1 to 5 GB of RAM per 1 TB of deduplicated data. A host without that RAM still imports the pool; the table then loads from disk over time.

ARC (Adaptive Replacement Cache)

The primary ZFS read cache, held in system RAM. It stores recently and frequently used blocks, and it is where the DDT is cached once read. ARC size is bounded by zfs_arc_max; when the table does not fit, dedup lookups fall back to on-demand disk reads and a dedup-heavy pool stays slow for a long time after import.

SLOG (Separate ZFS Intent Log)

A dedicated fast device that holds the ZFS Intent Log for synchronous writes only. It is not where your data lives. Losing it costs only the in-flight sync writes since the last transaction-group commit; the pool still imports with zpool import -m.

Uberblock

The root pointer for a transaction group, recording the TXG number, a timestamp, and the MOS root. ZFS keeps a ring of them in every vdev label, and how many slots that ring has depends on the pool's ashift. That ring is what lets you rewind to an earlier valid state.

Scrub vs Resilver

A scrub reads all data in the pool and verifies each block's checksum. On mirror, raidz and dRAID vdevs it also repairs any damage it finds. A resilver examines only data ZFS knows is out of date, such as the contents of a replacement device.

raidz1 / raidz2 / raidz3 Parity Tiers

ZFS parity vdev levels. raidz1 tolerates one drive lost per vdev, raidz2 tolerates two, and raidz3 tolerates three. Exceeding a vdev's parity count marks that vdev FAULTED and takes the pool offline, which is when forensic image-and-reconstruct work begins.

dRAID (Distributed RAID)

A declustered parity vdev introduced in OpenZFS 2.1, described by a config string such as draid2:4d:11c:1s (parity level, data devices per group, total children, distributed spares). Unlike RAIDZ with a separate whole-drive hot spare, a dRAID distributed spare is spare capacity sliced and interleaved across every child; a rebuild resilvers into those slices rather than onto one replacement disk. Fault tolerance is still the parity level.

TrueNAS ZFS Pool Recovery Questions

The questions below cover what TrueNAS administrators ask before shipping drives: DDT memory math, missing SLOG semantics, uberblock rollback commands, cross-host import portability, and the difference between -F, -X, and -T rewind. For broader OpenZFS architecture and other ZFS host environments, see our QNAP QuTS hero ZFS recovery page and the broader server data recovery workflow, including our enterprise TrueNAS / FreeNAS recovery page for ZFS pools backing VMware and Hyper-V.