I have to recover my 1TB USB HD. I'm using
ddrescue to accomplish this. Is there a way that I can resume
ddrescue once I start it?
I'm using the command:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
ddrescue can be resumed, but it requires a log file to be able to do so. The log file will record the progress that ddrescue has made so far, and restarting ddrescue will read the log file and start where it left off.
The log file would be the third parameter:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log
If you have already started a ddrescue run without a log file and cancel it, the next time ddrescue runs, it will start at the beginning since it has no record of what has already been recovered.
Even if you forgot to specify a logfile, there may be hope:
So you didn't read the tutorial and started ddrescue without a logfile. Now, two days later, your computer crashed and you can't know how much data ddrescue managed to save. And even worse, you can't resume the rescue; you have to restart it from the very beginning.
Or maybe you started copying a drive with
dd conv=noerror,sync and are now in the same situation described above. In this case, note that you can't use a copy made by dd unless it was invoked with the
sync conversion argument.
Don't despair (yet). Ddrescue can in some cases generate an approximate logfile, from the input file and the (partial) copy, that is almost as good as an exact logfile. It makes this by simply assuming that sectors containng all zeros were not rescued.
However, if the destination of the copy was a drive or a partition, (or an existing regular file and truncation was not requested), most probably you will need to restart ddrescue from the very beginning. (This time with a logfile, of course). The reason is that old data may be present in the drive that have not been overwritten yet, and may be thus non-tried but non-zero.
For example, if you first tried one of these commands:
ddrescue infile outfile
dd if=infile of=outfile conv=noerror,sync
you can generate an approximate logfile with this command:
ddrescue --generate-mode infile outfile logfile
As others have said, you should always specify a logfile as the third parameter, which will allow resuming. Since you didn't do that, that's not going to help you here. If you know approximately what point the process got to, you can use the
--output-position parameters to start from that point (make sure to set both those parameters to the same value, otherwise the output will be corrupted).
Since you did not specify a log file as third parameter, resuming cannot be done automatically . You could create a logfile by hand if you know the already rescued sectors, the syntax is easy. Just start another dummy rescue to another file while specifying a log and let it read different areas. Then edit the log to represent the already rescued areas in your first file. Now re-run your previous command but give the name of the log file as the third parameter. ddrescue will then resume on the first untried sector.
Per https://wiki.archlinux.org/index.php/Disk_cloning it seems
that with the
dddoes in fact add zeroes at the end of a block, not exactly where the read errors occurred. This is contrary to information in Miles Wolbe's answer from 2013-08-29.
For instance, if a correct sequence is
198123283 and there's a read error in the middle it will write
So in case there were actually read errors the proposed method won't be accurate- there will be areas which would have been readable which will end up filled with zeroes, yet will be considered "rescued".
By the way, it's a good practice to begin such a recovery attempt by filling the destination drive with zeroes (or at least the free space, which can be done with WinHex for example).