Csdrhrt

As far as I can see, comparing dd with ddrescue can be concluded saying that ddrescue is far better at rescuing data from broken data sources. dd does not have this ability.

dd_rescue vs dcfldd vs dd

Sometimes I simply don't now if a data source is completely fine or if it is broken in some way before starting the backup.

So why not forget about dd and simply use ddrescue every time?

Isn't it like this: If the data source is fine ddrescue will do a fine backup and if the data source is broken ddrescue may be able to handle this.

The only reason I can see so far would be if dd is available and ddrescue is not, but I think in most cases when someone is doing a backup he can probably gain root access and simply install ddrescue.

Does ddrescue operate in any way slower than dd on fine data sources?

Quite simply? DD is a standard tool which you will predictably find in some shape or form in most unix or unix inspired OS. Its designed around being minimal and simple. That's its only advantage. There's no built in verification, there's no check summing, there's no fancy bits. However you can walk to any linux system and do an image. Its a hammer. Its a bit of steel on a stick, you know every workshop has one, and it bashes in nails fine. And at the very least it looks something like this, and any other hammer you find does at least what this does. ddrescue also should give you a bit-perfect copy you can verify with a checksum.

Gnu dd rescue is a specialised tool that happens to do the same thing the generic one does. You MIGHT be able to get out nails with a specialised tool, but not with your generic hammer. This is a claw hammer

It drives in nails and it takes them out. It gives you the best chance of recovering data but at the cost of possibly more time, and the optimisation being for maximum data recovery over perfectness. It also would do an image of a drive that's perfectly healthy.

I also personally favour the gnuddrescue syntax. Its simpler and more idiot proof in my opinion.

I'd add a PROPERLY done image with any of these tools would essentially be usable in the same way.

Most unix greybeards would say "Use the big bashy thing" - its the "right" way to do it. I prefer gnuddrescue since its just a more elegant tool for the end user, that happens to do more. That said, in some cases knowing how to use both can be useful, for example when dealing with a system where you can't install what you prefer.

ddrescue works well the basic case, where you want to clone between disks and on-disk images.

However, there are some cases where it simply won't work, or getting it to work requires a convoluted process of additional abstractions. This is usually because ddrescue requires a seekable source and destination. For example, this is significant when:

• You want to send a disk stream directly over the network. dd will happily let you pipe its input from or output to nc, ssh, etc.. ddrescue cannot do this. You'd need to provide a seekable remote filesystem, perhaps with SMB, NFS or SSHFS - but they all introduce additional overhead. (Arguably, you should use rsync instead - but sometimes the bit-exact image can be useful.)


• You want to compress the disk image. Maybe you don't have enough space for the full uncompressed image. With dd, you can easily pipe through gzip. With ddrescue, you'd need something like fusecompress.

Yes, it's still possible to get ddrescue to do those things, but when you're reasonably sure the source will not throw a read error then dd is easier and meshes well with other standard *nix tools.