Sector-by-Sector Clone

A standard file copy operation works at the file system level: the operating system sees a list of files, you select some of them, and the OS copies their contents to a destination. Sector-by-sector cloning works one layer below: it copies every storage sector on the drive in order, regardless of what (if anything) the file system thinks is there.¹

What gets copied

A complete sector-by-sector clone preserves everything the source drive contains:

• All visible files in their exact on-disk locations.
• Deleted files still present in unallocated space until they’re overwritten.
• Slack space inside file allocations where old data lingers in unused parts of the last cluster of each file.
• File system metadata: the Master File Table, partition tables, boot sectors, and directory structures.
• The boot record itself, including bootloader code and partition table.
• Hidden partitions and recovery partitions that may not be visible through the OS.
• Bad sector regions with whatever content can be read from them.

The result is a copy that is functionally identical to the source. Mounting the clone or analyzing it with recovery software produces the same results as analyzing the source directly, except the source no longer has to be touched.

Sector-by-sector clone vs disk image

The terms overlap in usage. A disk image is the artifact: a file (or sometimes a destination drive) that contains the byte-for-byte copy. A sector-by-sector clone is the process of producing one, specifically using techniques that handle bad sectors and preserve every byte. Every recovery-grade disk image is the result of a sector-by-sector clone operation; the process is what produces the artifact. The two terms are often used interchangeably, but the distinction matters when you’re describing what to do versus what you have.

The image-once-recover-repeatedly principle

The technique exists because of a fundamental property of failing drives: every read accelerates the failure. The Technibble forum thread captures this directly: you should never read a single sector on a hard drive more than once.² Cloning forces a single, well-organized read pass that captures everything. After cloning completes, all subsequent recovery work happens against the clone, which is on a healthy destination drive. The failing source can be powered off and stored without further stress.

Most users have copied files between drives countless times. Why doesn’t ordinary copying work for recovery? Two reasons: standard tools don’t read what’s invisible to the file system, and they fail catastrophically when they hit a bad sector.³

File copy doesn’t see deleted data

When you copy a file in File Explorer or Finder, the operating system reads only the file’s allocated sectors as listed in the file system metadata. Deleted files that haven’t been overwritten still exist on disk but aren’t visible to file copy tools. The same applies to slack space, metadata regions, and any data outside the file system’s tracked allocations. For recovery purposes, those invisible regions often contain the data you need: deleted files, file-system journals showing recent activity, partition tables for partitions that have been removed.

Standard cloning tools abort on errors

Tools like Windows’ built-in disk-cloning utilities, basic cp commands, or even more sophisticated cloning tools like Macrium Reflect or Acronis True Image are designed for healthy drives. When they encounter an unreadable sector, they typically abort the entire operation rather than skipping the bad sector and continuing. A drive with even one bad sector in an inconvenient location can defeat these tools entirely.⁴

Standard tools don’t log failures

Even when standard tools do skip errors, they don’t usually log which sectors failed in a way that lets recovery resume from where it stopped. Recovery-grade tools maintain a mapfile that records every failed sector range. The mapfile is what makes multi-pass recovery possible, since each pass can target only the sectors that previous passes failed to read, without redoing already-completed work.⁵

The Windows-host-controller problem

Even when recovery-grade Windows tools exist, they share a fundamental limitation: the Windows host controller doesn’t allow software to control ATA commands directly. Read timeouts, retry counts, and similar low-level parameters are managed by the OS, not the application. For failing drives where you specifically want fast timeouts (so the drive doesn’t lock up retrying a bad sector for 30 seconds), this matters. Linux-based tools have direct hardware control and can configure these parameters, which is why ddrescue running on a Linux live USB outperforms most Windows-based recovery cloning even when the Windows tool is well-designed.

Comparison: standard copy vs recovery clone

Capability	File copy / standard cloner	Sector-by-sector clone (ddrescue)
Captures visible files	Yes	Yes
Captures deleted files in unallocated space	No	Yes
Captures slack space content	No	Yes
Continues past bad sectors	Usually no	Yes
Logs which sectors failed	No	Yes (mapfile)
Resumable across multiple sessions	No	Yes
Direct ATA command control	No (on Windows)	Yes (on Linux)
Configurable read timeouts	No	Yes

