Hi Matt,
Your recovery process is obviously going rather slowly, but,
take heart, sometimes the process speeds up after it gets past
the worst error area. Unless there are only a few errors, the
copy time is almost entirely proportional to the number of
errors, because error-free sectors copy so quickly and bad
sectors take so long to fail. (Unfortunately, I don't know of
any way to stop the drive's very slow internal error recover
process, for a quicker first pass.)
Your strategy seems pretty good except for a couple of small
mistakes. First, your recovery command should have been:
ddrescue -B -n /dev/hda /dev/hdb rescued.log
instead of
ddrescue -B -n /dev/hda1 /dev/hdb rescued.log
Unfortunately, the command you used will omit the MBR, so
there'll be no partition table on /dev/hdb. Oops!
I do NOT recommend that you start over. Once you've scraped
some data from a drive, it is never a good idea to throw it
away and start over. But it would be a good idea to go ahead
and grab the part that you missed:
ddrescue -B -n -s 63 /dev/hda rescued_mbr.ima rescued_mbr.log
(That's assuming that /dev/hda1 starts at sector 63. You can
check that with fdisk -lu /dev/hda.)
You're gonna have a little chore, eventually, putting the two
pieces back together... you'll have to do something like this
(assuming that /dev/hdb is a scratch drive, and /dev/hdc is the
eventual new drive):
# Copy the MBR / primary partition table:
ddrescue -B rescued_mbr.ima /dev/hdc
# Copy the first (only?) data partition:
ddrescue -B /dev/hdb /dev/hdc1
Secondly, I think you mistake how SpinRite works. Your step #4
needs to run SpinRite on the original (failing) drive, not on
the copy. (Note: my ddr2sr.pl ddrescue-to-SpinRite script
will help you target just the bad areas of the drive with
SpinRite.)
When ddrescue finishes, before you run SpinRite, the new copy
will have only two kinds of sectors: those which contain
perfect data, and those which have nothing at all (probably
zeros, if /dev/hdb was initially all zeros).
Then, when SpinRite has finished working on the bad sectors,
you'll have two kinds of formerly-bad sectors: Those which
were fully recovered (probably about 10% of them), and those
which were only partially recovered (the other 90%). You can
then use ddrescue to add the (fully partially) recovered
sectors to /dev/hdb. But be sure to save a copy of your
rescued.log file first, because ddrescue can't tell the
difference between the fully recovered sectors and the
partially recovered sectors -- they will all read
successfully when ddrescue sees them.
So, after you use ddrescue to add the SpinRite-recovered
sectors to /dev/hdb, the rescued.log file will no longer be
an accurate record of which parts if the drive are damaged.
(Dd-rescue's logfile has no mechanism for representing
damaged/partially-recovered sectors.) But the combination of
the new and old ddrescue log files, plus the SpinRite logfile,
encapsulates that information. My ddr2nfi.pl tool uses all
three logfiles to generate NFI commands for the truly damaged
sectors, for trying to deduce which files are impacted by
the damage. (Note: run the resulting .bat file of NFI
commands on a scratch copy of the recovered drive, not the
main/best copy, since Windows always messes with a drive
when it mounts it.)
For hours of entertainment, download my Perl scripts that
I use when doing dd-rescue recoveries. One
http://www.burtonsys.com/download/ddr2sr.zip
It contains:
clustersize.pl -- Shows cluster size(s) for FAT and NTFS partitions
ddrsummarize.pl -- Summarize a ddrescue log file
ddrsplit.pl -- DDRescue logfile SPLITter
ddrcombine.pl -- DDRescue logfile COMBINEr
ddrlogand.pl-- DDR LOGical .AND.
ddrlogor.pl -- DDR LOGical .OR.
ddrlognot.pl-- DDR LOGical .NOT.
ddr2sr.pl -- ddrescue-to-SpinRite
ddr2nfi.pl -- DDRescue to NFI
nficruncher.pl -- Process the output of many NFI commands
fat32inf.pl -- FAT32 info (this one is still under construction)
foreach.pl -- Repeat a command for each filename or argument
ddrcopyincrement.pl -- Copy additional recovered sectors
ddrwipe.pl -- Obliterate all the GOOD sectors on a failing disk
drive
samplescripts.zip -- some shell scripts
ddrescue_perl_helper_programs.txt -- documentation (see also comments in the
scripts)
There are examples in the samplescripts.zip of using a
raw device for a later pass to read sector-at-a-time,
so that the unrecovered parts will be down to a granularity
of one sector, instead of a full Linux buffered disk block.
Unfortunately, raw devices vary in implementation between
Linux versions, so you might have to fiddle with the scripts
to make that part work.
Unfortunately, some of the other scripts assume that the
destination is a copy of the full drive, including MBR, and
expect the logfile to describe a whole drive. After you put
the two
