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

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

After a few minutes on Google I came across this wonderful page:

http://www.solarisinternals.com/wiki/index.php/ZFS_forensics_scrollback_script

where the author has published information about his python script which
locates the uberblocks on the raw disk and shows the user the most recent
transaction IDs, prompts the user for a transaction ID to roll back to, and
zeroes out all uberblocks beyond that point. Theoretically, I should be
able to use this script to get back to the transaction prior to my dreaded
'zfs destroy -R', then be able to recover the data I need (since no further
writes have been done to the source disks).

First, I know there's a problem in the script on FreeBSD in which the grep
pattern for the od output expects a single space between the output
elements. I've attached a patch that allows the output to be properly
grepped in FreeBSD, so we can actually get to the transaction log.

But now we are to my current problem. When attempting to roll back with
this script, it tries to dd zero'd bytes to offsets into the disk device
(/dev/ada1p3 in my case) where the uberblocks are located. But even
with kern.geom.debugflags
set to 0x10 (and I am runnign this as root) I get 'Operation not permitted'
when the script tries to zero out the unwanted transactions. I'm fairly
certain this is because the geom is in use by the ZFS subsystem, as it is
still recognized as a part of the original pool. I'm hesitant to zfs export
the pool, as I don't know if that wipes the transaction history on the
pool. Does anyone have any ideas?

Thanks,
-Reid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zfs_revert-0.1.py.patch
Type: application/octet-stream
Size: 1126 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130711/d5011222/attachment.obj>