GNU ddrescue is the standard tool for software-based sector-by-sector cloning of failing drives. Its algorithm is sophisticated in ways that matter for recovery success.⁶

The five phases

ddrescue divides its work into distinct phases, each targeting a different stage of the recovery:

1. Copying phase: reads non-tried parts of the input in large blocks, marking blocks that fail as non-trimmed and skipping past them quickly. Up to five passes, with direction reversed after each pass to delimit large bad areas efficiently. The goal is capturing readable data before damage progresses.
2. Trimming phase: reads sector by sector at the edges of failed blocks to determine the precise boundaries between readable and unreadable regions. This shrinks the damaged areas in the mapfile and recovers data adjacent to bad sectors that the first pass skipped past.
3. Scraping phase: reads the remaining non-scraped blocks one sector at a time. Any sectors that still fail are marked as bad-sector. This recovers what’s possible from blocks the trimming phase couldn’t fully resolve.
4. Retrying phase: retries known bad sectors until either they succeed or the configured retry limit is reached. The direction reverses on each retry pass.
5. Final mapfile: after all phases complete, the mapfile shows exactly what was recovered, what failed, and the precise sector ranges of each.

The mapfile is the key

The mapfile (sometimes called the logfile) is what makes ddrescue uniquely effective for recovery. It’s a text file recording every sector range and its status: copied successfully, skipped, marked as bad, or not yet tried. The Data-Medics guide describes it precisely: it should arguably be renamed since it’s not really a log of activity but a sector-status database.⁷

The mapfile enables several capabilities that are otherwise impossible:

• Resume interrupted operations: if power fails or you stop ddrescue, the next run picks up exactly where the previous one stopped.
• Multiple recovery sessions: you can power off the drive, let it cool down for hours, and resume; ddrescue uses the mapfile to skip already-completed regions.
• Reverse-direction passes: the -R flag tells ddrescue to read backwards, which sometimes succeeds where forward reads fail because the drive’s controller approaches problem regions from a different angle.
• Retry only bad sectors: after an initial pass, you can rerun with --cpass to retry only the failed regions without redoing successful regions.

A typical first-pass command

A reasonable first-pass invocation for an unknown failing drive:

ddrescue -d -n -b 4096 /dev/sdX drive.img drive.mapfile

The flags are tuned for a fast first pass that captures readable data quickly:

• -d uses direct disk access, bypassing the OS cache for accurate reads.
• -n skips the trimming and scraping phases on the first run; the goal is rapid capture of readable data, with detailed work on bad regions deferred to a second pass.
• -b 4096 sets a 4K block size, matching modern Advanced Format drives.
• /dev/sdX is the source drive (replace X with the actual letter; verify with lsblk first).
• drive.img is the destination image file.
• drive.mapfile is the mapfile.

The retry-flag debate

Many tutorials recommend using -r3 (retry bad sectors three times) or even higher retry counts on the first pass. Datarecovery.com explicitly recommends against this: forcing a malfunctioning drive to read damaged areas without first having it diagnosed by a professional can cause further damage, including potential head-stack failure on HDDs.⁸ The conservative practice for unknown failure modes is: skip retries on the first pass, get the bulk of the readable data captured, then evaluate whether to retry bad sectors based on how much data was actually missed and how the drive is behaving. If the drive is making unusual sounds or its read-error rate is increasing, more retries can convert a partially-recoverable case into a fully-unrecoverable one.

ddrescue is the best free software-based sector-by-sector cloning tool, but it’s not the only or most powerful option. Professional recovery services use hardware imagers that can do things software running on a PC cannot.⁹

Software-only options

• GNU ddrescue: the free open-source standard, runs on Linux and macOS. Sophisticated multi-phase algorithm with mapfile support. Best free option for most cases.
• HDDSuperClone: commercial software that improves on ddrescue’s algorithm specifically for failing drives, with better handling of drives that disconnect during operation.
• Atola Insight Forensic (software mode): commercial forensic-grade software with advanced features for drives that don’t quite need full hardware imaging.
• R-Studio Drive Image: commercial software with sector-by-sector cloning built into a broader recovery toolkit.

