ZFS dedup-table recovery

A failed ZFS dedup vdev can make the entire pool unavailable because the dedup table may contain unique block references.

ZFS deduplication stores a table that maps content hashes to physical blocks and reference counts. When that DDT lives on a dedicated top-level dedup vdev, losing every valid replica of that device can remove metadata the pool needs to locate shared data.

Start a recovery case Call 682-325-7712

Understand the symptom

Deduplicated blocks depend on accurate hashes, physical pointers and reference counts.

WHY

What is happening

Recovery maps DDT objects, vdev labels, metadata replicas and surviving block references. Unlike L2ARC cache, a dedup allocation class stores unique metadata; recreating or clearing a failed device does not regenerate lost DDT entries from filenames.

What you may see

Symptoms that change the recovery path.

Pool will not import

A required top-level dedup vdev is missing or unreadable.

Zpool status reports DDT errors

Dedup metadata cannot be read or verified.

Scrub finds persistent checksum faults

Shared blocks or their table entries do not validate.

Pool stalls under dedup load

A damaged or memory-starved DDT causes severe lookup failures or import pressure.

Protect the source

Actions that can make the situation worse.

Removing the device can lose the pool

A dedup vdev holds unique metadata rather than a second copy.

Forced import can commit worse state

Recovery flags may discard transactions or damaged objects.

Turning dedup off does not remove old DDT data

Existing deduplicated blocks remain dependent on the table until rewritten.

Do this now

Safe steps before evaluation.

Stop pool imports and writes

Do not detach, replace, clear, scrub or use destructive import flags.

Preserve every vdev

Label and image normal, special, dedup and log devices with original order.

Collect pool metadata

Save zpool import and status output, labels, feature flags and failure history.

Document dedup use

Record affected datasets, applications, pool version and any prior pruning or device changes.

NEPFOSYS process

How a data-first evaluation proceeds.

DDT and topology analysis

NEPFOSYS maps dedup objects, allocation classes and surviving metadata replicas.

Copy-based import testing

Candidate devices and readonly recovery paths are evaluated without changing originals.

Dataset validation

Recovered datasets and shared blocks are checked for checksum and application consistency.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Is a ZFS dedup vdev a cache?

No. It stores unique deduplication metadata and should have redundancy comparable to critical pool vdevs.

Will setting dedup=off fix the pool?

No. It stops new deduplication but existing blocks still depend on their DDT entries.

Can the DDT be rebuilt from directory names?

No. It maps content hashes and physical references below the filesystem namespace.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case