dd

dd copies data from an input stream to an output stream while applying requested block sizes and conversions. It does not understand filesystems, partition boundaries, or whether an output target contains valuable data. That makes it useful for images and raw devices—and immediately destructive when the target is wrong.

Input, Output, and Block Size

A command has this general shape:

$ dd if=input.img of=output.img bs=4M status=progress

• if= selects the input; without it, dd reads standard input.
• of= selects the output; without it, dd writes standard output.
• bs= sets the input and output block size for ordinary copying.
• status=progress asks GNU dd to report periodic transfer progress.

dd copies blocks, not inherently one byte at a time. A larger bs can reduce system-call overhead, but the optimal value depends on devices, alignment, caching, and workload. It does not change the logical data copied.

Limiting the Copy

count= limits the number of input blocks processed. For a regular input file:

$ dd if=source.img of=prefix.img bs=1M count=2 status=progress

This requests two input blocks of up to 1 MiB each, so it copies at most 2 MiB. Short reads can complicate the simple multiplication for streams such as pipes; GNU dd offers iflag=fullblock when complete input blocks are required. Distinguish binary units and suffix syntax according to the local implementation.

Writing an Image to a Block Device

A raw restoration can look like:

$ sudo dd if=backup.img of=/dev/sdX bs=4M status=progress conv=fsync

/dev/sdX is deliberately a placeholder, not a command to copy. Before replacing it:

1. Maintain a tested backup of all valuable data.
2. Identify the target by model, serial, size, transport, and persistent link using lsblk, udevadm, or equivalent tools.
3. Confirm that no target partition is mounted, used as swap, part of RAID or LVM, or opened by another service.
4. Recheck the device after any unplug, reboot, or topology change.
5. Ensure the image fits and that writing the whole device is truly intended.

The output device is overwritten from its beginning. Reversing if and of, selecting the system disk, or using a whole disk when a partition was intended can destroy data without a confirmation prompt.

Creating a Consistent Image

Reading a live block device while its filesystem is changing can produce an internally inconsistent image. Prefer an unmounted filesystem, an application-consistent snapshot, or a documented freeze/snapshot workflow. Databases and virtual machines can require their own quiescing procedures.

A raw device image copies blocks, including filesystem metadata and unused regions, so it can be much larger than a file-level backup and can reproduce identifiers that must be changed before mounting a clone alongside the original.

Completion and Verification

The command completing without an I/O error does not prove that the intended source and target were selected or that the image is usable. Record the exact identities and sizes, ensure buffered output has reached storage, compare an appropriately bounded read-back or cryptographic hashes, and test recovery according to the backup plan.

Do not advertise dd overwrite passes as guaranteed secure erasure for SSDs, flash translation layers, thin-provisioned storage, snapshots, or remapped sectors. Use device- and platform-supported sanitization plus an explicit data-destruction policy.

Practice only with regular files or disposable virtual disks before touching raw hardware. Partition and filesystem concepts in Manage Linux Partitions and Filesystems provide essential context.

Summary

You can now reason about dd as a raw block-copy tool with no intent awareness.

1. Distinguish if, of, bs, and count.
2. Verify persistent target identity and every active consumer.
3. Create images from a consistent storage state.
4. Flush, verify, and test recovery after a copy.
5. Treat every raw-device output as potentially destructive.