David Greaves wrote:
Bill Davidsen wrote:
Leon Woestenberg wrote:
We will try to make disk clones first. Will dd suffice or do I need
something more fancy that maybe copes with source drive read errors in
a better fashion?
Yes to both. dd will be fine in most cases, and I suggest using noerror
to continue after errors, and oflag=direct just for performance. You
could use ddrescue, it supposedly copes better with errors, although I
don't know details.
Hi Bill
IIRC dd will continue to operate on error but just retries a set number of times
and continues to the next sector.
As I read the O.P. that's fine in this case, two drives believed just
fine, one showing okay in SMART, all should copy with dd. The last drive
is probably not recoverable, and if the other three are recovered RAID5
will recover in any case without it.
ddrescue does clever things like jumping a few sectors when it hits an error,
then, after it has retrieved as much data off the disk as possible it starts to
bisect the error area.
This type of algorithm is good because disks often die after a few minutes of
being powered and deteriorate rapidly as data is recovered - hammering them on
retries on an error on sector 312, 313, 314.... when you have millions of
(currently) readable sectors elsewhere is a bad idea because it can minimise the
time you have left to read your data. It's also very fast, provides continuous updates to the screen as to where it is and the io rates it is currently seeing and those it's averaging, it also writes
a log of what it's done to local file to allow restarts.
etc etc etcc..
try it - IMHO it's the right tool for the (data-recovery) job :)
I won't recommend a tool I haven't tried, and in this case I don't think
is going to be needed. I mentioned it existed, that's as far as I want
to go. I wouldn't suggest someone else use a tool I haven't used (or
written) myself.
If you've used it and found it worked on a drive with actual bad spots,
you offered your information which is appropriate.
--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
