Date: Fri, 12 Jul 2013 09:41:56 -0500 From: Reid Linnemann <linnemannr@gmail.com> To: Volodymyr Kostyrko <c.kworr@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem Message-ID: <CA%2B0MdpMfa-vMKGXrvgbJu8QQd4vqqAriLedENTHAaqVGgNwHGQ@mail.gmail.com> In-Reply-To: <51DFF79C.905@gmail.com> References: <CA%2B0MdpMj81=Ct-ZUJ7N-TYO=OCHeEomU4Xa70sFVVoBoyETzkQ@mail.gmail.com> <51DFF79C.905@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B0MdpMfa-vMKGXrvgbJu8QQd4vqqAriLedENTHAaqVGgNwHGQ>