My landlord’s old PC has suffered several failures over the years, including several fans and power supplies and at least one hard drive. When I moved in a year ago they called me over to replace yet another PSU for them, and a few months later to figure out why the machine would not even begin to boot.
The suspect was immediately either the IDE controller or both of its drive. After transplanting the drives to a seperate machine and failing to find their partitions, and after trying a new drive in the machine it was looking as though possibly all were fried.
A couple months have passed and my landlord has had me build him a new computer and the day has come to try to recover his data… Below is the process I’ve used to diagnose and recover his files.
1) Attempt to image the entirety of the drive
With the physical stability of the drives in question, the first order of business was to mitigate the amount of work done against the failed drives themselves. Windows claimed the drives were unformatted, and linux would not let me mount them (although their partition tables were visible).
The weapon of choice was dd, a data-copy utility that works at a low level and with a little bit of knowledge can be an invaluable tool. dd can be extremely dangerous if you aren’t careful with it!!! dd is basically a data-copy tool which takes a couple arguments; “if” (input file) and “of” (output file). The device/file you set “if” to will be copied to the “of” device/file. You can add more parameters to control the amount of data copied, and the blocksize that the harddrive’s partition uses.
Example: Backing up a drive’s partition table
The drive partition table is stored in the first kilobyte (not certain this is always true, it may depend on the block size) of the partition. To make a backup:
dd if=/dev/[drive] of=$HOME/[drive]_part.bak bs=1k count=1
This will copy the first kilobyte (bs=1k count=1) from /dev/[drive] to a file called [drive]_part.img in the executing user’s home directory.
Back to data recovery with dd… to make an image of the entire drive I used the following command, note that this creates a file equal to the physical size of the disk, so be sure you have enough room. i.e. if you have a 1GB partition on a 100GB drive (and 99GB unpartitioned) the resulting image will be 100GB.
dd if=/dev/[drive] of=$HOME/backups/[drive].dmg bs=512 (NOTE: bs varies depending on the filesystem settings, common sizes are 512, 1024, and 4096, although many others are possible. One way to determine the block size is to try copying one 512b block, one 1k block, and one 4k block (so on so forth). Wrong block sizes should result in an error, ruling out the selection.
dd does not work through errors by default, so if it finds bad sectors or other obstacles it will error out–providing evidence of the type of failure on your hands. I lucked out, and dd ran through the full 20GB drive without error which told me that the drive failure was likely with the partition or filesystem and not a hardware failure. If dd fails due to drive errors such as bad sectors you can use ddrescue or gddrescue, both of which use dd and will replace errors with null (nothing) values in the image, resulting in a backup image of as much data as possible. One other very cool feature is if you use these tools to copy from a device that is inconsistently reading it’s contents then you can run the tool multiple times, and if a 2nd (or 3rd, 4th…) pass is able to successfully read what a previous pass failed at it will fill in the void left by the earlier passes due to the error. This proves wonderfully useful on scratched CDs, among other things.
Now for the real fun: With the disk image in place I shutdown and remove the physical drive from the machine (so that if it is a hardware issue, any further damage will be prevented. My landlord was considering having the drive professionally recovered if we were unsuccessful, so we wanted to make sure we did no further harm to it). Upon booting back up I set the drive image to a loopback device, which lets you mount a disk image like it were a regular drive (iso’s work great with this)
2) Attempt to mount the image
After unplugging and removing the dead drive I tried to mount the image I’d just made:
mount /home/steve/[drive].dmg -o loop -t vfat /mnt/recovery
But it failed, barking about a bad superblock. This was starting to look more like a bad partition table than a fried drive–so back in went the drive.
3) A great utility
After some Googling I found multiple references to a utility called testdisk which is a free drive recovery tool. My only beef was that it only seems to work on physical drives, not loopback images (like what I made above). So with the drive back in I ran testdisk, and after selecting the appropriate drive and type from it’s menus it immediately told me I had a bad partition table.
Using the restore and scan options of testdisk brought the drive totally back to life! I was very impressed by it, as it seems to have a lot of power under the hood but not a lot of difficulty in it’s user-interface.
The drive lived! I saved it’s updated partition tables back to the drive, rebooted as it recommened and was able to successfully mount the partition.
4) Get everything off the drive
There was no sense running the risk of letting the drive cause more problems, especially as there was over a Terabyte of free space on the new machine. So I rsync’d everything off of it immediately:
rsync -av /mnt/[mountpoint] /var/storage/recovered/
5) Shred the drive
The old 20GB drive was recovered, and my landlord wanted to recycle it (give it away). So first we wanted to shred any remnants of it’s contents. There is a GNU utility aptly named “shred” that does specifically this.
And many hours later (shred defaults to 25 passes, which is extreme but can be changed) the drive was wiped clean.