GNU ddrescue: Clone a Failing Drive Before You Lose the Data (2026 Guide)

When a hard drive starts throwing read errors, every extra minute it spins is a minute closer to losing the data for good. GNU ddrescue exists for exactly this moment: it clones the dying drive to a healthy disk or an image file, copying the good data first and re-trying the bad spots afterward — so you can do all the risky recovery work on the clone instead of on the original.

This guide covers why ddrescue beats plain dd, the safe clone-first workflow, the exact commands (including the all-important mapfile), how to run it on Windows/macOS/Linux, and what to do once the clone is made.

The short answer

ddrescue clones a dying drive onto a healthy disk or image while gracefully working around read errors, and then you recover your files from the clone. You never run recovery tools directly on the failing original, because every read attempt on a damaged drive risks making it worse. ddrescue's job is to get a complete a copy as possible, as fast as possible, before the drive dies; the actual file recovery happens afterward on the safe clone.

ddrescue vs dd (why not just use dd)

Both tools copy raw bytes from one block device to another, but they behave very differently on a failing drive:

• dd reads in strict order and stops at the first error. When dd hits a bad sector it errors out (or, with conv=noerror, it keeps hammering sectors in sequence). Either way it spends time and head movement on the damaged zones early, stressing a drive that is already dying.
• ddrescue copies the healthy blocks first. Its first pass grabs everything readable quickly, then it comes back and re-tries only the error zones. So even if the drive dies partway through, you already have the bulk of your data.
• ddrescue uses a mapfile to track and resume. It records what has been copied and what still has errors, so you can stop, reboot, swap cables, and continue without re-reading the good parts.

On a dying disk, that ordering matters enormously. You want the good data off the platters before the drive fails — not after it has exhausted itself retrying a single unreadable region.

The safe workflow: clone first, recover later

The single most important rule with a failing drive is: clone it before you touch it with any recovery software.

1. Clone the failing drive to a healthy target (another disk or an image file) using ddrescue.
2. Set the original aside. Ideally never power it on again, especially if it shows mechanical symptoms.
3. Run recovery (testdisk/photorec) on the clone, never on the original.

Why this order? Recovery scans and partition rebuilds involve a lot of reading. Doing that on a drive that is physically failing accelerates the damage. The clone is a stable, healthy copy you can scan as aggressively as you like. If the original is making the rhythmic clicking sound of a failed head, cloning may not even be possible at home — but for a drive that still reads, ddrescue is the correct first move. For the broader picture of failure types and diagnosis, see our guide on hard drive failure: signs, diagnosis, and what to do.

ddrescue commands: fast pass, retries, and the mapfile

The standard procedure is two passes. The first grabs every good block quickly; the second re-tries the error zones. Both share the same mapfile, which is what makes the second pass efficient.

First pass — rescue the good blocks fast:

ddrescue -d /dev/sdX image.img map.log

• /dev/sdX is the failing source drive (replace sdX with your actual device).
• image.img is the destination image file on a healthy disk (or use a second device like /dev/sdY to clone disk-to-disk).
• map.log is the mapfile. Always specify it.
• -d uses direct disk access, bypassing the kernel cache for a truer read of the hardware.

Second pass — re-try the error zones (3 retries):

ddrescue -d -r3 /dev/sdX image.img map.log

• -r3 tells ddrescue to re-try bad areas up to 3 times.
• Because it reads the same mapfile, it skips everything already rescued and spends its effort only on the remaining bad regions.

The mapfile is the heart of the operation. It lets you resume after a stop, and it stops ddrescue from wasting time re-reading zones it has already secured. Never run ddrescue without one.

If you are imaging to a file, make sure the destination disk has more free space than the source is large, since the image is a full sector-by-sector copy.

Windows, macOS, Linux (and ddrescue-gui)

• Linux: ddrescue is native and packaged in most distributions (the package is typically gddrescue). The easiest reliable route for a failing internal drive is to boot a recovery live USB such as SystemRescue, which includes ddrescue, and run it from there so the failing drive is not your running system.
• macOS: install it with Homebrew (brew install ddrescue), then use it the same way against the device under /dev/.
• Windows: ddrescue does not run natively on Windows. The standard answer to "ddrescue windows" is to boot the machine from a Linux live USB (SystemRescue again is a common choice) and run ddrescue from that environment, cloning to a second healthy disk or to an image file on external storage.
• Prefer a GUI? ddrescue-gui is a graphical front-end for ddrescue that exposes the same source/destination/mapfile and retry options without the command line.

Whichever platform you use, the logic is identical: failing drive as source, healthy disk or image as destination, a mapfile to track progress.

After cloning: testdisk / photorec on the clone

Once ddrescue has produced your image or clone, mount it read-only and run file-recovery tools against it:

• testdisk rebuilds lost or corrupted partition tables and boot sectors, and can make a non-mounting volume mountable again.
• photorec ignores the file system entirely and "carves" files by their signatures (JPEG, DOCX, MP4, and many more) — useful when the file system is too damaged for testdisk to repair.

Run these against the clone or the mounted image, never against the original failing drive. To decide which of the two fits your situation, see our testdisk vs photorec guide.

When to stop and call a pro

ddrescue is powerful, but it has hard limits. Stop and consider a professional cleanroom lab if:

• The drive makes loud clicking or grinding noises.
• There is a burnt smell, or the drive does not spin up at all.
• You suspect a head crash (scraping sounds, drive detected then dropping out repeatedly).

These are signs of physical, mechanical failure. ddrescue maximizes what can be rescued from a drive that is still readable, but it does not repair a crashed head or a seized motor — and every additional power-on of a physically failing drive deepens the damage. Cloning can take hours or even days for a large, heavily-erroring drive; that patience pays off on a drive that still reads, but on one that is mechanically dead it only makes things worse. When in doubt, power down and get a free diagnostic from a certified lab.

Conclusion

GNU ddrescue is the right first tool for a drive that is still readable but throwing errors. Clone first with the fast pass, re-try the error zones with -r3, keep the mapfile so you can resume and skip the good areas, and then do all your recovery work on the clone with testdisk or photorec. Reserve the original for one job only: being the source of that clone. And if the drive is physically dying — clicking, grinding, not spinning — stop and let a cleanroom lab take over. The goal is always the same: get the data off before the window closes.