Every other article in this pillar assumes the drive is healthy. Burn-in testing catches problems before a drive ever holds data, and SMART monitoring catches the warning signs during normal service life. This one is about the moment after that, when a drive is already failing and you need to get the data off it, now, with as little further damage as possible.

The single biggest mistake people make here is treating a dying drive like a normal one. They try to copy files off it, or run chkdsk, or re-run a SMART self-test “to see how bad it is.” Every one of those actions reads from a drive that’s already struggling to read reliably, and every extra read is a chance to turn a partially failing drive into a completely dead one. The right first move is almost always the opposite of instinct: stop touching the drive directly, and image it instead.

Why you image first, not copy files

A normal file copy reads data in whatever order the filesystem driver and the application decide to read it, and it has no concept of “this sector is bad, skip it and come back later.” The moment a copy operation hits a bad sector, behavior ranges from a long stall while the drive retries internally, to an outright I/O error that aborts the whole copy, to (on a drive with a failing head or degrading platter) genuinely making the physical problem worse by continuing to seek across a damaged area.

Imaging is different. A disk-imaging tool reads the drive sector by sector (or in larger blocks) from front to back, writes everything it successfully reads into an image file, and keeps a separate log of exactly which sectors failed. It doesn’t care what filesystem is on the drive, doesn’t try to interpret any of it, and critically, it can be stopped and resumed without starting over. Once you have a complete (or as complete as possible) image sitting on a healthy drive, you do all your actual recovery work, filesystem repair, file extraction, the works, against that image. The failing drive itself gets touched exactly once, in the gentlest read pattern available, and then it’s done.

This is the same principle forensic recovery shops have used for decades, just without the cleanroom and the price tag. For a $50-200 problem (an external drive with photos nobody backed up) versus a lost dataset, the time cost of imaging first is close to zero.

ddrescue, and why it’s not the same tool as dd

dd is the tool everyone’s heard of for byte-level copying, and it’s the wrong tool for a failing drive. dd reads in fixed-size blocks, and if a read fails partway through a block, its default behavior is either to abort or to skip the entire block, losing every sector in it, not just the bad one. It also has no retry logic and no resume capability. If your source drive is actively struggling, dd is a blunt instrument for a job that needs precision.

ddrescue (GNU ddrescue, not the similarly-named dd_rescue) was built specifically for this scenario. It reads in large blocks as long as reads are succeeding, which is fast on the healthy majority of a failing drive, then automatically narrows down to smaller and smaller block sizes around any area that throws an error, isolating exactly which sectors are bad instead of writing off a whole region around them. It maintains a separate mapfile that records the state of every block on the drive (finished, bad-sector, not-yet-tried), which means the entire operation is resumable: pull the power cord, reboot, come back a week later, point it at the same mapfile, and it picks up exactly where it left off without re-reading anything it already has.

A basic run looks like this, imaging a failing drive at /dev/sdX to an image file on a separate healthy drive with plenty of free space:

ddrescue -d -r3 /dev/sdX /mnt/healthy-drive/failing-drive.img /mnt/healthy-drive/failing-drive.mapfile

-d tells it to bypass the kernel’s block-device cache and access the drive more directly, which matters for getting more consistent behavior out of a drive that’s already unreliable. -r3 sets it to retry a bad sector up to three times before giving up on it and moving on, a reasonable middle ground between thoroughness and not hammering a dying drive with endless retries. The image file and the mapfile both need to live on a different drive with enough free space to hold a full image of the source, not on the failing drive itself and not on your working/boot drive if space is tight.

The two-pass strategy that actually works

Running ddrescue once straight through, letting it retry every bad sector as it encounters them, is the naive approach and usually not the best one. The better pattern is two distinct passes:

Pass one: grab everything easy, fast, with minimal retries. Run with a low retry count (or -r0, meaning don’t retry at all yet) and let it blast through every sector that reads cleanly on the first attempt. This pass typically recovers 95-99% of a failing drive in a fraction of the time a full run would take, because most of a “failing” drive is still perfectly readable, it’s usually a specific damaged region, not the whole surface.

Pass two: go back and work the bad areas specifically. Once the easy data is safely imaged, re-run ddrescue against the same image and mapfile with a higher retry count and let it spend its time exclusively on the sectors the first pass marked bad. This is where you want to budget real time, because this is the part that’s genuinely hard on a failing drive and the part where additional attempts have diminishing (and sometimes negative) returns.

The reason this two-stage approach matters: every minute a struggling drive spends being hammered with retries on bad sectors is a minute of additional mechanical stress on a component that’s already failing. Getting the 95% that’s easy, safely, before you spend any time stressing the drive further on the hard 5%, means that even if the drive dies completely partway through pass two, you’ve already secured the vast majority of the data.

What to do before you even start

A few decisions made in the first few minutes after you notice a drive is failing matter more than almost anything in the actual imaging process:

  • Power it down the moment you suspect a problem, don’t keep trying things on the live drive. Every additional boot, every filesystem check, every “let me just see if this one file still opens” is a read you didn’t need to take.
  • Listen to it, briefly, before you decide your next move. A drive making a repetitive clicking or grinding noise is a different problem than a drive that’s just throwing occasional read errors in software. Mechanical noise is a sign of a head or platter problem, and in that case, every additional spin-up risks more physical damage; the honest answer there is that a professional data recovery service with a cleanroom is the right call, not another ddrescue attempt, if the data is worth real money to you. A drive that’s silent but throwing SMART errors or I/O errors in dmesg is a much better candidate for DIY imaging.
  • Never image onto the same drive, and never image onto your only other copy of anything important. The destination needs enough free space for a full image of the source drive’s total capacity, not its used capacity, since you want to preserve filesystem structure as-is for the repair step.
  • If the drive is spinning up and down repeatedly or disconnecting from USB, power is probably the problem, not the drive. A USB enclosure without its own adequate power, or a laptop port that can’t sustain a spinning 3.5" drive’s startup current, produces symptoms that look exactly like drive failure. Try a powered dock or a direct SATA connection before concluding the drive itself is dying.

After the image: repairing the filesystem

An image file with some bad sectors in it is not, by itself, a usable filesystem. The mapfile tells you which regions are damaged, and depending on what landed in those regions, you might have a perfectly mountable filesystem with a handful of corrupted files, or a filesystem structure that needs repair before anything mounts at all.

For most Linux filesystems, running the filesystem’s own repair tool against the image (not the original drive) is the next step, fsck for ext4, btrfs check for Btrfs, and so on. For NTFS or exFAT drives recovered from Windows systems, mounting the image read-only first and seeing what’s accessible before running any repair tool is worth doing, since a repair tool that doesn’t fully understand a damaged filesystem can occasionally make an already-marginal structure worse. Keep the original image and mapfile untouched and make a working copy before running any repair tool against it, so a bad repair attempt doesn’t cost you the one clean copy you have.

If the filesystem itself won’t mount even after repair attempts, file-carving tools (PhotoRec being the common free option) can pull recognizable file types directly out of the raw image based on file signatures, without needing an intact filesystem structure at all. It loses original filenames and folder structure, but for the specific case of “I need these photos back, I don’t care what they’re named,” it’s often the last resort that actually works.

Bottom line

The failure mode to avoid isn’t a bad drive, drives fail, that’s the premise of this entire content pillar. The failure mode to avoid is making a partially recoverable drive fully unrecoverable by treating it like a healthy one during the panic of realizing it’s dying. Stop reading from the drive directly the moment you notice a problem, image it with ddrescue onto separate healthy storage using the two-pass approach, and do every bit of actual recovery work against that image instead of the original. The drive gets touched once, as gently as the tooling allows, and everything downstream of that happens somewhere the clock isn’t running against you anymore.