I am a bit confused about few things and I hope someone could clear this up for me. Is there any particular difference in disk to disk vs disk to image file approach?

I executed following code to recover my dying 2TB USB drive:

ddrescue --force --no-split /dev/sdc1 /dev/sdd1 ~/ddrescue.log

I thought it will make an image file on sdd1 (4TB USB), but instead it now seems to have full copy of entire filesystem, automatically mounted by Ubuntu. I now understand that I maybe should have done /dev/sdd1/image.img instead.

Do I understand correctly, that now, because I did disk to disk instead of disk to image, I do not need to do anything any more and I can safely start using data on new disk?

If so, what is the benefit of doing disk to image?. It seems to me that disk to disk is faster and easier because I now do not have to deal with extracting the image file. I understand the need of image file when one needs to split data to different smaller drives, but in case you have at least same size spare drive?

Extra question: I now seemingly have exact copy of broken drive automatically mounted and working. Because, I ran ddrescue only once without copying any error blocks there has to be some data, it could not recover (it can be free space?). How do I know which data was not recovered? Everything seems to be there.

1 Answer 1


The advantage of using disk to image is that it allows you do some surgery on the image later, without affecting an entire filesystem. This is why I always[1] rescue a drive to an image instead of a replacement drive.

As for going directly between sdc1 to sdd1, I've always been reluctant when it comes to copying directly from and to a partition, as opposed to the entire filesystem. What if the partition table on sdd does not match what's on sdc?

Identifying broken data is a tedious process. The log file should give you a clue as to what didn't transfer over[2]. In addition, there is the obvious method of checking individual files, in particular the large files, such as any video you might have, as they might start glitch when the keyframes go missing.

Note 1: By always, I mean provided that it's a rescue operation. If it's just a normal disk dump of a fully functioning system, I might do it disk to disk.

Note 2: It is worth mentioning that while the first pass to copy the sector is most likely the only result you're gonna get, ddrescue supports reading the logfile to see which sectors failed copy, and give those another go. Refer to the manpage for details. This helped me once when the limp part of the filesystem seemed to move around.

  • Thank you, that cleared most of it and yes I know about -r retry option, but because the whole process has taken way too long already and first run rescued most of it (1,7TB of 2), then I'm really not into running it again now. Saving those last 0.3tb is less important than time spent recovering it. Am I correct if I assume that I can try to recover some more later and per file basis?
    – ruuter
    Apr 13, 2015 at 19:55
  • 1
    You can try again, yes, but ddrescue doesn't care about individual files on the drive, only the drive itself, so what you need to do is mount the image as a loopback device, and try to access it normally. If that fails, it's time to use a tool that can try to find individual files on damaged filesystems.
    – Jarmund
    Apr 13, 2015 at 20:22

You must log in to answer this question.

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