Disk Image

Disk imaging is straightforward in concept: read every sector from the source storage device starting at LBA 0, write each sector’s contents to a destination file, and continue until the last LBA. The output is a complete bit-for-bit copy of the source drive. Unlike file copying (which works through the file system), imaging operates below the file system, capturing everything regardless of whether the OS recognizes the file system or not.¹

The defining property of disk imaging is completeness. An image captures everything that was on the source: file content, file system metadata, partition tables, boot sectors, deleted file remnants in unallocated space, and slack space within file system clusters. File-based copying captures only what the OS can see; imaging captures the substrate that the OS sees through. This is why imaging is the foundation of recovery: deleted files, damaged file systems, RAW partitions, all of these are visible in an image even when no normal tool can read them on the source drive.

The basic imaging process

Every imaging tool follows the same sequence:²

1. Identify the source device by its physical address on the system (Linux /dev/sda, Windows \\.\PhysicalDrive0, macOS /dev/disk2). Whole-disk imaging is the standard; partition-only imaging is also possible but less common in recovery scenarios because it misses the partition table.
2. Choose the destination. The destination must be on a different physical drive than the source (cannot image a drive to itself) and must have at least the source drive’s capacity. For compressed images, less space may be needed; for uncompressed raw images, the destination needs the full source size.
3. Read sectors in blocks. Imaging tools read in chunks (typically 64 KB to 4 MB) for performance, then write each chunk to the destination. The chunk size affects speed but not the resulting image’s contents.
4. Handle errors according to the tool’s policy. Plain dd stops on first read error. Bad-sector-tolerant tools like ddrescue mark the failed sector in a log and continue. The error-handling policy is the most important difference between imaging tools.
5. Verify the result. Hash the source and the image with MD5 or SHA-256; if they match, the image is bit-perfect. For damaged sources where some sectors couldn’t be read, the hashes won’t match exactly but the image still represents the best recovery possible.

Why imaging is sector-by-sector, not file-by-file

The OS works through the file system: applications request files; the file system translates file requests into sector requests; the drive returns the sectors. Imaging operates one level below this. An imaging tool asks the drive directly for sectors at specific LBAs, bypassing the file system entirely. This is what makes imaging work even when the file system is damaged; the imaging tool doesn’t need the file system to function. It’s also what lets imaging capture deleted files (still present in unallocated sectors), boot sector damage (in the first few sectors), and RAW partitions (where the file system is unrecognizable).³

Read-only operation

Imaging tools open the source device with read-only access; nothing the imaging process does writes to the source. This matters in two ways. First, the source drive’s contents can’t be accidentally modified during imaging. Second, on a failing drive, write operations are riskier than read operations; the read-only design eliminates the risk of imaging itself causing more damage. Once the image is created, all subsequent recovery work happens against the image; the source is set aside (or written to as a target for the recovered files).

The three terms get confused constantly, often by tools that use them interchangeably. The technical distinctions matter for choosing the right approach to your situation.⁴

When to image

Imaging is the right choice for:

• Data recovery scenarios. Imaging preserves the failure state for repeated analysis; multiple recovery attempts can run against the same image without consuming source-drive reads.
• Forensic investigation. Hash-verified images preserve evidence in a documented, repeatable form for legal use.
• System backup with full restore capability. Restoring an image gives you back the exact OS state, applications, and user data without reinstallation.
• Pre-modification snapshots. Creating an image before risky changes (firmware updates, OS upgrades, partition resizing) gives you a complete rollback option.
• Software deployment. One image of a configured system can be restored to many destination drives, ensuring identical setups.

When to clone

Cloning is the right choice for:

• Drive migration. Replacing an old drive with a new one; clone the old to the new and the new is immediately ready to use.
• Drive upgrade. Moving from a smaller drive to a larger one, especially when the goal is “boot from the new drive immediately.”
• Pre-flight before a risky operation, when you want a working spare drive rather than an archive file.

When to back up files

File backup is the right choice for:

• Routine ongoing protection of personal documents, photos, and other user files.
• Cloud sync scenarios where the backup is automatically replicated offsite.
• Selective backup of only the files that matter, ignoring OS and applications.
• Sharing specific files with others without giving them access to the entire system.

For data recovery specifically, file backup is generally insufficient because it doesn’t capture the failure state. If a drive fails after the most recent file backup, anything modified since the backup is lost. A disk image (or full system backup that captures the disk image at intervals) provides better recovery coverage.

