On 2017-02-28 22:31, Stevens wrote:
On 02/28/2017 03:20 PM, Wols Lists wrote:
> On 28/02/17 20:59, Stevens wrote:
>> On 02/28/2017 02:37 PM, Felix Miata wrote:
>>> Any reason not to use dd_rescue instead of
dd in the first place?
>> My being totally unfamiliar with dd_rescue probably enters into it.
> As far as I am aware, basic ddrescue syntax is identical to dd.
> HOWEVER. If you have problems with dd it will leave you up a gum tree.
> Especially if copying something like a disk drive.
> The classic problem with dd aiui, is that if it fails to read, lets say,
> sector 10 on your old drive, it simply skips that when writing to the
> new drive, so the old sector 11 becomes the new sector 10. Cue
> everything after your failed read being scrambled. That's why the
> default is to abort after a failed read!
> Just use ddrescue as if it were dd, and (a) your chances of a successful
> copy are a lot higher - it has loads of tricks for dealing with dodgy
> reads, and (b) the copy you end up with will be as perfect as possible -
> holes where there were failed reads etc.
> It will also give you a log of any failed reads if you ask it, so you
> can (if your fu is good enough) work out what files have been damaged.
> Hopefully, on the raid list we will soon have a script that will take
> that log and force soft read failures on the new drive where there was a
> hard failure on the old one. That will cause any attempt to read a
> corrupt file to bomb.
Wol - Greg said that the sync option puts zeros where
there was a bad
sector. Is that not the same as what you are saying about dd_rescue's
action? I mean, it would seem to maintain the sector count. I do not
know, I have not used either.
That's because dd_rescue uses dd to do the actual job :-)
I concur on recommending dd_rescue for this job, for several reasons. It
is really easy to use (more than dd). And it brings several advantages.
You can do the same that dd_rescue does, by calling dd several times
with the appropriate options. dd_rescue simply automates the process for
If it finds an error, it initially skips it, with the goal of copying as
most as possible of the source. Later, it tries to narrow on the error
zone trying to copy as most as it can.
If there are no errors, then if finishes and you are done. If there are
errors, you let it run for a sensible time and abort it when tired of
waiting: it will have copied all that was possible. It will display the
percent, anyway. In theory, leaving enough time it should finish.
Another advantage is that you can abort the process and restart it later
from the point it left.
Another similar tool is gnu-ddrescue (program ddrescue). This tool was
developed later after seeing the success of dd_rescue (I think). It does
the same thing with slightly different syntax. I have not made up my
mind to which is best. Let's use dd_rescue.
dd_rescue [options] infile outfile
dd_rescue /dev/sdb /home/you/backups/firstone.img
As with dd, be very careful about what destination you tell it to use.
Tell it to write to a disk, and it will overwrite it, not caring or
warning if it contains data, even if it is the system disk.
Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" (Minas Tirith))