When a hard drive starts to struggle, the instinct is nearly always the same: run another scan, copy the important files in a hurry, or install recovery software. Each of those actions puts load on a device nobody knows how many more reads it can survive. Data recovery labs do the opposite. They first freeze the state of the drive in a faithful copy, then work only on that copy. Here is why this step changes everything, how it is done, and where the limits of software cloning lie.
File copy or sector-by-sector clone: two different operations
Copying files means asking the operating system to list what it can see and read each file in turn. The result depends entirely on the file system: if the table describing the folder tree is damaged, or if a single sector of a file cannot be read, the copy stops or skips the file. It also leaves out recoverable deleted files, unallocated space and the internal structures (partition tables, metadata) that recovery tools actually need.
A sector-by-sector clone ignores all of that. It reads the device block after block, without trying to interpret the content, and reproduces every sector identically on another drive (a clone) or in a file (an image). Recovery tools can then work on that reproduction exactly as they would on the original, including the parts the operating system can no longer make sense of.
| Criterion | File copy | Sector-by-sector clone or image |
|---|---|---|
| What is read | Files the file system can still list | Every readable sector, without interpretation |
| Deleted files and unallocated space | No | Yes |
| Structures (partitions, metadata) | No | Yes |
| Behavior on an unreadable sector | File error or interrupted copy | The sector is flagged and the copy goes on (tool dependent) |
| What it is used for | Browsing the copied files directly | Analysis and recovery on the copy |
A note on terms: a clone is written to a destination drive, an image to a file. A raw image takes the full size of the source drive, while some forensic formats such as E01 can compress it. Either way the principle is the same: a complete read, with no filter.
Why you should never work on the original of a failing drive
On a healthy drive, reading a file a hundred times changes nothing. On a drive with a fault, every read is a risk. A typical recovery program sweeps the whole surface, often in several passes, and keeps coming back to the same fragile areas. A drive whose head struggles or whose surface is degrading can slip from “slow but readable” to “not responding” in the middle of a scan, with no warning.
The logic is simple. A direct scan that fails halfway leaves a more damaged drive and a single attempt used up. A clone, even an interrupted one, leaves a partial copy of what was read, and the work can continue from it.
There is a second danger, often underestimated: unintended writes. Plugging a drive into a computer can trigger write operations (file system journal, indexing, automatic repair prompts). Running a repair tool such as chkdsk or fsck on a drive that returns I/O errors modifies the very structures recovery depends on. The GNU ddrescue documentation puts it bluntly: never try to repair a file system on a drive with I/O errors, because you will probably lose even more data.
Finally, a clone gives you room for error. If a first attempt at rebuilding a partition fails or returns inconsistent results, you start again from the copy with nothing damaged. Warning signs that should trigger this reflex include clicking or scraping noises (see our article on recovering data from a dead hard drive), a drive that disappears intermittently, extreme slowness, or worsening SMART counters. Among the SMART attributes that Backblaze, a large storage operator, monitors to anticipate failures are reallocated sectors (attribute 5), current pending sectors (197) and uncorrectable sectors (198): as soon as one of them is above zero, there is reason to investigate.
What software tools can do
Three tools come up most often, each with its own scope.
- dd: the historic Unix block copy tool. With the
conv=noerroroption it continues after a read error, but it reads linearly, has no strategy for defective areas and keeps no record of what was or was not read. With large blocks, a single error can cost the whole block. - Clonezilla: a cloning and backup suite that boots from a USB stick. It is aimed mainly at duplicating and migrating disks. Its error-tolerant mode (the “rescue” option) is not enabled by default.
- GNU ddrescue: the free-software reference for damaged media. Despite the name, it is not related to dd by design.
Several principles set ddrescue apart, all described in its official manual. It keeps a log file (the “mapfile”) recording the state of every area, so a rescue can be interrupted and resumed exactly where it stopped, and only the blocks still needed are read again. It copies the healthy areas first and postpones the difficult ones, working through five phases (copying, trimming, sweeping, scraping, retrying). Recent versions also minimize head movement, which is an extra source of wear on a fragile drive. It does not write zeros in place of unreadable sectors, and running it again on the same destination fills the gaps without erasing what has already been rescued.
A few safety rules apply to any software cloning. The destination must be a different drive from the source and at least as large, because its content will be overwritten. Device names (for example /dev/sdb) can change between reboots, so check the model and serial number before starting. The source must not be mounted read-write during the copy. And a destination containing partitions must not be opened by an operating system that offers to “repair” them.
The limits of software cloning on a physically failing drive
- The kernel keeps control of errors. When a drive stops responding, the operating system decides how long to wait. The ddrescue manual itself admits that a bad drive can block the tool for a long time, until the kernel gives up.
- No control over the hardware. Software cannot choose which read head to use, cut the power to restart a drive that has frozen, or finely limit current and timeouts.
- Nothing to clone if nothing is readable. A drive that is not detected, whose motor does not spin up or whose heads are damaged returns no data to the software. The fault has to be dealt with on the hardware side, in a lab, before cloning is even on the table.
- Retries have a cost. Insisting on an unreadable area with a mechanically damaged drive speeds up degradation. The more physical the fault, the worse repeated reading becomes.
In short, software cloning suits light faults, such as isolated bad sectors on a drive whose mechanics still work. As soon as there are abnormal noises, unstable detection or a drive that freezes, it is time to stop and change approach. On a hard drive with internal damage, the right decision is not to insist.
Hardware imagers: reading an unstable drive differently
Labs use dedicated equipment such as DeepSpar Disk Imager, Atola Insight or PC-3000 systems. A hardware imager talks to the drive directly and handles errors itself instead of leaving them to the operating system. According to Atola’s documentation, its imager offers multipass imaging of damaged drives, automated handling of drives that freeze, and selective head imaging, where each read head is treated according to its condition as established during diagnostics. That kind of tuning does not exist in software that goes through the operating system’s standard driver.
To protect the source, forensic practice uses a hardware write blocker, which physically prevents any write to the source, and computes a hash (SHA-256, for example) of both source and copy to show they are identical.
Special case: RAID arrays and NAS
For a RAID server, the rule is the same but the scale changes: each member disk must be cloned individually, with its original slot recorded, before any rebuild or assembly attempt. A rebuild on drives that are already fragile puts heavy load on each of them.
Good habits before any cloning
- Stop using the drive at the first signs of failure, and power it off if abnormal noises appear.
- Do not format, reinstall or run a file system repair tool on the affected drive.
- Avoid makeshift remedies. Putting a drive in the freezer, for instance, does not help, as our article on the freezer trick explains.
- Do not open the drive outside a cleanroom: the slightest dust on the platters makes things worse.
- Prepare a separate destination of sufficient capacity, and never install a recovery tool on the failing drive itself.
- If there are mechanical signs, hand the drive to a lab rather than piling up software attempts.
Cloning before recovering turns a situation where every mistake is final into one where you can try, correct and start again. Software suits light faults; as soon as the mechanics are involved, specialized equipment and lab work take over. If your drive shows signs of weakness, the safest course is to stop using it and ask for advice before doing anything else.