Recovering from a dd_rhelp add_chunk error

If you've got a crashed disk, dd_rhelp is a very
useful tool for quickly recovering a large amount of data from just
about any failed disk. I used it earlier this week to help recover a
160GB linux LVM group member drive. Unfortunately, after a while of
running, it hit this error:

    dd_rhelp: error: add_chunk : invalid argument '0-(info)' (is not correctly formatted as number:number)

Here's
how you get past that. The problem is that dd_rhelp was not able to
determine the size of your hard disk automatically, so it is scanning
beyond the actual size, which of course fails. We need to tell it our
disk size manually.

First, make a backup of your logfile, for example:
    cp -rp sdb.log sdb.log.bad-eof
That way you can start over if you mess up.

Go to the first line in the original log file that states:
    dd_rescue: (warning): /dev/sda (282662620.0k): No space left on device!
Or something similar. Scroll up to the next line before that that reads:
    === COMPUTED VERSION OF LOG :
Delete all lines including and following this line, then save your file.

Obtain your filesystem size with fdisk:
    # fdisk -l /dev/sda
   
    Disk /dev/sda: 160.0 GB, 160000000000 bytes
    and so on...

In this case, your filesystem size would be 160000000000 bytes, or 160000000  kbytes.

Next,
change all the lines in the file stating "eof:nothing" to
"eof:160000000". Use your fs size in replacement of 160000000 kbytes.
You can quickly do this using sed:
    sed 's/eof:nothing/eof:160000000/g' -i sdb.log

Now re-run your dd_rhelp command. It should now continue to recover as normal!

Thanks to Valentin from dd_rhelp and "Master One" for leading me in the right direction.

UPDATE:
It seems that after a short time, I ran into the same error again. My
solution was to open the dd_rhelp script, look for the line that says:
    eof="nothing"
and change it to
    eof="160000000"
(of course, substituting your disk size in kb)

Re-do the cleanup above and re-run.

UPDATE 2: So I've found that dd_rhelp is slow, or at least, it's slow on my damaged disk. I suggest trying ddrescue instead (not to be confused with dd_rescue from above). It seems to be much more efficient at sidestepping bad data and gives a more concicse summary of recovery progress. This includes how much data has been recovered so far, lost so far, number of total errors, and transfer rates. For more info on the design differences between ddrescue and dd_rhelp, see the SpinRite wikipedia entry.