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 you. 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. syntax: dd_rescue [options] infile outfile so: 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))