NDR / Whatever it is saying now / ZFS pool will not import

zpool import · FAULTED · UNAVAIL · corrupted data · -F and -X

The ZFS pool will not import. ZFS remembers more than it lets on. Forcing the import is how it forgets.

A ZFS pool that will not import says so in the language of zpool: one or more devices is currently unavailable, the pool is FAULTED or UNAVAIL, one or more devices has experienced an error resulting in data corruption, or simply an I/O error. TrueNAS and FreeNAS relay the same words in their dashboards. ZFS is a copy-on-write file system with checksums on everything and a history of transaction groups on the disks, and a pool that will not import at its latest state can usually be imported read-only at an earlier one from images of the disks. What ends that possibility is the forum's answer, zpool import -F, which discards transactions to get the pool to mount, and -X, which discards more. Every disk is imaged and the pool imported from the images. A pool of two or more disks is £500 + VAT upwards after the free look, fixed in writing, 5–10 days at the bench.

Free first lookOne fixed figure in writingNo data, no bill on most jobsReturn postage paid

Rather talk it through? An engineer answers the bench line
0800 6890668

Do not force the import. zpool import -F rolls the pool back by discarding recent transactions, and -X discards more; both write new labels and both throw away history the bench would use. Do not run zpool clear or a scrub either. Power down, note the exact message, and send the disks.

What ZFS keeps on the disks, and how a pool comes back from it.

ZFS writes nothing in place. Every change goes to new blocks, and every few seconds a transaction group closes and a new uberblock is written into a ring of them at the front and back of each disk, pointing at the state of the whole pool at that moment. Older uberblocks stay in the ring until overwritten, and older blocks stay on disk until reused. That is the history: a pool has not one state on its disks but dozens, and the latest is merely the one the import tries first.

A pool fails to import when the latest state does not add up: a vdev has lost too many members, a label is unreadable, the latest uberblock points at metadata that fails its checksum after a power cut or a controller that lied about a write. The import then reports what it found, and the dashboard turns it into FAULTED or UNAVAIL. Nothing about that has removed the earlier states. An import at an earlier transaction group, read-only, brings the pool up as it was a few seconds or minutes before the damage, with every dataset intact.

The forum's -F does exactly that, on the originals, by rewinding and then writing new labels to make the rewound state current, discarding what it skipped. -X goes further back and discards more. Both work often enough to be recommended, and both destroy the history that would have allowed a more careful choice. The bench images every disk, imports the pool read-only from the images at the latest consistent transaction, and rolls back only as far as it must, with the discarded transactions still on the images should they hold anything.

What it says, and what it means.

Describe yours to us →

What you see	The usual reason	Where that leaves you
cannot import: one or more devices is currently unavailable	A member missing or a label unreadable	Member imaged; labels read from the images
cannot import: I/O error	A member with read errors	Imaged with bad areas last; imported from images
cannot import: corrupted data	Latest metadata fails its checksum	Read-only import at an earlier transaction group
pool state FAULTED	Too many members lost from a vdev	Each member imaged; pool assembled from images
pool state DEGRADED, still imports	Redundancy lost	Copy out; power down; no scrub
-F already run	History discarded to the rewind point	Imported from images; what remains assessed honestly

From the box arriving to your files going back.

Work we have closed →

Logged the day it lands, and the first look costs nothing Free

A case number goes on the parcel and a number on every drive the day it is opened, and an engineer settles what has actually happened before anything spins. The unit is examined on its own; each drive is assessed on our own equipment, never in a NAS that will try to rebuild. Back to you come two things together: a straight note of what is liftable and what is not, plus one figure, fixed and written down. Accept it, or decline and owe us nothing.

Nothing to pay for lookingA single figure, put in writingNo rebuilds, no repairs, no resets

The unit, and the drives, apart

The box and the disks are two different jobs. The unit is tested separately, because a dead power supply, a failed board or a bricked boot flash leaves the drives untouched more often than not. Each drive is then read on the bench: the ones that answer at full speed, and the weak or failed ones in clean air where they need head work. On units that hold an encryption key or a layout of their own, the unit is part of the data and is kept with it.

