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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