The file format choice affects size, performance, compatibility, and forensic admissibility. The major formats divide into raw (uncompressed) and forensic (with metadata, hashes, and often compression).⁵

Raw / dd format

The simplest and most portable. Created by Unix’s dd command and read by virtually every recovery and forensic tool. One byte in the source becomes one byte in the image; no compression, no metadata, no headers. A 4 TB drive produces a 4 TB image file. The advantage is universal compatibility: any tool that can read raw bytes can process the image. The disadvantage is storage cost; multi-terabyte images consume considerable space.⁶

EnCase Evidence Format (E01)

The forensic standard format, originated by Guidance Software’s EnCase. E01 files are compressed (typically 30-70% size reduction), include metadata (case info, examiner name, capture date), and embed MD5 and/or SHA-1 hashes for integrity verification. Multi-segment support splits large images into multiple files (E01, E02, E03, etc.) for media size limits or transport convenience. Most forensic tools and many recovery tools read E01 natively.

Advanced Forensic Format (AFF)

An open-standard alternative to E01 developed by Simson Garfinkel. AFF files include metadata, optional encryption, and arbitrary key-value attributes for case-specific information. Less commonly used than E01 in practice but supported by major forensic suites. AFF version 4 is the modern standard.

VMDK / VHD / VDI for virtualization

Disk image formats designed for virtual machines. The advantage is mountability: you can attach the image to a VMware, Hyper-V, or VirtualBox virtual machine and boot it as if it were a real drive. Useful for examining a damaged drive’s contents in a sandboxed environment, or for running an exact copy of a damaged system to debug what’s wrong. Most virtualization formats can be converted to raw or vice versa with tools like qemu-img.

ISO and DMG

ISO 9660 is the standard image format for optical media (CD, DVD, Blu-ray). DMG is Apple’s disk image format used for macOS software distribution. Both are sector-by-sector copies of their respective media, with format-specific structure. Less commonly used for HDD/SSD recovery but standard in their respective contexts.

Imaging tools span from $0 command-line utilities to $10,000+ hardware imagers. The right choice depends on the source drive’s condition, the use case, and budget.⁷

Free consumer-grade tools

• GNU ddrescue (Linux / Mac, GPL). The gold standard for bad-sector-tolerant imaging. Mapfile-driven retry logic, multiple-pass workflow, and read-only operation. Command-line only but the de facto recovery industry standard.
• HDD Raw Copy Tool (Windows, free). HDDGURU’s GUI alternative to ddrescue. Sector-by-sector imaging with optional compression (.imgc format), checksumming, and a familiar Windows interface. Good for users who want imaging without the command line.
• dd (Unix, public domain). The original imaging tool, available on every Unix-like system. Fast and simple, but stops on first read error; not suitable for failing drives. Useful for healthy drives where speed matters and bad sectors aren’t a concern.
• Clonezilla (Linux, GPL). Disk and partition imaging in a bootable Linux environment. Compresses output by default; supports many file system formats. Convenient when imaging a system that can’t run other tools while booted.
• Win32 Disk Imager (Windows, free). Simple GUI for raw imaging on Windows; popular for SD card and USB drive imaging.

Free forensic tools

• FTK Imager (Windows / Linux, free from Exterro). Forensic-focused imaging with E01 output, hashing, and chain-of-custody documentation. Free download but registration required. Industry-standard for forensic acquisition.
• OSFClone (free, multi-platform). Bootable forensic imaging environment with hash verification; convenient for evidence acquisition without modifying the source system.
• Guymager (Linux, GPL). Open-source forensic imager with E01 output, multi-threaded compression, and a clean GUI. Common in Linux-based forensic distributions.

Commercial tools

• Macrium Reflect (Windows, paid + free). Backup-oriented imaging with strong scheduling and incremental support; popular for system backup with optional restoration to dissimilar hardware.
• R-Drive Image (Windows, paid). Imaging with broad file system support and strong incremental imaging.
• Acronis Cyber Backup (paid). Enterprise-class backup with imaging as one of its capabilities; popular in business environments.
• EnCase ($3,000+). The dominant forensic suite; imaging is one of many capabilities. Standard in law enforcement and legal contexts.

Lab-grade hardware imagers

