ZFS pool-metadata recovery

ZFS MOS corruption can block the map to every dataset even when many data blocks remain readable.

The Meta Object Set, or MOS, describes pool-wide objects and dataset relationships. If required MOS blocks or their pointers are damaged, ZFS may detect all devices yet report that the pool metadata needed to open the pool is corrupt.

Understand the symptom

Opening a pool requires a valid chain from labels through uberblocks into the MOS.

WHY

What is happening

Pool labels provide configuration and uberblocks identify transaction-group roots. Recovery compares redundant labels and uberblocks, verifies vdev availability, and tests earlier consistent states. A rewind discards newer transaction groups, so a mountable pool is not proof that the latest data survived.

What you may see

Symptoms that change the recovery path.

01

ZFS-8000-72

OpenZFS reports that metadata required to open the pool is corrupt.

02

All disks appear but import fails

Device presence is not enough when the MOS or block-pointer tree is invalid.

03

Import offers -F recovery

An earlier transaction group may be consistent enough to open.

04

Extreme import takes a long time

ZFS may traverse metadata and data to verify a candidate rewind state.

Protect the source

Actions that can make the situation worse.

01

-F discards recent transaction groups

Writes after the selected recovery point are lost.

02

-X can discard even more history

Extreme rewind searches farther back and has a larger potential data-loss window.

03

Importing on active shared storage can corrupt it

The -f flag overrides ownership protection; it does not prove another host is inactive.

Do this now

Safe steps before evaluation.

01

Stop all import experimentation

Prevent automatic imports, services, scrubs, rewinds, and writes across every host.

02

Capture diagnostics

Save zpool import, status, events, labels, zdb output, device errors, GUIDs, and pool history.

03

Preserve all vdevs

Keep normal, special, log, cache, spare, removed, and replacement devices with original identity.

04

Snapshot or image the pool

Work from array snapshots or member images before rewind or metadata repair attempts.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Root-tree analysis

NEPFOSYS compares labels, uberblocks, transaction groups, MOS roots, and vdev availability.

02

Nonwriting import tests

Read-only imports and dry-run recovery points are evaluated on protected copies.

03

Dataset validation

Recovered datasets, snapshots, file systems, and priority files are checked at the selected transaction state.

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.

What is the ZFS MOS?

It is the pool-wide Meta Object Set that describes datasets and other essential objects.

Does zpool import -F lose data?

Yes. It rewinds to an earlier transaction group and discards newer transactions.

Should I use -FX?

Only after preserving the pool and testing safer options on copies. Extended rewind can lose more recent data and is not guaranteed to work.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case