On Sat, Jan 9, 2010 at 11:10 AM, Stroller <strol...@stellar.eclipse.co.uk>wrote:
> > On 9 Jan 2010, at 09:23, Neil Bothwick wrote: > >> On Sat, 9 Jan 2010 07:20:18 +0000, Valmor de Almeida wrote: >> >> Sometimes the "current rate" reads 0 B/s for a long time... and "time >>> from last successful read" can be 8m. >>> >>> Would any one know whether this is normal? >>> >> >> Doesn't ddrescue retry on blocks it cannot read? That would explain the >> variable read rate, even the period of zero activity. If your drive is >> that badly damaged, dd would have been no use anyway. >> > > I think Valmor is using GNU ddrescue, with which one makes the multiple > passes manually. The "-n" flag on the command line that Valmor posted > (`ddrescue -n /dev/sda /dev/sdc rescued.log`) relates to the examples given > in the GNU manual page [1]. I believe that GNU ddrescue is the better > version - it was inspired by garloff's original work, and makes > improvements, but it operates differently. > > 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 <http://savannah.gnu.org/projects/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 expectation, not a reasoned one. I think the best thing he can do is hold > his breath, wait until its finished and see how if the results are readable, > after running `fsck` on the mounted filesystem. > 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? > > 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. > > > Stroller, you mean your rescue.log showed no problematic entries? 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 + Thanks for inputs. -- Valmor > >
