I have written an python script that enables to get back already deleted files and pools/partitions. This is highly experimental, but I managed to get back a moths work when all the partitions were deleted by accident(and of course backups are for the weak ;-)
I hope someone can pass this information to the ZFS forensics project or where this should be.. First the basics and the HOW-TO is after that. And i am not an solaris or ZFS expert, i am sure here are many things to improve, i hope you can help me out with some problems this still has. [b]Basics:[/b] Basically this script finds all the uberblocks, reads their metadata and orders them by time, then enables you to destroy all the uberblocks that were created after the event that you want to scroll back. Then destroy the cache and make the machine boot up again. This will only work if the discs are not very full and there was not very much activity after the bad event. I managed to get back files from an ZFS partition after it was deleted(several) and created new ones. I got so far by the help of these materials, the ones with * are the key parts: *http://mbruning.blogspot.com/2008/08/recovering-removed-file-on-zfs-disk.html* http://blogs.sun.com/blogfinger/entry/zfs_and_the_uberblock *http://www.opensolaris.org/jive/thread.jspa?threadID=85794&%u205Etstart=0* http://opensolaris.org/os/project/forensics/ZFS-Forensics/ http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch04s06.html http://www.lildude.co.uk/zfs-cheatsheet/ [b]How-to[/b] This is the scenario i had... First check the pool status: $zpool status zones >From there you will get the disc name e.g:c2t60060E800457AB00000057AB00000146d0 Now we look up the history of the pool so we can find the timeline and some uberblocks(their TXG-s) where to scroll back: zpool history -il zones Save this output for later use. You will defently want to backup the disk before you continue from this point: e.g. ssh r...@host "dd if=/dev/dsk/c..." | dd of=Desktop/zones.dd Now take the script that i have attached zfs_revert.py It has two options: -bs is block size, by default 512 (never tested) -tb is number of blocks:[this is mandatory, maybe someone could automate this] To find the block size in solaris you can use prtvtoc /dev/dsk/c2t60060E800457AB00000057AB00000146d0 | grep sectors >From there look at the "sectors" row. If you have a file/loop device just sizeinbytes/blocksize=total blocks Now run the script for example: ./zfs_revert.py -bs=512 -tb=41944319 /dev/dsk/c2t60060E800457AB00000057AB00000146d0 This will use dd, od and grep(GNU) to find the required information. This script should work on linux and on solaris. It should give you a representation of the found uberblocks(i tested it with a 20GB pool, did not take very long since the uberblocks are only at the beginning and ending of the disk) Something like this, but probably much more: TXG, time-stamp, unixtime, addresses(there are 4 copy's of uberblocks) 411579 05 Oct 2009 14:39:51 1254742791 [630, 1142, 41926774, 41927286] 411580 05 Oct 2009 14:40:21 1254742821 [632, 1144, 41926776, 41927288] 411586 05 Oct 2009 14:43:21 1254743001 [644, 1156, 41926788, 41927300] 411590 05 Oct 2009 14:45:21 1254743121 [652, 1164, 41926796, 41927308] Now comes the FUN part, take a wild guess witch block might be the one, it took me about 10 tryes to get it right, and i have no idea what are the "good" blocks or how to check this up. You will see later what i mean by that. Enter the last TXG you want to KEEP. Now the script writes zeroes to all of the uberblocs after the TXG you inserted. Now clear the ZFS cache and reboot(better solution someone???) rm -rf /etc/zfs/zpool.cache && reboot After the box comes up you have to hurry, you don't have much time, if any at all since ZFS will realize in about a minute or two that something is fishy. First try to import the pool if it is not imported yet. zpool import -f zones Now see if it can import it or fail miserably. There is a good chance that you will hit Corrupt data and unable to import, but as i said earlier it took me about 10 tries to get it right. I did not have to restore the whole thing every time, i just took baby steps and every time deleted some more blocks until i found something stable(not quite, it will still crash after few minutes, but this is enough time to get back conf files or some code) Problems and unknown factors: 1) After the machine boots up you have limited time before ZFS realizes that it has been corrupted(checksums? I tried to turn them off but as soon as I turn checksumming off it crashes and when i could turn it of then the data might be corrupted) 2) If you copy files and one of them is corrupted the whole thing halts/crashes and you have to start with the zfs_revert.py script and reboot again. 3) It might be that reverting to a TXG where the pool was exported then there is a better chance of importing it after reboot, but i am not sure. 4) Is there a way to force the pool to stay in tact even if ZFS does not want to? 5) Why does the zpool command totally hang if i try to do anything with the reverted disk, it just hangs after it realizes there is something wrong(that is why i have to reboot after every try and this takes a lot of time) 6) I did try this thing on loop devices before. Used 1gb size and there the ZFS did not crash after i deleted some uberblocks, might be because i only deleted a file and partition then restored them(did not make new files or pools). Worked perfectly, so the scenario might had been a worst case. If something in this post is unclear or you have any suggestions/ideas on how to make this thing better then speak out. You can e-mail me if you don't want to post in a forum mardi...@gmail.com I did not add a licence to this script, only my name and contact, i don't know what Licences are popular in the solaris world, but GPL2 is a good idea? Sorry if my English is not perfect, this is not my native language. -- This message posted from opensolaris.org
zfs_revert.py
Description: Binary data
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
