ddrescue vs dd: One of Them Stops at the First Bad Sector

Both copy a block device. On healthy hardware they do the same job and dd is fine.

On a drive that is failing, they behave so differently that the choice decides how much of your data survives.

What dd does at a bad sector

dd reads in order. When a read fails, it stops.

Told to continue with conv=noerror,sync, it does something worse for recovery purposes: it writes zeros in place of what it could not read, so the offsets stay aligned. The image is the right size and the damaged regions are silently filled with plausible-looking nothing.

Afterwards you cannot tell those zeros from real ones. The information about what failed existed for a moment, in the error output, and was never recorded anywhere the image could carry.

What ddrescue does instead

Three things, in an order that is the whole design:

1. Copy everything readable, fast, skipping trouble. No fighting bad regions on the first pass.
2. Write a map file recording exactly which regions succeeded, which failed, and which are untried.
3. Then go back and retry the failed regions with progressively smaller reads.

The map file is the most valuable artefact of the operation, more than the image itself in the early stages. It makes the job resumable: if the drive drops off the bus, you restart with the same map and it continues instead of re-reading everything from the start.

On a drive with limited life left, not re-reading the good parts is the difference between finishing and not finishing.

They survey before they dig, and they record where they have already been. That is the entire difference between the two tools, and the photograph cannot show the part that matters: the notebook. dd does the digging without the notebook.

The ordering is the point

It looks like a small optimisation and it is not.

A failing drive has a budget: a number of hours, or a number of read attempts, before it stops responding for good. Nobody knows the size of that budget in advance.

dd spends it in physical order, which means it may exhaust itself grinding on a bad region at 5 percent while 90 percent of your data, sitting further along the disk, is still readable and never gets copied.

ddrescue spends the budget on the easy data first. If the drive dies at the same moment, you have 90 percent instead of 5.

When dd is the right tool

Healthy media. Writing an installer image to a USB stick. Cloning a working disk. Wiping. Reading a fixed number of blocks from a known-good source. It is smaller, it is everywhere, and it does not need a map file for any of that.

The rule is about the state of the source, not about preference. Healthy source: either works. Suspect source: ddrescue, always.

What neither of them does

Neither recovers files. They produce a block-for-block copy. Getting files out of that image is a separate step with separate tools, and a filesystem repair on the image is another one again.

Neither tells you whether the drive is dying. You have to have decided that already, which is uncomfortable, because the decision has to be made before the tool can help.

This is what the argument is about. Not the drive, which is replaceable and insured, and not the tool. The reason to image before repairing is that the things on the disk usually exist in exactly one copy.

The order that protects you

1. Stop using the drive. Minutes cost data on failing hardware.
2. Image with ddrescue, to healthy storage, keeping the map file.
3. Work on the image. Repair, recover, analyse. Never on the original.
4. Retry the bad regions later if you need them, using the same map, on a second pass.

The whole method fits on that list. The hard part is not the commands, it is deciding early enough that this is the situation you are in, and that decision has to happen while the drive still answers.