Skip to main contentSkip to navigation
Rossmann Repair Group logo - data recovery and MacBook repair

HDDSuperClone vs ddrescue

Louis Rossmann
Written by
Louis Rossmann
Founder & Chief Technician
Published March 19, 2026
Updated March 19, 2026

GNU ddrescue and HDDSuperClone are the two most-recommended open-source tools for imaging a failing hard drive. Both create a sector-by-sector binary clone of a source disk. Both can pause, resume, and work around bad sectors. The difference is architectural: ddrescue reads through the Linux kernel's block device layer, while HDDSuperClone sends raw ATA commands directly to the drive controller via pass-through. That distinction determines which tool can handle a specific failure mode and which one will make it worse.

This guide covers when ddrescue is the right choice, when HDDSuperClone's ATA pass-through is required, and when both tools are inadequate and the drive needs professional hardware like the PC-3000 or DeepSpar Disk Imager.

Disk Imaging Is Not Data Recovery

A common error in DIY recovery attempts is running file-recovery software (Recuva, EaseUS, Disk Drill) directly on a failing drive. These programs issue random, non-sequential read requests across the entire disk surface. On a drive with unstable heads or degrading media, that access pattern accelerates mechanical failure.

Disk imaging is the first phase of any recovery: reading sectors sequentially from LBA 0 to the last sector and writing them to a healthy destination. File-system parsing happens on the cloned image, not on the original drive. ddrescue and HDDSuperClone are imaging tools. They output a raw binary image or a cloned disk. They do not output readable files.

GNU ddrescue: Kernel Block Device Imaging

GNU ddrescue is a GNU Project tool that reads from the standard Linux block device interface (/dev/sdX). It issues POSIX read() calls, and the kernel handles the actual SCSI/ATA command translation via the host bus adapter driver.

ddrescue's strength is its multi-pass algorithm. As of version 1.30 (January 2026), five phases handle progressively harder sectors:

  1. Copying: Reads large contiguous blocks. On error, skips a large region and continues forward, extracting all the easy-to-read data first.
  2. Trimming: Revisits skipped regions and narrows down the exact boundaries of each bad sector cluster by reading inward from both edges.
  3. Sweeping: A forward pass with skipping disabled to delimit large error areas and produce good starting points for the scraping phase.
  4. Scraping: Reads the remaining unresolved sectors one at a time.
  5. Retrying: Multiple passes over confirmed bad sectors, relying on the probability that the head aligns correctly on a retry to recover marginal sectors.

The mapfile (formerly logfile) records the state of every sector range as non-tried, finished, non-trimmed, non-scraped, or bad-sector. If the process is interrupted by a crash or a drive dropping offline, ddrescue resumes from the mapfile without re-reading finished sectors.

Where ddrescue works well

Drives with stable, functioning read/write heads but scattered bad sectors from media degradation. The heads can still read the majority of the platter surface; the bad sectors are localized defects in the magnetic coating. ddrescue extracts the good data first, then methodically narrows down the bad regions.

Where ddrescue fails

When a physical read/write head is weak or intermittently failing, ddrescue has no mechanism to detect which head is responsible. The Linux kernel treats the drive as a single block device. If a bad head hangs the drive controller, the kernel waits for its I/O timeout (30+ seconds by default) before returning an error. During that wait, the failing head is forced to keep attempting reads, accelerating its degradation. ddrescue cannot issue a hardware reset or skip the failing head's sectors because it does not know physical heads exist.

HDDSuperClone: ATA Pass-Through Imaging

HDDSuperClone, originally developed by Scott Dwyer, uses SCSI/ATA pass-through to bypass the Linux kernel's block device layer and send raw ATA commands (such as READ SECTORS EXT) directly to the drive controller. This gives the software access to the drive's hardware error registers rather than the generic “read failed” response the kernel returns.

Head-skipping algorithm

A hard drive maps logical block addresses (LBAs) to physical platters and heads. HDDSuperClone tracks which LBA ranges correspond to which physical head. When a head produces repeated read errors, the algorithm calculates the LBA offset of that head's zone and skips the entire zone. It clones all data from the healthy heads first, then returns to the failing head for a careful, throttled extraction. This approach is similar to how professional hardware like the PC-3000 handles head instability at the firmware level.

DMA vs PIO mode selection

Standard data transfer uses DMA (Direct Memory Access), where the drive controller writes data directly to system memory at full interface speed. On a degrading drive, DMA timeouts can crash the controller, requiring a full power cycle. HDDSuperClone allows switching to PIO (Programmed Input/Output) mode, where the host CPU polls the drive for each data word. PIO is slower but eliminates DMA timeout crashes, reducing stress on a mechanically unstable drive.

Virtual disk mode

HDDSuperClone can present the imaging session as a virtual block device to the host operating system. File-recovery software (DMDE, R-Studio) can then target specific structures like the Master File Table. If the requested sectors have already been cloned, HDDSuperClone serves them from the image file. If not, it reads them from the source drive and caches them. This prevents any sector from being read twice, allowing targeted file recovery without completing a full-disk clone.

Side-by-Side Comparison

