Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem

Volodymyr Kostyrko c.kworr at
Fri Jul 12 12:33:35 UTC 2013

11.07.2013 17:43, Reid Linnemann написав(ла):
> So recently I was trying to transfer a root-on-ZFS zpool from one pair of
> disks to a single, larger disk. As I am wont to do, I botched the transfer
> up and decided to destroy the ZFS filesystems on the destination and start
> again. Naturally I was up late working on this, being sloppy and drowsy
> without any coffee, and lo and behold I issued my 'zfs destroy -R' and
> immediately realized after pressing [ENTER[ that I had given it the
> source's zpool name. oops. Fortunately I was able to interrupt the
> procedure with only /usr being destroyed from the pool and I was able to
> send/receive the truly vital data in my /var partition to the new disk and
> re-deploy the base system to /usr on the new disk. The only thing I'm
> really missing at this point is all of the third-party software
> configuration I had in /usr/local/etc and my apache data in /usr/local/www.

You can try to experiment with zpool hidden flags. Look at this command:

zpool import -N -o readonly=on -f -R /pool <pool>

It will try to import pool in readonly mode so no data would be written 
on it. It also doesn't mount anything on import so if any fs is damaged 
you have less chances triggering a coredump. Also zpool import has a 
hidden -T switch that gives you ability to select transaction that you 
want to try to restore. You'll need a list of available transaction though:

zdb -ul <vdev>

This one when given a vdev lists all uberblocks with their respective 
transaction ids. You can take the highest one (it's not the last one) 
and try to mount pool with:

zpool import -N -o readonly=on -f -R /pool -F -T <transaction_id> <pool>

Then check available filesystems.

Sphinx of black quartz, judge my vow.

More information about the freebsd-hackers mailing list