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.
r...@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.