FeatureGNU ddrescueHDDSuperClone
Interface layerLinux kernel block device (/dev/sdX)ATA/SCSI pass-through (bypasses kernel)
Head awarenessNone; sees only logical blocksMaps LBAs to physical heads; skips failing heads
Timeout controlDepends on kernel I/O timeout (~30s default)Custom hardware timeouts; can issue soft/hard resets
DMA/PIO switchingNot availableUser-selectable; PIO for degraded drives
Progress trackingMapfile (text-based, sector status log)Domain log with head-zone mapping
Media compatibilityAny block device (HDD, USB, CD, floppy)Hard drives only (ATA command set)
Virtual disk modeNot availableYes; presents imaging session as virtual block device
Best use caseStable heads, scattered bad sectorsWeak/failing heads, DMA timeout issues

Why Windows Is the Wrong Operating System for Disk Imaging

Windows aggressively attempts to mount, index, and parse every connected storage device. When a failing hard drive is connected via USB or SATA, Windows will issue random read requests across the disk surface for file-system indexing, thumbnail generation, and drive health checks. These non-sequential reads stress the failing heads in the same way file-recovery software does.

Both ddrescue and HDDSuperClone run on Linux, which can be configured to avoid auto-mounting. For drive imaging, the source drive should never be mounted. Linux distributions booted from a USB stick (such as Ubuntu or SystemRescue) provide a controlled environment where the imaging tool is the only process accessing the drive.

When Both Tools Fail: The Physical Failure Boundary

Stop and power the drive off if you observe any of the following symptoms.

Running ddrescue, HDDSuperClone, or any imaging software on a physically failing drive will cause permanent, unrecoverable data loss.

  • Clicking or clacking: The heads cannot find the servo tracks on the platter surface. They swing outward, fail to lock onto a track, and retract to the crash stop. Each cycle risks contact between the head slider and the platter.
  • Beeping: Hard drives contain no speakers. Beeping is the acoustic resonance of the spindle motor stalling because the heads are stuck to the platter surface (stiction) or the motor bearing has seized.
  • Head crash debris: If a head has contacted the platter, microscopic debris contaminates the airflow channel. Software imaging drives the surviving heads through this debris field, causing cascading head failures.
  • Firmware corruption: If the drive's Service Area is damaged, the drive may report 0 bytes capacity, show a factory alias (e.g., “WDC ROM MODEL-HAWK”), or fail to spin up entirely. Software imaging tools cannot access or repair the Service Area.

What professional tools do differently

When a drive crosses this physical failure boundary, recovery requires opening the drive in a 0.02µm ULPA-filtered clean bench for head swaps, or connecting via the PC-3000's diagnostic terminal for firmware repair. The PC-3000 can disable a crashed head at the firmware level before the drive motor spins, then image the surviving platters using the Data Extractor utility. That firmware-level head control is the capability that separates professional hardware from any software imaging tool.

If your drive exhibits any of the symptoms listed above, mail-in recovery is the next step. We charge no fee if the data is unrecoverable.

Choosing the Right Approach

If the drive spins up, is recognized by the BIOS, and produces no abnormal sounds, start with GNU ddrescue. It is simpler to configure, media-agnostic, and handles scattered bad sectors efficiently. Use a Linux live USB, connect the source drive via SATA (not USB, which adds a bridge controller that masks ATA errors), and image to a destination drive at least as large as the source.

If ddrescue stalls repeatedly on the same regions, or the drive intermittently drops offline, the likely cause is a weak read/write head. Switch to HDDSuperClone and enable its head-skipping algorithm. If the drive is connected via direct SATA and still hangs during DMA transfers, enable PIO mode.

If the drive clicks, beeps, grinds, shows 0 bytes in BIOS, or fails to spin, stop. No software will help. The drive needs physical intervention in a professional lab.

Frequently Asked Questions

Can I use HDDSuperClone on a failing SSD?

No. HDDSuperClone sends ATA commands designed for spinning hard drives with physical read/write heads. SSDs use NAND flash memory with no moving parts and a completely different command set. For SSD failures, the recovery path depends on the controller and encryption architecture, not disk imaging software.

My hard drive is clicking. Should I run ddrescue or HDDSuperClone?

Neither. Clicking means the read/write heads cannot locate the servo tracks and are slamming against the crash stop on each attempt. Running any imaging software on a clicking drive forces those damaged heads across the platters, scraping off the magnetic coating that holds the data. Power the drive off immediately. Recovery requires opening the drive in a particle-controlled environment, swapping the heads with matched donors, and imaging with a PC-3000 or DeepSpar Disk Imager.

What is the difference between DMA and PIO mode in HDDSuperClone?

DMA (Direct Memory Access) lets the drive controller transfer data directly to system memory at full speed. If the controller hangs on a bad sector, the DMA engine can lock up, requiring a power cycle. PIO (Programmed Input/Output) makes the host CPU poll the drive for each data word. PIO is slower but eliminates DMA timeout crashes, making it a safer mode for drives with intermittent controller hangs.

Does ddrescue or HDDSuperClone recover my files?

No. Both tools are disk imagers. They create a raw, sector-by-sector binary copy of the physical drive onto a healthy destination. The output is a .img file or a cloned disk containing the raw data. To see files, you run file system recovery software (DMDE, R-Studio, UFS Explorer) against the cloned image. Imaging and file recovery are two separate steps.

If you are experiencing this issue, learn about our hard drive recovery service.