Stroller wrote: [snip] > > I would try running fsck on a copy of the image. >
I did try and thought I would post here some final info just for the record. I proceeeded with the command r...@sysresccd /root % ddrescue -r 1 /dev/sda /dev/sdc rescued.log which took ~50 hours to finish with the message: Press Ctrl-C to interrupt Initial status (read from logfile) rescued: 58811 MB, errsize: 48909 kB, errors: 95 Current status rescued: 77815 MB, errsize: 2210 MB, current rate: 0 B/s ipos: 66589 MB, errors: 598, average rate: 56872 B/s opos: 66589 MB, time from last successful read: 18.5 m Trimming failed blocks... ddrescue: write error: Input/output error Again the same error message. I did not care about it and moved forward to mount the /dev/sdc drive. Enabled the LVM volume groups with vgchange -a y (all this under the systemrescuecd boot), mounted the partition of interest under LVM control and did a reiserfsck --check /dev/myvg/mylv It ended with 1 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Fri Jan 15 11:46:23 2010 ########### The next step was then reiserfsck --rebuild-tree --logfile rebuild.log /dev/myvg/mylv I was then able to mount the partition and inspect the newly created lost+found/ directory. Surprisingly I was able to find the file I was looking for!! It was the first time I tried this kind of HDD forensics and was surprised with the time that it took to recover data from a relative low storage drive: 80GB. The rebuild.log file had over 8000 lines. Stroller, thanks for all your comments and suggestions. Yes having extra disk space is a must to be able to recover data. -- Valmor > > 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. > > >
