ddranalog.pl is a perl script that uses ddrescue to copy data from a
failing HD to a new one while avoiding bad blocks. Its logic is very
simple, it finds the biggest unknown area on disk, divides it in 2, and
copy the second half until it reaches the end or a bad sector. Then
finds another unknown area, divides, and so on. Naturally this method
has its flaws too, but it's much better than a simple linear scan.

I usually take the bad disk, a good empty disk at least as large as the
bad one (CAUTION! if it isn't new, it needs to be zeroed beforehand),
and another disk or usb key or some other media (even a floppy will do)
for a rescue log, connect to a computer and boot Knoppix on it (from CD,
network, big usb key, whatever is available). If you're a bit familiar
with Linux you can read on, otherwise you won't understand much I'm
afraid.

I either set up the source bad disk as a raw device, or turn off OS
caching on it with "hdparm -a0" command. Then I run the script like
this: "ddranalog.pl -e 0 -c 1 -n /dev/source_disk /dev/dest_disk
/path/to/logfile". The "logfile" will be created by ddrescue and the
path should point to some r/w mounted non-volatile media.

I let it run for as long as needed. If the script starts hitting bad
blocks too often, I try to disable disk read ahead with "hdparm -A0"
command. It makes linear reads sometimes as slow as 700kb/s, but usually
makes it spend much less time reading bad blocks. YMMV. The command
works for IDE drives. For SATA you can try:

echo 0 >/sys/block/sdx/read_ahead_kb
echo 1 >/sys/block/sdx/nr_requests


The script is stupid and if you let it run for a long enough time it will
split the disk areas until they are single byte in size, so if I see that
the operation is near the end I kill the script with Ctrl+C and finish it
with "ddrescue /dev/source_disk /dev/dest_disk /path/to/logfile".

Data copying can be interrupted at any time, and continued at some later
time. Thus, when ddrescue starts hitting bad blocks time after time, it
may be a good idea to stop the operation and try some file rescue
software on the destination drive, provided that the rescue software do
not modify data in-place. Maybe all the important files will be
recoverable already, so the further scanning of the bad disk won't be
needed. Maybe you'll later realize that some important stuff is still
missing, then just copy some more from the source disk and try again.

The unfortunate thing about file recovery software is that nearly all
such software requires Windows. Unfortunately, Windows is so stupid it
may try to run chkdsk when it sees a drive with damaged file system,
which usually makes a total mess on the fs and destroys important data,
which might have been recoverable otherwise. DON'T LET IT DO IT! You
have 10 seconds to press a key and abort chkdsk. Another problem is that
Windows will try to mount the drive r/w, and may also try to write its
"System Volume Information" folder on it. See, there's a reason why data
recovery companies use hardware "write locker" devices, or run Windows
in VMWare or other virtualization software that can block writes. I
don't know if there's a way to turn off this Windows stupidity.

Other hints:

- if the bad drive has ATA connector, try to not connect it with another
drive on the same cable. If the disk crashes, it may lock up the other
drive too.

- if the disk is in USB or firewire enclosure, get it out of the
enclosure and connect directly. HD enclosures tend to behave very badly
when the disk is failing. They lock up. They return bogus data.


Comments? Suggestions? mailto:pp@siedziba.pl