Re: Help with ddrescue
On Fri, 8 May 2015 14:41:24 -0600
Bob Proulx <bob@proulx.com> wrote:
> The Wanderer wrote:
> > Gary Dale wrote:
> > > I think Wanderer may be overstating the problem a little. If the
> > > two drives are exactly the same size, you can use ddrescue to
> > > duplicate the failed drive onto the new drive (ddrescue
> > > if=/dev/sdb of=/dev/sdc). However this will limit you to
> > > recovering in place on new drive.
> >
> > In my experience, single-pass recovery like this does not work very
> > reliably or very well; it also doesn't let you make the "backup
> > copy" you originally suggested, which is a good idea if you have
> > the space (though I never have had).
>
> I have never had *enough* disk space. Because I always need more!
>
> There is an idea that I didn't see proposed as I read through this
> thread. If one had three same sized drives then there is another
> possibility.
Problem I have now is the lack of money. I simply don't have money now
to buy yet another drive. I took out one drive from my another system,
bought usb external enclosure and thought I'll succeed. Hmm..
everything is just not as easy as it seems.
It isn't that unusual to have three drives of the same
> size. One could then make two copies of the data. Copy the data from
> the failing drive to a good same-sized drive. It would then be an
> identical copy. Then take the failing drive and put it on the shelf
> so as not to damage it further while trying to recover. Then make
> another identical copy onto the third drive. At that point one of the
> copies can be used for recovery experimentation and there would still
> be a copy available for backup on the other drive.
>
> Also when making the first backup copy using ddrescue use a third
> location for the ddrescue log file. I am assuming that a system has
> been booted up for the rescue and has the failing disk and the target
> disk attached. That means the host system has its own space available
> for the copy. Use it for the log file.
>
> ddrescue /dev/sdX /dev/sdY /var/tmp/rescuelogfile
>
> Where /dev/sdX is the failing source drive, /dev/sdY is the spare
> target drive, and /var/tmp/rescuelogfile is on the system hosting the
> recovery effort with its own drives. If I had a spare drive of the
> same size this would be what I would do to copy it.
>
> Then could do the same for the backup onto the working copy spare for
> recovery. Or just use a normal dd there since presumably both of the
> spares are good and error free.
>
> > It's technically possible, yes, but I wouldn't want to trust or
> > rely on it in any case where the source device is potentially prone
> > to failure - and in any scenario where it isn't, you're unlikely to
> > want to use one of the *rescue tools in the first place.
>
> My experience has been that once a drive starts to produce hard
> failures that it tends to become worse rather quickly. I would
> perform the backup of it. There is no way to avoid it. But I would
> try to avoid working the failing drive as much as possible until there
> is as much recovered as possible. After having recovered as much as
> is possible only then would I try any other work on the failing drive.
> Because Murphy's Law usually means that it becomes worse quickly. But
> after I had a good backup then trying other things such as other disk
> recovery software and so forth is reasonable. Why not if the drive
> has already failed otherwise? But again I would want a good backup
> first. And do any recovery work on a different working copy of it.
>
> > (There's also the consideration of finding space for the ddrescue
> > log file if you're restoring directly to the identical-size device;
> > that file that may not be as important in some scenarios, but I
> > wouldn't want to try to do such a rescue without one.)
>
> Agreed. The ddrescue log is critical. But a hosting system with both
> drives mounted could use /var/tmp/rescuelog for space not on either of
> the same-sized drives.
>
> > I certainly wouldn't say there are never times when direct
> > device-to-device recovery like that is appropriate, but I haven't
> > encountered one and I would not recommend it as a base-practices
> > procedure.
>
> Storage recovery is definitely a problem that takes skill to produce
> good results. It's a problem. There is no easy solution because the
> decisions we make along the way all depend upon the knowledge and the
> information available at that moment. It is really hard to document a
> canonical procedure. Sometimes it just helps to be lucky.
>
> Bob
Reply to: