dd Command (Linux/Mac)

The OneUptime dd reference provides the foundational definition: “dd (data duplicator, though commonly misnamed ‘disk destroyer’ as a reminder to be careful) copies data at the block level. It reads from a source, optionally transforms the data, and writes to a destination. Unlike filesystem-aware tools, dd doesn’t know or care about files; it copies raw bytes. This makes it useful for disk cloning, image creation, partition backup, and secure erasure, but it also means a mistake with the if= and of= parameters can destroy data.”¹

The 1974 Unix V5 origin

dd has been part of Unix since the earliest editions, predating most modern Unix conventions:

• 1974 (Unix V5): dd introduced as part of the base Unix utilities; the syntax derived from IBM Job Control Language.
• 1980s BSD Unix: dd adapted for Berkeley Unix; remained part of the base utility set.
• 1991 (Linux 0.01): dd inherited from Unix tradition; became part of GNU coreutils.
• 2001 (Mac OS X): macOS adopted BSD’s dd as part of its Unix subsystem.
• 2004: GNU ddrescue released as a separate dedicated recovery tool addressing dd’s limitations on damaged drives.
• Present: dd remains universal across Linux, macOS, FreeBSD, OpenBSD, NetBSD, Solaris, AIX, with consistent syntax.

The IBM JCL syntax origin

dd’s distinctive syntax is the most-noticed feature for first-time users:

• Standard Unix tools: use command -f flag value or command --flag=value conventions.
• dd: uses command parameter=value parameter=value with no leading dashes.
• Why JCL: the original Unix authors borrowed the syntax from IBM’s Job Control Language where DD statements (Data Definition) declared input/output files for batch jobs.
• Result: “if” means “input file” (not the if conditional); “of” means “output file”; “bs” means “block size”.
• Modern compatibility: the unusual syntax has persisted because changing it would break decades of scripts and documentation.

The “disk destroyer” reputation

dd’s reputation as a dangerous tool reflects practical experience:

• Reversing if= and of= writes the destination over the source (fatal).
• Typing /dev/sda when you meant /dev/sdb wipes the wrong drive.
• No confirmation prompts; dd executes immediately when entered.
• No undo; the operation completes faster than realization of the mistake.
• Same syntax for safe imaging and total destruction; only the parameters differ.
• The Cyberciti dd reference cites a real user complaint: a user intended to image a Windows drive but reversed parameters and corrupted the destination filesystem instead.

Why Unix systems treat devices as files

dd’s effectiveness on storage devices reflects a fundamental Unix design principle: everything is a file. The Open Tech Guides dd reference describes it: “Unix like systems treat all devices as files and these device files are located in the /dev directory in your system. So typically your hard disk drive is a file in the /dev directory with the prefix of hd or sd. This concept of device as files makes dd a perfect candidate for backup and restore of disk images or cloning some partitions or the entire disk.”² Practical implications:

• /dev/sda is a Linux block device file representing the first SATA disk.
• /dev/disk0 is the macOS equivalent for the first physical disk.
• Reading from these files retrieves disk content; writing to them modifies disk content.
• The same I/O primitives that handle regular files handle disk devices.
• Tools like dd that work with files automatically work with disk devices without modification.

Cross-platform availability

dd is universally available on Unix-like systems with consistent core syntax:

Platform	Package	Device naming	Progress reporting
Linux (most distros)	GNU coreutils	/dev/sda, /dev/nvme0n1	status=progress
macOS	BSD base	/dev/disk0, /dev/rdisk0	kill -USR1 PID
FreeBSD	Base system	/dev/ada0, /dev/da0	status=progress (recent)
OpenBSD	Base system	/dev/sd0, /dev/wd0	kill -INFO PID
Solaris	Base system	/dev/dsk/c0t0d0	External progress only
AIX	Base system	/dev/hdisk0	External progress only
Windows (via WSL/Cygwin)	Coreutils port	Mapped paths	status=progress

dd’s parameter set has accumulated over decades and reflects both its IBM JCL heritage and its many use cases. Understanding the parameters is essential for both safe operation and effective recovery work.

The fundamental syntax

The basic dd syntax pattern is straightforward despite the unusual notation: dd if=source of=destination [bs=blocksize] [count=N] [skip=N] [seek=N] [conv=options] [iflag=flags] [oflag=flags] [status=mode]. All parameters are optional except if= (defaults to stdin) and of= (defaults to stdout).

Input and output parameters

The two primary parameters specify the data flow:

• if= (input file): the source; can be a regular file, a block device (/dev/sda), or a special device (/dev/zero, /dev/urandom, /dev/random).
• of= (output file): the destination; can be a file path or a block device.
• Default values: if= defaults to stdin; of= defaults to stdout; this enables piping with other commands.
• Path conventions: Linux uses /dev/sda, /dev/sdb; macOS uses /dev/disk0, /dev/disk1; FreeBSD uses /dev/ada0, /dev/da0.
• The reversal disaster: swapping if= and of= writes destination over source; the most common dd mistake.

Block size parameters

Block size significantly affects throughput and is one of the most-tuned parameters:

• bs= (block size): sets both input and output block size; common values bs=4M, bs=64K, bs=512.
• ibs= (input block size): input only; allows asymmetric configurations.
• obs= (output block size): output only; useful when input and output have different optimal sizes.
• cbs= (conversion block size): for conv= operations like ASCII-to-EBCDIC.
• Default: 512 bytes; far too small for modern drives.
• Performance impact: bs=512 may achieve 30 MB/s; bs=4M may achieve 200+ MB/s on the same drive.
• Common recommendations: bs=4M for HDDs, bs=64M for high-throughput SSDs, bs=64K for older systems with limited memory.

Count, skip, and seek parameters

These parameters enable partial copying and offset operations:

• count= (number of blocks): limits the number of blocks copied; useful for partial imaging or testing.
• skip= (input offset in blocks): skips N blocks at the start of the input.
• seek= (output offset in blocks): seeks to N blocks before writing output.
• Practical examples: dd if=/dev/sda of=mbr.img bs=512 count=1 copies only the first sector (MBR backup); dd if=/dev/sda of=part.img bs=512 skip=2048 count=2097152 copies a 1 GB partition starting at sector 2048.

The conv= options

conv= specifies data transformations applied during the copy:

• noerror: continue on read errors instead of stopping (essential for damaged drives).
• sync: pad input blocks with zeros up to ibs= when reads return short or fail (maintains alignment).
• fsync: flush output buffers to disk before exiting (prevents loss on power interruption).
• notrunc: don’t truncate the output file when starting (preserves existing content beyond the write).
• swab: swap byte pairs (legacy use for endian conversion).
• ucase / lcase: uppercase or lowercase the output (text data only).
• Combined usage: conv=noerror,sync is the standard combination for damaged drives.

Flag and status parameters

Modern GNU dd added several quality-of-life parameters:

• status=progress: displays live progress (bytes transferred, elapsed time, transfer rate) on Linux GNU dd; not available on BSD/macOS.
• status=none: suppresses all output except errors.
• status=noxfer: shows final summary but no transfer statistics.
• iflag= / oflag=: per-input or per-output flags like fullblock (read complete blocks even when source returns partial), direct (bypass cache), sync (synchronize after each write).
• BSD/macOS progress: send SIGUSR1 via kill -USR1 PID to display progress.

Block size syntax conventions

Block size values support multiple notations:

• bs=N (plain bytes): exact byte count.
• bs=Nb: N × 512 bytes.
• bs=Nk or bs=NK: N × 1024 bytes.
• bs=NM: N × 1048576 bytes (binary mebibyte).
• bs=NMB: N × 1000000 bytes (decimal megabyte).
• bs=NG: N × 1073741824 bytes (binary gibibyte).
• Common usage: bs=4M for 4 mebibytes; this is the practical de facto standard.

dd’s flexibility supports a wide range of disk operations. The following patterns are the most-used in practice.

Creating a disk image

The most common dd use case is creating a sector-level disk image. The standard pattern:

• Identify source: lsblk on Linux, diskutil list on macOS.
• Unmount source: sudo umount /dev/sda1 on Linux, diskutil unmountDisk /dev/disk0 on macOS.
• Standard image creation: sudo dd if=/dev/sda of=/backup/disk.img bs=4M status=progress conv=fsync
• Compressed image: sudo dd if=/dev/sda bs=4M status=progress | gzip > /backup/disk.img.gz
• Compressed network transfer: sudo dd if=/dev/sda bs=4M | gzip | ssh user@host 'cat > /backup/disk.img.gz'
• Split for size limits: sudo dd if=/dev/sda bs=4M | gzip | split -b 4G - /backup/disk.img.gz. creates files limited to 4 GB.

Restoring a disk image

Restoration reverses the imaging process:

• Standard restore: sudo dd if=/backup/disk.img of=/dev/sda bs=4M status=progress conv=fsync
• Restore from compressed: gunzip -c /backup/disk.img.gz | sudo dd of=/dev/sda bs=4M status=progress conv=fsync
• Restore from split: cat /backup/disk.img.gz.* | gunzip -c | sudo dd of=/dev/sda bs=4M status=progress
• Network restore: ssh user@host 'cat /backup/disk.img' | sudo dd of=/dev/sda bs=4M status=progress
• Destination size check: the destination must be at least as large as the source; smaller destinations cause truncation and data loss.

Drive cloning

Direct cloning skips the intermediate image file. The ArchWiki dd reference describes the basic pattern: “From physical disk /dev/sda to physical disk /dev/sdb: dd if=/dev/sda of=/dev/sdb bs=64M status=progress. This will clone the entire drive, including the partition table, boot loader, all partitions, UUIDs, and data.”³ Important properties:

• Both partition tables, file systems, and content are duplicated exactly.
• UUIDs are duplicated; this can cause confusion if both drives are connected to the same system.
• Boot loaders are copied; the cloned drive is bootable on compatible hardware.
• Encrypted volumes are cloned in their encrypted state; decryption keys are needed separately.
• Cloning to a smaller drive will fail or truncate; destination must be at least as large as source.
• Cloning to a larger drive leaves unallocated space that can be reclaimed via partition resize.

Bootable USB creation

Writing ISO images to USB drives is one of dd’s most-common consumer uses:

• Linux ISO: sudo dd if=/path/to/ubuntu.iso of=/dev/sdX bs=4M status=progress oflag=sync
• macOS image: sudo dd if=/path/to/image.iso of=/dev/rdiskX bs=4M
• The oflag=sync parameter: ensures writes are synchronized; reduces corruption risk if USB is removed prematurely.
• Identify drive: always verify USB drive identity via lsblk or diskutil list before writing; selecting the wrong drive destroys data.
• Modern alternatives: Etcher, Rufus (Windows), Ventoy provide GUI-based USB writing with safety checks.

Wiping drives

dd can perform basic drive wiping using special device files as input:

• Zero wipe: sudo dd if=/dev/zero of=/dev/sda bs=4M status=progress writes zeros across the entire drive.
• Random data wipe: sudo dd if=/dev/urandom of=/dev/sda bs=4M status=progress writes pseudo-random data.
• Cryptographic random: sudo dd if=/dev/random of=/dev/sda uses kernel entropy (very slow).
• Multi-pass wipe: repeat zero and urandom passes for paranoid sanitization (single-pass is sufficient for modern drives).
• Comparison with Secure Erase: firmware-level Secure Erase is faster and more thorough on SSDs because it includes wear-leveling areas.

MBR backup and restore

dd can target very specific portions of disks using bs=512 count=1:

• MBR backup: sudo dd if=/dev/sda of=mbr-backup.img bs=512 count=1 saves the first 512 bytes (boot loader + partition table).
• MBR restore: sudo dd if=mbr-backup.img of=/dev/sda bs=512 count=1 restores from backup.
• Partition table only: sudo dd if=/dev/sda of=ptable.img bs=1 count=64 skip=446 copies just the 64-byte partition table without the boot code.
• GPT backup: requires copying the GPT header (LBA 1) and the partition entries (LBA 2-33); use sgdisk for proper GPT backup instead of dd.

Forensic-quality imaging with dcfldd

For forensic contexts where chain of custody matters, dcfldd is a dd-derived tool with hash verification built in:

• Hash during imaging: dcfldd if=/dev/sda of=/path/disk.img hash=sha256 hashlog=/path/file.hash computes hash on the fly.
• Validate against original: dcfldd if=/dev/sda vf=/path/disk.img verifies image matches source.
• Status interval: dcfldd provides progress reporting via statusinterval=N parameter.
• Use cases: digital forensics, e-discovery, evidence preservation where hash verification is required.

The relationship between dd and ddrescue is the most-confused aspect of Unix recovery tooling. Understanding the differences is essential for choosing the right tool for any given recovery scenario.

The fundamental dd limitation on damaged drives

The Apple Discussions ddrescue thread captures the canonical recommendation: “I’d guess that you’re much more likely to have success with either GNU ddrescue or dd_rescue (different things), or with one of the commercial disk-recovery products, any of which is designed for the task, while dd is not.”⁴ The specific issues with dd on damaged drives:

• dd reads sequentially from the start to the end of the source.
• When dd encounters a bad sector, default behavior is to abort; conv=noerror is required to continue.
• With conv=noerror, dd skips bad sectors but doesn’t track which were bad.
• dd has no resume capability; an interrupted dd run must restart from the beginning.
• dd hammers bad sectors immediately, potentially accelerating drive failure during recovery.
• dd cannot benefit from temporary improvement in damaged drive behavior; it never retries.

How ddrescue addresses these limitations

The Medium ddrescue reference describes the architectural advantage: “ddrescue manages efficiently the status of the rescue in progress and tries to rescue the good parts first, scheduling reads inside bad (or slow) areas for later. This maximizes the amount of data that can be finally recovered from a failing drive.”⁵ Key ddrescue features:

• The mapfile (logfile): tracks which sectors have been successfully read, which failed, and which haven’t been attempted yet.
• Multi-pass strategy: Pass 1 (Copying): reads good areas in large blocks; Pass 2 (Trimming): reads sector-by-sector at the edges of bad areas; Pass 3 (Scraping): reads each bad sector individually; Pass 4 (Retrying): re-reads bad sectors with configurable retry count.
• Resume capability: if interrupted, ddrescue resumes from the mapfile state; no work is lost.
• Reverse passes: alternates direction between passes for better damage area handling.
• Cooldown periods: can be configured to give failing drives thermal recovery time.
• Output is identical: the resulting image is byte-equivalent to dd’s output for non-damaged drives.

Three different rescue tools

Three Unix tools have similar names but very different capabilities:

Tool	Origin	Capabilities	Recovery use
dd	Unix V5 (1974)	Basic byte copy	Healthy drives only
dd_rescue	Kurt Garloff (1999)	Better error handling than dd	Light damage
GNU ddrescue	Antonio Diaz Diaz (2004)	Mapfile, multi-pass, resume	Severe damage
dcfldd	Forensic fork (2002)	Hash verification, forensic features	Chain-of-custody work

When to use which

Choosing the right tool depends on the drive condition and use case:

• dd: healthy drive imaging, drive cloning, ISO writing, secure wipe, partition table backup.
• dd with conv=noerror,sync: minor read errors but mostly healthy drive.
• GNU ddrescue: any drive showing SMART errors, bad sectors, mechanical issues, BSOD/kernel panic on access.
• dcfldd: forensic imaging where hash verification and chain of custody are required.
• Specialized hardware imagers (PC-3000, HDDSuperClone, DeepSpar Disk Imager): severely damaged drives where firmware-level intervention is needed.

macOS-specific recovery considerations

macOS adds several quirks for dd and ddrescue use. The Der Flounder ddrescue reference describes a critical macOS optimization: “instead of /dev/disk{x} you may use /dev/rdisk{x} – This will give a massive performance boost (in my testing transfer rate went from 30 MB to 130 MB).”⁶ macOS-specific patterns:

