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

[Reid Linnemann]

Hey presto!

/> zfs list
NAME             USED  AVAIL  REFER  MOUNTPOINT
bucket           485G  1.30T   549M  legacy
bucket/tmp        21K  1.30T    21K  legacy
bucket/usr      29.6G  1.30T  29.6G  /mnt/usr
bucket/var       455G  1.30T  17.7G  /mnt/var
bucket/var/srv   437G  1.30T   437G  /mnt/var/srv

There's my old bucket! Thanks much for the hidden -T argument, Volodymyr!
Now I can get back the remainder of my missing configuration.


On Fri, Jul 12, 2013 at 7:33 AM, Volodymyr Kostyrko <c.kworr at gmail.com>wrote:

> 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.
>