Re: [gentoo-user] Re: is ddrescue this slow?

[Stroller]

On 11 Jan 2010, at 00:14, Valmor de Almeida wrote:
> ...
> Indeed I am using GNU ddrescue and the -n flag is supposed to expedite
> the recovery of data as posted in
> http://www.cgsecurity.org/wiki/Damaged_Hard_Disk
>
> "The best solution - both faster and more efficient - seems to be
> Antonio Diaz's 'ddrescue' (ddrescue)"
>
> # first, grab most of the error-free areas in a hurry:
> ./ddrescue -n /dev/old_disk /dev/new_disk rescued.log
> # then try to recover as much of the dicy areas as possible:
> ./ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log

I remember reading a very similar summary - the words "grab most of  
the error-free areas in a hurry" seem quite familiar - when I started  
using ddrescue, a few months ago.

> The first step above finished; don't know how long it took but it was
> a long time (maybe 20 hours or more?) and the screen output was
>
>
> Press Ctrl-C to interrupt
> Initial status (read from logfile)
> rescued:         0 B,  errsize:       0 B,  errors:       0
> Current status
> rescued:    58811 MB,  errsize:  48909 kB,  current rate:       83 B/s
>   ipos:    58860 MB,   errors:      95,    average rate:    1365 kB/s
>   opos:    58860 MB,     time from last successful read:       0 s
> Copying non-tried blocks...
> ddrescue: write error: Input/output error
>
>
> Comparing with the screen output at the time of my first post,
>
> Current status rescued went from 58656 MB to 58811 MB, errsize went
> from 4408 kB to 48909 kB.
>
> Don't know how the write error: Input/output error message affect the
> data in the new drive copied to. Not sure whether I should do the next
> step with option -r 1.
>
> This failed drive is still bootable and the corruption is in the
> partitions /var (which I do not care) and /home; these cannot be
> mounted. I would like to attempt to get a couple of files from /home
> that were not in the most recent backup. Maybe I should try to rescue
> only the partition /home. However this partition is under LVM.
> Specifically, /dev/sda4 is a linux LVM partition. The volume group is
> vfda and the logical volume of interest is /dev/vfda/home which has
> reiserfs file system. Is it possible to rescue data only from this
> partition when under LVM?

I would try running fsck on a copy of the image.

Your original command was to clone to /dev/sdc - you can now safely  
`dd if=/dev/sdc2 of=/mnt/foo/olddrive.img` and then loopback mount the  
image. You should be able to fun fsck on it, also.  (Where sdc2 is the  
partition /home was on)

I have invested in a fair amount of hard-drive space recently, and the  
extra room allows you a lot of breathing space for operations like this.

If fsck doesn't work then you can dry photorec. I would try on both  
sdcX and olddrive.img (where X is the partition /home was on).

DISCLAIMER: I don't know anything about LVM or how that might affect  
things. In fact, I avoid LVM for this reason. I might do something  
like backing up (using `dd`) the other partitions that contribute to  
the affected volume groups, then lvm-mount them together with your  
sdcX and try an reiserfsck on the resultant logical volume. The idea  
position to be in (well, "ideal" once we have accepted the fact of the  
failed drive) is to have images of all your drives before you start  
mucking about any further; if the repair attempt fails you can revert  
to the images and try again a different way.


>>   Valmor: when I ran the `ddrescue -dr3` stage I had no success at
>> all, however the system was fine after a reboot & a `chkdsk`.
>> Better than it had been, in fact, on the old hard-drive. You might
>> have more luck getting *some* of the blocks showing as failed when
>> you run it on your drive, but don't be too disheartened if you don't.
>
> Stroller, you mean your rescue.log showed no problematic entries?

No, I had only one line in my rescue.log, my most recent attempt at  
this. The `ddrescue -dr3` stage errored without managing to recover  
that block, but it seems like the data in that block was not really  
important.

The old drive failed to completely boot Windows because of this bad  
block; the new drive - with that block missing - booted fine (perhaps  
after a chkdsk). So I can only conclude that - using the old drive -  
Windows died because some unimportant system file was thought to be  
there. It couldn't read the block and kept trying. With the new drive  
the file was clearly absent or damaged, so Windows was able to  
continue the boot without it. Perhaps some unimportant system service  
failed to start, but in any case the system worked fine.

I'm pretty sure I also dealt last year with another drive which had  
about 3 errors on it, but I don't remember any of the details.

> I got over 400 lines in my rescue.log file.
>
> root@sysresccd /root % head rescued.log
> # Rescue Logfile. Created by GNU ddrescue version 1.11
> # current_pos  current_status
> 0xDB45D9000     ?
> #      pos        size  status
> 0x00000000  0x9CE341000  +
> 0x9CE341000  0x00000200  -
> 0x9CE341200  0x0001F000  *
> 0x9CE360200  0x00000200  -
> 0x9CE360400  0x00020000  *
> 0x9CE380400  0x3BD63AC00  +


It seems to me that your drive was in a very bad way, and this is why  
you has so many errors. You don't say how large it was - ddrescue  
terminated at  58811 MB. Was it only a 60GB drive?

It seems to me that ddrecue died before managing to complete the first  
pass. I don't think you should have seen the "ddrescue: write error:  
Input/output error" line if the first pass completed ok - you should  
have just seen something like "Completed: XXX copied, Y errors". Then  
you would try a second pass (eg `ddrescue -r 3`) and *hope* to get  
fewer errors the second time around; the -r 3 tells ddrescue to keep  
trying, make 3 attempts to read this block before giving up. Because  
the logfile keeps a record of the failed blocks, when you run ddrescue  
with the -r flag it only tries the blocks that have previously failed.  
So you can quite safely keep running `ddrescue -r 3 /dev/old_disk /dev/ 
new_disk rescued.log`, optimistically hoping that maybe this time the  
read will be successful. The only important thing is to make sure you  
always use the same destination and rescued.log file when doing so -  
using the same rescued.log file ensures you're not wasting time trying  
blocks that you've already got on a previous pass, and using the same  
destination ensures that any blocks that are read successfully this  
time are written into an image file that is combined from the multiple  
passes.

I think that the "write error: Input/output error" line indicates that  
your drive really has failed badly & catastrophically, and that you're  
not going to get any more off it. Feel free to try though. Console  
yourself with the knowledge that ddrescue was the best tool for the  
job, and that in using it you did all you could have done to recover  
your data.

The number of errors you saw (95) indicates your drive was much worse  
than the ones I have recently worked on. I'm pretty sure my  
rescued.log was less than 40 lines long (I could `cat` or `less` it,  
and it fitted within my 80 wide x 50 tall terminal, I'm sure).

I hope this makes sense. I'm by no means an expert, but I'm glad to  
help in any way possible. Having lots of disk space helps a lot.

Stroller.