[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help with ddrescue



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

Attachment: signature.asc
Description: Digital signature


Reply to: