Disk copies you can trust: imaging and verifying drives

Imaging a disk sounds like the simplest job in computing. Read every block from one place, write it somewhere else. In practice a disk image is only useful if you can prove it matches the source, and only safe if the tool cannot be pointed at the wrong drive. This post covers how we think about imaging and verifying drives: what kind of copy to make, how to handle a disk that is dying, how to check the result with SHA-256, and the small interface decisions that stop people from erasing the disk they meant to save.

Some of it is also the thinking behind dskcopy, our tool for macOS, Windows and Linux that writes disk images to drives and verifies them. dskcopy works in the other direction from most of this post: it takes an image file, such as an ISO, and writes it to a USB stick or SD card. It does not image drives or make backups. The parts about verifying with a hash and never writing to the wrong disk apply to both directions, and those are the parts we built it around.

Block copies and file copies are different things

There are two ways to copy a drive, and they answer different questions.

A file copy walks the filesystem and copies each file. You get what the operating system thinks is on the disk: files, folders and (if the tool is careful) permissions, timestamps and extended attributes. The copy lands in a fresh layout on the destination. Deleted files, free space and the filesystem's own bookkeeping are not copied, because they are not files.

A block copy reads the device from the first byte to the last and ignores the filesystem entirely. Partition tables, boot records, metadata, free space and deleted data that has not been overwritten all come along. The copy is the same size as the disk and, if all went well, identical to it byte for byte.

Use a file copy when you are moving your life to a new drive. Use a block copy when you need the disk exactly as it was: before a risky repair, for a machine you are about to reset, or when you are not sure yet what matters on it. If in doubt, take the block copy first. You can always pull files out of an image later. You cannot get deleted data back from a file copy.

Raw images and sparse images

A raw image is the simplest possible format: a file whose bytes are the disk's bytes. Every tool can read it, it mounts on any operating system, and its hash is directly comparable with a hash of the source device. The downside is size. A 2 TB drive with 200 GB on it still makes a 2 TB raw image.

A sparse image keeps the same logical layout but does not store blocks that are all zeros. Modern filesystems, including APFS, ext4 and NTFS, support sparse files, where long runs of zeros take no space on disk. GNU dd has conv=sparse for this, and ddrescue has a sparse option too. macOS also has its own .sparseimage and .sparsebundle formats through hdiutil, which are convenient on a Mac and awkward everywhere else.

Two cautions. Free space is only zeros if something wrote zeros there, so a used drive often shrinks less than you hope. And a sparse file can quietly become a full-size file when it is copied by a tool that does not understand holes, so check the size on the destination and not just the size in the listing.

Reading a failing drive

A drive that clicks, stalls or throws read errors is a different job. Every read may be one of its last, so the order of work matters more than the tool.

• Image first, repair later. Do not run First Aid, fsck or chkdsk on a failing disk. Repairs write to the disk and hammer the damaged areas. Repair the image instead.
• Copy the easy parts first. GNU ddrescue does a fast pass that skips anything slow, then comes back for the hard areas, and records progress in a map file so it can stop and resume.
• Accept holes. Blocks that never read come back as zeros in the image, and the map says exactly where they are. An image with three unreadable blocks and a log is far more useful than a drive you wore out trying to get them.

On Linux a typical first pass and retry look like this:

ddrescue -n /dev/sdX disk.img disk.map
ddrescue -r3 /dev/sdX disk.img disk.map

On a Mac, use the raw device path (/dev/rdisk4 rather than /dev/disk4), which skips the buffer cache and is usually much faster for large sequential reads. For health data, smartctl -a from smartmontools shows reallocated and pending sectors on most drives that report them.

Verifying with SHA-256

A copy you have not verified is a copy you hope is right. The check is a cryptographic hash: read the source, compute its SHA-256, read the image, compute its SHA-256, compare. If one bit differs anywhere, the hashes differ completely. SHA-256 is the sensible default in 2026. MD5 and SHA-1 still catch accidental corruption, but they are broken against deliberate tampering and there is no reason to start with them now.

sudo shasum -a 256 /dev/rdisk4
shasum -a 256 disk.img

On Linux the equivalent is sha256sum. Three details decide whether the comparison means anything:

• The source must not change between reads. A mounted volume changes all the time: Spotlight indexes it, the system writes logs, apps touch files. Unmount it first (diskutil unmountDisk /dev/disk4), or the hashes will never match and you will not know why.
• Hash while copying. Computing the hash on the same pass that reads the data saves a full read of the source. On a failing drive that second pass might be the one it does not survive.
• For damaged drives, hash the image and keep the map. The source cannot be re-read reliably, so its hash will not match. What you can prove is that the image has not changed since it was made, and which blocks were missing when it was.

Write the hash down next to the image, in a plain text file with the date and device details. Six months later it is the only way to know the file is still the file.

APFS and NTFS quirks

APFS adds a few surprises. A container holds several volumes that share free space, so "the disk" and "the volume" are different targets. Clones let two files share the same blocks, so a file copy to another disk can need more room than the source shows as used. Snapshots hold old versions of blocks you cannot see in Finder. And on modern Macs the system volume is sealed and the internal storage is encrypted in hardware, so a block image of an internal drive is not the portable object people expect. For Mac system disks, a volume-level tool such as Apple's asr, or a file copy of the data volume, is usually the honest answer.

NTFS has its own. macOS mounts NTFS volumes read-only by default, which is good for imaging. File copies from NTFS can lose alternate data streams and Windows permissions if the tool does not handle them. And Windows Fast Startup leaves a volume in a hibernated state rather than cleanly unmounted. Imaging it at block level is fine. Writing to it from another system is how people lose data.

Never writing to the wrong disk

Forensic teams use hardware write-blockers, small bridges that pass reads through and refuse writes at the connector. Most people do not own one, so the software has to behave like one. This is where most of the interface work goes, and it is the part we care about most in our desktop apps.

• Name disks by what they are. Show model, capacity, partition names and a serial number, not disk4. Device numbers change when you replug a drive, so a number alone is a trap.
• Treat the source as read-only by default. Unmount it or mount it with diskutil mount readOnly, and never offer the source as a destination in the same session.
• Refuse the boot disk as a target, and warn loudly about any disk that holds a mounted volume.
• Show what is on the destination before erasing it, and ask for the disk's name, not a yes.
• Check identity again right before writing. If the serial number at the moment of writing does not match the one the person picked, stop.

None of these steps is clever. Together they make the dangerous path slow and the safe path fast, which is the only kind of safety people keep using. If you work with evidence or sensitive disks, our notes on security tools cover the adjacent problems.

The last thing we do after any important image is boring: mount the image read-only, open a few files from it, and check the hash again a week later. It takes five minutes, and it is the step that turns a file on a disk into a backup.