Unit and disks assessed separatelyFailing members to the clean bench

Every member imaged, once

Every disk, including any SLOG, is imaged. The pool is imported read-only from the images at the latest transaction group whose metadata passes its checksums, and rolled back further only where it must be; the datasets are mounted from that import and copied out, encrypted datasets unlocked with your key. Nothing is written to the originals and nothing is discarded.

Every drive, including the cacheWeak areas last

The set put back together, from the images

Order, chunk size, parity rotation and the reshape point are read from the drives' own metadata and the array is reassembled in software: mdadm and LVM under SHR, X-RAID and QTS pools; a ZFS pool imported read-only; Drobo's BeyondRAID zones reconstructed. The file system, Btrfs, ext4, XFS or ZFS, is repaired on the virtual volume, and encrypted volumes are unlocked there with the key you supply. Never on the originals.

Rebuilt in software, from imagesThe file system repaired on the virtual volume

You see the file list before you pay

What was recovered is listed for you first, and only then does a bill exist. Approve the list and it is invoiced; turn it down and it is not — and where nothing has come back, most jobs carry no charge at all. Recovered data travels home on fresh media bought in for your job, with the postage at our end. Your case is not closed until you have opened the files on a machine of your own.

No charge until you accept the figureFresh media, supplied with the job5–10 days at the bench

From the bench

The uberblock ring is the history. Dozens of earlier pool states sit on every disk until overwritten; a read-only import chooses among them. -F chooses for you and burns the rest.
A DEGRADED pool that still imports should be copied out and powered down, not scrubbed. A scrub reads every block of every member, which is where the next failure is found.
Send the SLOG. A separate log device holds synchronous writes not yet on the pool, and a pool imported without it is missing them.
Tell us what was typed. A forced import, a clear, a labelclear: each changes the plan, and honesty about it helps.

One job, followed all the way through.

UK · NDR-2026-0536JOB LOGGED ✓

A TrueNAS SCALE box with six drives in RAIDZ2 that would not import after a power cut, and an import -F that made it worse

Two drives had dropped in the power cut and the owner had forced the import, which discarded the last transactions. All six drives were imaged on the bench and the pool imported read-only from the images at the last transaction group before the force. The datasets came back complete, including the one the force had lost.

100% of the datasets recovered7 days here, and back by post

Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

Power down and copy out the exact zpool message
Note every disk's slot and serial
Send every disk, the SLOG and the boot device
Tell us every command that was run

What sets us back

zpool import -F or -X
zpool clear, or a scrub
zpool labelclear, or replacing a disk
Reinstalling TrueNAS to see whether it imports

Questions answered before you commit.

TrueNAS says the pool cannot be imported. Is the data gone?

Rarely. ZFS keeps a history of pool states on every disk, and a read-only import from images at an earlier transaction usually brings the datasets back whole. What loses data is forcing the import on the originals.

Should I try zpool import -F?

No. It rewinds the pool by discarding transactions and writes new labels to make the rewound state current. Sometimes it works; when it does not, the history it discarded is gone. The bench does the same rewind read-only, on images, and keeps the history.

I already ran -F and it is worse. What now?

Power down and send the disks. What -F discarded is still on the images unless the pool was written to afterwards, and the bench imports at the best remaining transaction.

What does it cost?

A pool of two or more disks is £500 + VAT upwards after the free look, fixed in writing; eight disks or more from £1,250 + VAT.

How long does it take?

5–10 days at the bench.

Where this usually leads.

TrueNAS, Unraid, OMV →TrueNAS / FreeNAS →Encrypted volumes and folders →QNAP →

Nothing gets worse while it is powered down.

Looking at it is free. Back comes a list of what opened and what did not, together with a single price to finish, set down in writing while you are still free to say no. Until that list reaches you, leave the unit off and the drives in their bays.

0800 6890668

Price my job Packing and posting

Every kind of NAS

Manufacturers

Whatever it is saying now

What it costs, and what follows