Hardware imagers

For drives that are too damaged for software cloning, professional hardware imagers provide capabilities at a level above what software can achieve:

• PC-3000 (ACE Lab): the dominant professional recovery hardware, capable of imaging drives that disconnect repeatedly, drives with firmware corruption, and drives that don’t respond to standard ATA commands. Includes vendor-specific firmware repair tools.
• DeepSpar Disk Imager (DDI): hardware imager focused on recovery from drives with bad sectors and degraded firmware, with configurable per-sector timeouts and intelligent skip patterns.
• Atola Insight Forensic (hardware): hardware imager combining recovery and forensic capabilities, with hash verification and chain-of-custody logging for legal cases.

When hardware imagers are necessary

Hardware imagers cost in the high four to five figures and require specialized training. They’re justified when:

• The drive disconnects from the host repeatedly during cloning, making software-based recovery impossible.
• The drive has firmware corruption that prevents normal ATA communication.
• The drive’s internal heads are partially failing and need configurable read parameters to capture data before complete failure.
• Forensic chain-of-custody requirements demand hash verification and write-blocking that consumer hardware can’t reliably provide.
• The case involves an SSD with controller failure that needs the controller bypassed entirely (chip-off recovery starts with hardware imaging of the NAND chips).

Sector-by-sector cloning isn’t appropriate for every recovery scenario. Knowing when to clone and when to skip directly to recovery saves time on healthy drives and protects data on failing ones.

When cloning is essential

• Failing drives: any drive showing bad-sector counts, intermittent errors, unusual sounds, or rising SMART warnings should be cloned before recovery is attempted.
• Drives with critical data: if losing the data would be catastrophic, clone first regardless of the drive’s apparent health. The clone is cheap insurance against a recovery operation going wrong.
• Drives where multiple recovery approaches will be tried: if you’re going to run TestDisk, then PhotoRec, then a commercial recovery tool, working from a clone means each tool sees the same starting state.
• Drives in hybrid damage scenarios: physical damage producing logical symptoms benefits enormously from imaging first; the logical recovery happens against the image while the failing source is left alone.
• Drives heading to professional services: recovery labs prefer to receive a clone or to clone the drive themselves; avoid running recovery software directly on a drive you’re going to send for professional recovery.

When cloning isn’t necessary

• Healthy drives where you want to recover deleted files: if the drive is mechanically sound and SMART data is clean, running recovery software directly is acceptable and faster than cloning.
• Time-critical scenarios where the drive is healthy: recovery software can find and copy files in less time than cloning would take, when the drive’s health doesn’t add to the risk.
• Drives where the destination capacity isn’t available: cloning requires a destination at least as large as the source. Without that, work directly with the source if it’s healthy or escalate to professional services if it isn’t.

Sector size and destination compatibility

One subtle issue affects clones to physical destination drives: modern drives use different sector sizes that aren’t always interoperable. 512-byte native (512n) drives expose 512-byte sectors. 512-byte emulated (512e) drives have 4K physical sectors but emulate 512-byte sectors for compatibility. 4K native (4Kn) drives expose 4K sectors directly. Cloning a 512n source to a 4Kn destination produces an unbootable result because the partition table assumes the wrong geometry. Imaging to a file rather than another drive avoids this entirely; the image file holds whatever sector size the source had, and recovery tools work correctly against it.

Step-by-step workflow

1. Identify the failing drive’s device path with lsblk on Linux. Confirm the destination drive or file location.
2. Run a fast first pass with -n to capture readable data quickly without lingering on bad sectors.
3. Review the mapfile to see how much was captured and where the remaining bad regions are.
4. Decide on retry strategy based on how the drive is behaving. If the drive sounds healthy and only minor regions failed, run a retry pass. If the drive is making unusual sounds, stop and consult a professional.
5. Run additional passes if appropriate, including reverse-direction reads with -R for stubborn regions.
6. Verify the image by mounting it (read-only) or running file system checks against it before starting recovery work.
7. Power off the source drive and store it; all subsequent work happens against the image.