In Which I Discuss a Hard Drive Recovery Scenario And Elect Not To Put the Disk In The Freezer
Got a bad or dying hard drive? Read on. This is part tutorial, part introduction to data recovery ideas, and part case study. Also, I've linked to some PPC Mac binaries that are useful if you don't have the Developer Tools installed on your Mac and you need to recover some data, hence this whole post is somewhat Mac-skewed, though the theory is applicable no matter what kind of computer you have. Hopefully this is of some help to someone.
Not to be confused with the similar and similarly named dd_rescue and dd_rhelp (which were precursors to this program), the GNU ddrescue program is a useful command-line utility that helps restore failing hard drives. Here is a zipfile containing a Mac PPC binary and a readme, should you be having trouble getting ddrescue working on your Mac. Note that it's available for compilation on just about any unix-like OS; google ddrescue if you need more information or if you need to compile it for different architectures.
The basic idea is that because block-wise data recovery can stall for long periods of time at errors, it's prudent to read all the good data off the drive quickly first, then go back to revisit problem areas and work at them until (hopefully) all the data can be recovered; at worst in the output file there are blank areas where there were unrecoverable sections of the original disk. Because this process can take a significant amount of time it is possible to run the program, abort it (with a control-C), and resume it again later to finish recovery, if necessary (though make sure you specify the same logfile so it is able to pick up where it left off).
Save the above .zip archive to the desktop and extract it. It should produce a ddrescue folder, inside which will be the unix (Mac PPC executable, runs under Rosetta emulation on Intel macs) and a text file explaining usage. Launch Terminal and cd to the ddrescue folder (type "cd " then drag the folder icon onto the Terminal window). Copy the executable to your /usr/bin directory with the following (it should prompt you for your password):
sudo cp ddrescue /usr/bin/ddrescue
Figure out which drive you need to run ddrescue on by running Disk Utility, then getting info on the partition you wish to rescue. The Disk Identifier is the string you need (hooking up a failing laptop hd in a firewire enclosure, knowing I want the second partition of the disk yields the identifier "disk1s2"; yours may well be different).
Run ddrescue with the correct disk specified (all the disks live under the /dev/ hierarchy), your desired output file, and a logfile name for later resuming in case you need to stop and start over (the process can take a LONG time). In my case, the command line was:
ddrescue /dev/disk1s2 ACER.dmg logfile
which runs ddrescue on the correct block device, outputs the reconstructed disk image to ACER.dmg and logs progress in logfile (both files go in the current directory).
In my case, the partition to be rescued was about 54GB in size with (at max) about 140 errors-represented by 9000KB (just shy of 10MB) of bad blocks. The better areas of the drive read after some time (about 18 hours), and then the remainder of the time was focused on the bad areas (only about 3MB, with ddrescue scrubbing repeatedly over them to extract data thus reducing the number of errors and the size of the error regions-it shows the stats in real time on the command line, which is moderately more interesting than paint drying, though heartening if you have a vested interest in the data you are recovering). I stopped it a few times with control-C after rescuing most of the drive and reran it with --max-retries=2 (less obsessive but faster). In the end I was left with a little under 3MB unrecovered, which was gudenuff (I could have stuck it in a ziplog bag and chucked it in the freezer for a few, and then tried again if I was really crazy about that last 3MB).
Also, the zipfile ddrs2r.zip contains some perl scripts that summarize the log file and also let you use other utilities to figure out what files are hosed on your recovered disk image. See here for more info on these scripts. A GUI would be nice, but so far it seems no one has stepped up to the plate and made one.
A final note: when using the recovered disk image, it would be prudent to lock it (make it read-only) first before looking around it and playing, lest you change it (which, if you wish to keep running ddrescue to get the last few blocks, might really F things up). In my case it looks like all the data that my client cares about is recovered! Yay for happy clients!
Not to be confused with the similar and similarly named dd_rescue and dd_rhelp (which were precursors to this program), the GNU ddrescue program is a useful command-line utility that helps restore failing hard drives. Here is a zipfile containing a Mac PPC binary and a readme, should you be having trouble getting ddrescue working on your Mac. Note that it's available for compilation on just about any unix-like OS; google ddrescue if you need more information or if you need to compile it for different architectures.
The basic idea is that because block-wise data recovery can stall for long periods of time at errors, it's prudent to read all the good data off the drive quickly first, then go back to revisit problem areas and work at them until (hopefully) all the data can be recovered; at worst in the output file there are blank areas where there were unrecoverable sections of the original disk. Because this process can take a significant amount of time it is possible to run the program, abort it (with a control-C), and resume it again later to finish recovery, if necessary (though make sure you specify the same logfile so it is able to pick up where it left off).
Save the above .zip archive to the desktop and extract it. It should produce a ddrescue folder, inside which will be the unix (Mac PPC executable, runs under Rosetta emulation on Intel macs) and a text file explaining usage. Launch Terminal and cd to the ddrescue folder (type "cd " then drag the folder icon onto the Terminal window). Copy the executable to your /usr/bin directory with the following (it should prompt you for your password):
sudo cp ddrescue /usr/bin/ddrescue
Figure out which drive you need to run ddrescue on by running Disk Utility, then getting info on the partition you wish to rescue. The Disk Identifier is the string you need (hooking up a failing laptop hd in a firewire enclosure, knowing I want the second partition of the disk yields the identifier "disk1s2"; yours may well be different).
Run ddrescue with the correct disk specified (all the disks live under the /dev/ hierarchy), your desired output file, and a logfile name for later resuming in case you need to stop and start over (the process can take a LONG time). In my case, the command line was:
ddrescue /dev/disk1s2 ACER.dmg logfile
which runs ddrescue on the correct block device, outputs the reconstructed disk image to ACER.dmg and logs progress in logfile (both files go in the current directory).
In my case, the partition to be rescued was about 54GB in size with (at max) about 140 errors-represented by 9000KB (just shy of 10MB) of bad blocks. The better areas of the drive read after some time (about 18 hours), and then the remainder of the time was focused on the bad areas (only about 3MB, with ddrescue scrubbing repeatedly over them to extract data thus reducing the number of errors and the size of the error regions-it shows the stats in real time on the command line, which is moderately more interesting than paint drying, though heartening if you have a vested interest in the data you are recovering). I stopped it a few times with control-C after rescuing most of the drive and reran it with --max-retries=2 (less obsessive but faster). In the end I was left with a little under 3MB unrecovered, which was gudenuff (I could have stuck it in a ziplog bag and chucked it in the freezer for a few, and then tried again if I was really crazy about that last 3MB).
Also, the zipfile ddrs2r.zip contains some perl scripts that summarize the log file and also let you use other utilities to figure out what files are hosed on your recovered disk image. See here for more info on these scripts. A GUI would be nice, but so far it seems no one has stepped up to the plate and made one.
A final note: when using the recovered disk image, it would be prudent to lock it (make it read-only) first before looking around it and playing, lest you change it (which, if you wish to keep running ddrescue to get the last few blocks, might really F things up). In my case it looks like all the data that my client cares about is recovered! Yay for happy clients!