Date: Thu, 11 Jul 2013 09:43:34 -0500 From: Reid Linnemann <linnemannr@gmail.com> To: freebsd-hackers@freebsd.org Subject: Attempting to roll back zfs transactions on a disk to recover a destroyed ZFS filesystem Message-ID: <CA%2B0MdpMj81=Ct-ZUJ7N-TYO=OCHeEomU4Xa70sFVVoBoyETzkQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--001a11c312423a26da04e13d6b2b Content-Type: text/plain; charset=ISO-8859-1 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 --001a11c312423a26da04e13d6b2b Content-Type: application/octet-stream; name="zfs_revert-0.1.py.patch" Content-Disposition: attachment; filename="zfs_revert-0.1.py.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hj01fgkc0 LS0tIHpmc19yZXZlcnQtMC4xLnB5Lm9yaWcJMjAxMy0wNy0xMSAwOToxMTozOS41NTAyODQ5OTUg LTA1MDAKKysrIHpmc19yZXZlcnQtMC4xLnB5CTIwMTMtMDctMTEgMDk6MTI6MDkuMzA3Mjc2MTYx IC0wNTAwCkBAIC02NSw4ICs2NSw4IEBACiBwcmludCAnUmVhZGluZyBmcm9tICVzIGJsb2NrcyB0 byB0aGUgZW5kJyVsX3NraXAKIAogI2dldCB0aGUgdWJlcmJsb2NrcyBmcm9tIHRoZSBiZWdpbm5p bmcgYW5kIGVuZAoteWJlcmJsb2Nrc19hPWZvcm1hdHN0ZChzdWJwcm9jZXNzLlBvcGVuKCdzeW5j ICYmIGRkIGJzPSVzIGlmPSVzIGNvdW50PSVzIHwgb2QgLUEgeCAteCB8ICVzIC1BIDIgImIxMGMg MDBiYSIgfCAlcyAtdiAiXC1cLSInJShicyxmaWxlLCBhX2NvdW50LGdyZXBfY21kLGdyZXBfY21k KSwgc2hlbGw9VHJ1ZSwgc3Rkb3V0PXN1YnByb2Nlc3MuUElQRSkuY29tbXVuaWNhdGUoKVswXSkK LXliZXJibG9ja3NfbD1mb3JtYXRzdGQoc3VicHJvY2Vzcy5Qb3Blbignc3luYyAmJiBkZCBicz0l cyBpZj0lcyBza2lwPSVzIHwgb2QgLUEgeCAteCB8ICVzIC1BIDIgImIxMGMgMDBiYSIgfCAlcyAt diAiXC1cLSInJShicyxmaWxlLCBsX3NraXAsZ3JlcF9jbWQsZ3JlcF9jbWQpLCBzaGVsbD1UcnVl LCBzdGRvdXQ9c3VicHJvY2Vzcy5QSVBFKS5jb21tdW5pY2F0ZSgpWzBdKQoreWJlcmJsb2Nrc19h PWZvcm1hdHN0ZChzdWJwcm9jZXNzLlBvcGVuKCdzeW5jICYmIGRkIGJzPSVzIGlmPSVzIGNvdW50 PSVzIHwgb2QgLUEgeCAteCB8ICVzIC1BIDIgImIxMGMgXCswMGJhIiB8ICVzIC12ICJcLVwtIicl KGJzLGZpbGUsIGFfY291bnQsZ3JlcF9jbWQsZ3JlcF9jbWQpLCBzaGVsbD1UcnVlLCBzdGRvdXQ9 c3VicHJvY2Vzcy5QSVBFKS5jb21tdW5pY2F0ZSgpWzBdKQoreWJlcmJsb2Nrc19sPWZvcm1hdHN0 ZChzdWJwcm9jZXNzLlBvcGVuKCdzeW5jICYmIGRkIGJzPSVzIGlmPSVzIHNraXA9JXMgfCBvZCAt QSB4IC14IHwgJXMgLUEgMiAiYjEwY1wrIDAwYmEiIHwgJXMgLXYgIlwtXC0iJyUoYnMsZmlsZSwg bF9za2lwLGdyZXBfY21kLGdyZXBfY21kKSwgc2hlbGw9VHJ1ZSwgc3Rkb3V0PXN1YnByb2Nlc3Mu UElQRSkuY29tbXVuaWNhdGUoKVswXSkKIAogCiB5YmVyYmxvY2tzPVtdCg== --001a11c312423a26da04e13d6b2b--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B0MdpMj81=Ct-ZUJ7N-TYO=OCHeEomU4Xa70sFVVoBoyETzkQ>