• PC-3000 (~$3,000-$30,000). Hardware imager that talks to drive firmware directly, bypassing the standard ATA command set. Used by virtually every professional recovery lab. Handles drives that consumer tools can’t because of firmware-level corruption.
• DeepSpar Disk Imager (DDI Utility) ($3,500-$8,000). Hardware imager focused on bad-sector-tolerant imaging at firmware level; complementary to PC-3000 in many labs.
• Atola Insight (~$8,000-$25,000). Newer hardware imager with strong forensic features; growing share in professional labs.

Choosing the right tool for your scenario

• Healthy drive, bulk transfer: dd or Clonezilla. Fast and simple.
• Drive with bad sectors or failing hardware: ddrescue is the standard. HDD Raw Copy Tool for Windows users who prefer GUI.
• Forensic acquisition with chain of custody: FTK Imager (free) or EnCase (commercial).
• System backup for restore: Macrium Reflect or R-Drive Image; backup-oriented features matter here.
• Drive that doesn’t respond to standard ATA commands: Lab-grade hardware imager required. Send to a recovery lab.
• SD card or USB stick imaging: ddrescue, Win32 Disk Imager, or HDD Raw Copy Tool. All work fine for typical scenarios.

GNU ddrescue is the most-used tool in the recovery toolchain because of its specific design for failing drives. The workflow has nuances that distinguish it from generic imaging.⁸

The mapfile is the unsung hero

The mapfile (older versions called it the logfile) tracks ddrescue’s progress through the source drive. It records which sectors have been read successfully, which failed, and which haven’t been tried yet. The mapfile is what allows ddrescue to do something no other imaging tool does: resume an interrupted imaging session from the exact stopping point, retry only the failed sectors with different parameters, and run multiple passes that progressively get more aggressive on the difficult sectors.

Without a mapfile, ddrescue must restart from LBA 0 on every run; with a mapfile, every run picks up exactly where the previous one left off. Always pass a mapfile path to ddrescue; never run it without one, even on what you expect to be a quick imaging job.

The standard 3-pass recovery workflow

The recommended approach for any drive with bad sectors uses three progressive passes, each more aggressive than the last:⁹

The first pass uses -r0 (no retries) so failed sectors are skipped quickly. This captures 95-99% of the readable data without stressing the drive on hard sectors. The second pass with -r3 retries each failed sector up to three times; the -A flag tells ddrescue to also retry the trimmed (partially-failed) sectors. The third pass with -R reads in reverse direction; some drive failures are direction-sensitive, and reversing can unstick stubborn sectors.

Real ddrescue output

What a successful ddrescue run looks like, condensed from a real 4 TB drive recovery:

This output represents 99.99% successful recovery: 4000 GB rescued, only 1024 bytes (two 512-byte sectors) unrecoverable, 14 hours and 25 minutes of total runtime. The “non-trimmed” and “non-scraped” fields show that ddrescue’s later passes attempted the failed sectors thoroughly. For most consumer recovery scenarios, ddrescue results look similar: nearly complete recovery with a few sectors lost, completed overnight or over a weekend.

Hash verification

After imaging completes, verify the integrity:

If the hashes match, the image is bit-perfect. If they don’t match (which they generally won’t for failing drives), the difference reflects the unrecovered sectors. The mapfile’s bad-sector report shows exactly which sectors failed and why; the hash comparison confirms only those sectors differ. For drives sent to lab-grade recovery, the lab will hash the source on arrival and the recovered image at completion to document chain of custody.

👥 Researched & Reviewed By

Marcus Whitfield

Data Recovery Software Analyst & Senior Writer

All Articles X (Twitter)

Marcus has evaluated data recovery tools for more than six years across Windows, macOS, and Linux, from free utilities to enterprise-grade platforms. He writes the technical reference content on Data Recovery Fix, with particular focus on the imaging tools that form the foundation of every serious recovery workflow and on testing how consumer-grade tools compare to professional-grade alternatives.

B.Sc. Computer Science 6+ years data recovery evaluation ddrescue / FTK Imager

Rachel Dawson

Technical Approver · Data Recovery Engineer

All Articles X (Twitter)

Rachel brings over twelve years of cleanroom data recovery experience, with hands-on imaging across the full range of failure scenarios. Her work spans daily ddrescue and HDD Raw Copy Tool use for typical bad-sector cases, PC-3000 firmware-level imaging for drives that consumer tools can’t read, and forensic E01 acquisition for legal cases that require chain-of-custody documentation.

12+ years data recovery engineering PC-3000 certified Forensic imaging