Or, how to scrape data off a broken harddrive with unnecessary cruelty
The other day a friend of mine sent a terabyte harddrive by which, dueto events unknown, had ceased to perform its duty in a Linux-based NAS.
Indeed, it seemed as if the disk in question 1) indeed contained an ext3filesystem, and 2) had lost its partition table, and as no informationabout the partitioning was available, I started off to try the usualtools to guess a layout. I first triedGPart , thenTestdisk, both without muchsuccess.
I proceeded to try and find a partition table manually; as there areusually backup copies of this table present. Manual search, however,turned out to be quite tedious, so I searched for a way to automatethis.
I came up with this little Python thing:
from subprocess import *def losetup(offs): cmd = ['/sbin/losetup', '-o', str(offs), '/dev/loop0', '/dev/sdb'] call(cmd)def fsck(n): print "nTrying byte %s" % n cmd = ['/sbin/fsck.ext2', '-n', '/dev/loop0'] p = Popen(cmd, stdout=PIPE, stderr=PIPE) out, err = p.communicate() if p.returncode != 8: print out print errdef delo(): cmd = ['/sbin/losetup', '-d', '/dev/loop0'] call(cmd)for n in xrange(0, 4096): losetup(n) fsck(n) delo()
It really is a bit brutal. It iterates through the first 4k bytes of theharddrive (I made a backup image beforehand) and tries to perform a fsck(without actually changing anything). I basically let fsck do the testif a partition table can be found (or a backup). And, much to mysurprise, fsck actually found a backup partition table using an offsetof 512, so all I had to do was losetup once more, and this time performthe fsck for real. Almost all of the data could be recovered! Yaylosetup and Python!