• diskutil unmountDisk /dev/disk0: required before dd operations; otherwise “device not configured” or “resource busy” errors.
• Use /dev/rdiskN not /dev/diskN: raw device 4x throughput improvement.
• APFS containers: diskutil list shows synthesized container volumes; the underlying physical disk is the correct dd target.
• SIP (System Integrity Protection): may block dd operations on the boot disk; recovery from external boot environment required.
• Time Machine snapshots: different from dd imaging; complementary rather than replacement.
• FileVault encrypted volumes: dd captures encrypted state; decryption requires the FileVault password or recovery key.

dd’s role in data recovery is foundational: nearly every Unix-based recovery workflow starts with creating a sector-level image of the affected drive. Understanding the recovery workflows clarifies how dd fits into the broader recovery toolchain.

The image-first recovery principle

The fundamental rule throughout the recovery community: image the drive first, then perform recovery operations on the image. This protects against:

• Repeated read attempts stressing already-damaged drives.
• Recovery tool bugs corrupting the source.
• Multiple recovery attempts requiring fresh source state each time.
• Drive failure during extended recovery sessions.
• Chain-of-custody requirements in forensic contexts.

The standard Unix recovery workflow

The complete recovery workflow on Linux/macOS:

1. Stop using the drive: unmount immediately; remount read-only if access is essential.
2. Identify the drive: lsblk on Linux, diskutil list on macOS; record exact device path.
3. Assess drive condition: SMART status (smartctl -a /dev/sda); listen for clicking; check dmesg for I/O errors.
4. Choose imaging tool: dd for healthy drives, ddrescue for damaged drives, hardware imager for severely damaged.
5. Create the image: to a destination drive at least as large as source; write to a separate physical drive.
6. Verify image integrity: calculate hash of source (sha256sum) and image; compare for confirmation.
7. Run recovery against the image: use loop devices to mount the image (sudo losetup /dev/loop0 disk.img).
8. Use specialized recovery tools: TestDisk for partition recovery, PhotoRec for file carving, ext4magic/extundelete for ext deleted files, R-Studio Linux for cross-filesystem recovery.
9. Save recovered files: to a separate destination, never to the source or image.
10. Document the recovery: tools used, parameters, hashes, results.

Why dd is the foundation of recovery workflows

dd appears in nearly every recovery workflow description because:

• Universal availability: every Unix-like system has dd installed by default.
• No dependencies: works without any external tools or special privileges beyond root.
• Operating system independent output: dd images can be analyzed on any system.
• Predictable behavior: byte-for-byte copy with no transformation by default.
• Scriptable: easily integrated into automated recovery and backup workflows.
• Composable: pipes naturally with gzip, ssh, split, dcfldd for various scenarios.

When dd is appropriate

Despite ddrescue being preferred for damaged drives, dd has clear roles:

• Healthy drive backup: routine system backups before upgrades or migrations.
• Drive cloning for migration: moving system from old drive to new drive.
• Bootable USB creation: writing OS installation images to USB drives.
• Forensic imaging of healthy evidence drives: with dcfldd for hash verification.
• Test data generation: using /dev/urandom or /dev/zero for performance testing.
• Partial imaging: using count=, skip=, seek= for specific drive regions.
• Network imaging across SSH: efficient transfer to remote backup servers.

When dd is dangerous

Specific scenarios where dd should be avoided or used with extreme caution:

• Drives showing SMART errors: use ddrescue instead.
• Drives with mechanical issues: dd reads stress the drive further.
• Critical irreplaceable data without backup: any single-pass tool risks the data.
• Mounted filesystems: dd on mounted source can produce inconsistent images.
• Boot drives during operation: imaging the running system drive can capture inconsistent state.
• When destination is smaller than source: truncation guaranteed.
• Tired or distracted operator: the syntax similarity between safe and destructive commands amplifies typo risk.

Recovery from dd-related disasters

When dd has been misused (wrong direction, wrong drive), recovery prospects depend on what was overwritten:

• Reversed if= and of= caught immediately: some recovery possible if minimal data was overwritten before stop.
• Wrong destination drive (full overwrite): data is gone; restore from backup.
• Wrong destination drive (partial overwrite): data after the overwrite point may be recoverable via partition recovery tools.
• Image to wrong destination file: minimal damage if the destination file was empty space.
• The lesson: always pause before pressing Enter on a dd command; verify if= and of= one more time.