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

5 Answers 5


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.

Note: ddrescue and dd_rescue are different programs.

  • 3
    So if I started initially with a log file and will run the same command again, it will automatically resume from last log position? /edit: it does start from the last position.
    – Qwerty
    Commented Dec 6, 2018 at 12:04
  • How about changing config, is it possible to change config and for example reduce number of retries and speed up process?
    – RMachnik
    Commented Jan 13, 2021 at 11:48

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
  • Is infile the disk being rescued, and outfile the rescue data?
    – Bastion
    Commented Jul 19, 2019 at 5:48

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 --input-position and --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 conv=noerror,sync switch, 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 198283000, not 198000283.

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

  • Hi GabrielB, welcome to Super User. I have edited your answer, but I'm not sure that it is enough to stand alone- perhaps you could further edit it to include a small section that addresses the original question too?
    – bertieb
    Commented Aug 22, 2015 at 0:22
  • If I remember correctly I wanted to comment Miles Wolbe's answer but couldn't as a new member, so I had to post a new answer. If it's possible, feel free to move the above post where it should appear and delete this one.
    – GabrielB
    Commented Oct 27, 2015 at 18:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .