Rule Zero of Data Recovery: Image the Drive First

Rule Zero of Data Recovery: Image the Drive First

Never work on the original media. That's rule zero of data recovery, and most people break it without realizing — they point a recovery tool straight at the failing drive. The first and only thing a failing drive should ever do again is surrender one sector-level image. Every recovery attempt after that happens on the copy.

Why every read is a risk

A drive that's failing is failing right now, while you use it. A mechanical disk with degrading heads or media scores its platters a little more with every rotation. Marginal sectors that read fine today may not read tomorrow. Flash media with a dying controller can drop dead mid-read and never enumerate again.

Whatever the failure mode, every read you spend is drawn from a budget of unknown size that only shrinks. Think of it like a prepaid card with no balance display — you don't know how much is left, so every swipe has to count.

Recovery tools are the worst way to spend that budget. A file-carving scan walks the drive slowly and repeatedly, hammering exactly the marginal regions a careful imager would defer. Run it directly on failing hardware and the tool meant to rescue the data finishes the drive off instead. The imaging pass reads each sector as few times as possible, in the smartest order possible — that's the whole reason it goes first.

ddrescue and the mapfile

GNU ddrescue is the standard tool for this job. The invocation is short:

ddrescue -n /dev/sdX drive.img drive.map      # fast pass: skip bad areas
ddrescue -r3 /dev/sdX drive.img drive.map     # retry pass: 3 attempts on the gaps

The strategy matters more than the syntax. The fast pass (-n) sweeps the whole drive and grabs everything that reads cleanly, skipping regions that error instead of grinding on them. On a mostly-healthy drive, this one gentle sweep recovers the vast majority of the data.

Only then does the retry pass (-r3) return to the recorded gaps and work the bad areas with bounded persistence. Easy data first, hard data last: by the time the drive is under stress, everything recoverable without stress is already safe.

The quiet hero is the mapfile. It records the state of every region — rescued, skipped, bad — and that buys two things that matter on real jobs:

• Resumable. Power cut, drive hung, USB bridge reset — rerun the same command with the same mapfile and ddrescue continues where it stopped. Nothing already saved gets re-read. Imaging a large dying drive over several sessions is normal, not a failure.
• Auditable. The mapfile is a precise account of what was recovered and what wasn't. "The image contains 99.7% of the device, with 12 MB unreadable, here are the ranges" is a claim you can hand to whoever owns the data — not a hope.

A complete image is not recovered files

An image finishing at 100% feels like victory. It is, for stage one. But a sector-perfect copy of a corrupted filesystem is still a corrupted filesystem. The partition table may be gone, the file table damaged, files fragmented across the disk in ways metadata no longer describes.

All of that work is still ahead: repairing filesystem structures, or carving files out of raw sectors when the structures are beyond repair. Carving has hard limits worth understanding before promising anyone their files back — I cover those in what PhotoRec can and cannot recover from NTFS.

The point of rule zero: stage two is now safe. Filesystem repair tools can be aggressive. Carving scans can run for days.

A failed approach can be retried with a different tool. None of it touches the original again. Keep the pristine image untouched and work on a copy of the copy — storage is cheap, second chances at a dying drive are not.

The practical checklist

• Storage math: the image is the size of the device, not the data — a 4 TB drive that's "mostly empty" still yields a 4 TB image. Have destination space for the image plus a working copy before starting.
• Mount nothing. The failing drive must never be mounted read-write. Even an automount "just to look" writes journal replays and access metadata. A hardware write-blocker is the professional answer; disabling automount and strict read-only discipline is the minimum acceptable one.
• Work from the image for every subsequent step, and keep the mapfile with it — the unreadable ranges tell you which later gaps are hardware losses rather than tool failures.

When to stop and send it to a lab

Software imaging has a boundary, and crossing it destroys data. A drive that's clicking, buzzing, or spinning up and down has a mechanical problem — heads or motor — and continuing to power it grinds debris into the platters. A drive that was dropped, flooded, or burned belongs in a cleanroom, not on a USB dock.

When ddrescue's recovery rate collapses to bytes per second with the error count climbing, the drive is telling you its budget is spent. A lab with head-swap and platter-handling capability can often continue where software can't — but only if the drive arrives no more damaged than it already is. The honest rule: the more the data matters, the earlier the handoff.

The takeaway

Image first, with ddrescue and a mapfile: fast pass, then bounded retries. Treat the original as evidence: read-only, powered as briefly as possible, never the target of a recovery tool.

Budget storage for the full device size. Expect filesystem work after the image completes. Hand physically failing drives to a lab before software makes them worse. Every recovery that ends well starts the same way — with the original safely out of the loop.