VMware ESXi and vSphere Cluster Management

Archive and Restore a Filesystem with dd in Linux

Learn to create, restore, verify, split, and safely deploy raw Linux filesystem and disk images with dd.

The Linux dd utility copies data between files, devices, and streams at the block or byte level. It can create a byte-for-byte image of a partition, disk, or optical medium, then write that image back later.

This is powerful and dangerous: dd does not provide a recycle bin or an undo operation. A reversed input or output operand can overwrite the wrong disk immediately.

What a Raw Filesystem Image Contains

A raw image is a byte-for-byte representation of the selected source range. When the source is a partition, the image normally includes filesystem metadata, allocated file data, deleted remnants that have not yet been overwritten, and unused blocks. Boot-related data is included only when it lies inside the selected source.

dd performs block-level copying, not file-level backup. It does not understand directories, permissions, free-space maps, or the internal rules of a particular filesystem.

Raw Imaging Compared with File-Level Backup

Copy level: dd copies blocks; tar or a backup tool copies files and metadata.

Unused-space handling: dd normally copies unused blocks; file-level tools generally skip them.

Output size: A raw image is usually as large as the selected partition or device; a file-level backup is closer to the amount of stored data, often plus metadata.

Filesystem awareness: dd is filesystem-agnostic; filesystem-aware tools can interpret files, snapshots, consistency, and incremental changes.

Restore flexibility: A raw image normally requires a target of equal or greater size; file-level backups can often restore to a differently sized filesystem.

Unsupported filesystems: Raw imaging can preserve a filesystem Linux cannot mount or interpret, provided the device can be read.

Target overwrite risk: Both can overwrite files, but writing a raw image to a device can replace an entire partition or disk with no file-by-file protection.

When Low-Level Imaging Is Appropriate

Create a safety copy of a partition before resizing, repairing, encrypting, or otherwise performing destructive work.
Preserve a filesystem that the current Linux system cannot mount or understand.
Capture CD-ROM, DVD, or other block-device media as an image file.
Deploy a known-good Linux installation to comparable machines.
Create an exact copy of a partition or complete disk when capacity, partition layout, boot configuration, and hardware differences are understood.

Use a filesystem-aware tool such as tar, rsync, or a dedicated backup application when you need selective restores, incremental backups, or efficient handling of mostly empty filesystems.

Identify Sources and Destinations

A block device is storage accessed as an ordered sequence of blocks, such as a disk, partition, or optical drive. Linux exposes devices under /dev.

/dev/sdc usually identifies a complete disk.
/dev/sdc1 identifies the first partition on that disk.
/mnt/backup/sdc1.img identifies an image file on a mounted filesystem.
/dev/sr0 commonly identifies an optical drive.

Copying /dev/sdc includes the disk's partition table and all selected partitions. Copying /dev/sdc1 copies only that partition; it does not include a separate partition table, EFI System Partition, or boot record located elsewhere.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sudo blkid
findmnt
mount

Use these commands to confirm names, sizes, filesystem types, UUIDs, and mount points. Also check free space on a file destination with df -h.

Understanding dd Operands

The operand if= means input file, or the source from which data is read. The operand of= means output file, or the destination to which data is written.

dd Copy Direction Reference

Partition to image file: if=/dev/sdc1 → of=/mnt/backup/sdc1.img; creates a raw partition image; the output path must be correct and have enough space.

Image file to partition: if=/mnt/backup/sdc1.img → of=/dev/sdc1; restores the image; all current target contents are replaced.

Disk to disk: if=/dev/sdc → of=/dev/sdd; clones the complete source disk; a mistaken destination can destroy another disk.

Optical device to image file: if=/dev/sr0 → of=/mnt/backup/disc.iso; creates an optical-media image; failing media may require a recovery tool.

The bs=4M setting requests 4 MiB transfer blocks and can improve throughput. It does not change the logical contents of the copy. status=progress periodically displays progress, and conv=fsync requests that output data be flushed before dd exits.

Preflight Checklist

Identify source device: Run lsblk and blkid; distinguish the complete disk from an individual partition.

Identify destination: Inspect the target device or the mounted backup path; ensure it is not the source.

Confirm capacity: Compare source size with destination capacity and check df -h for image-file storage.

Check mounted filesystems: Use findmnt and mount; avoid copying an actively changing filesystem.

Plan consistency: Unmount the source, boot from another environment, or use a consistent snapshot.

Plan verification and retention: Reserve space for checksums and keep an independent copy of important images.

Create a Partition Image

Store the image on a different filesystem or physical device whenever possible. The destination filesystem needs free capacity approximately equal to the entire source partition, even when the partition contains little visible data.

For a consistent offline source, unmount it first:

sudo umount /dev/sdc1
sudo dd if=/dev/sdc1 of=/mnt/backup/sdc1.img bs=4M status=progress conv=fsync

The data flow is from /dev/sdc1 to the image file. If the source cannot be unmounted, use a filesystem snapshot or an offline environment when consistency matters. A live copy can contain changes from different moments and may produce a filesystem that needs repair.

Create a Full-Disk Image

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

A full-disk image includes the partition table and all partitions within the source disk's range. It is different from an image of one partition and usually requires more storage.

Create an Optical-Media Image

sudo dd if=/dev/sr0 of=/mnt/backup/disc.iso bs=4M status=progress conv=fsync

This reads the optical device into an image file. Read errors from failing media are a recovery problem; use a recovery-oriented utility such as ddrescue rather than repeatedly relying on ordinary dd.

Restore a Partition Image

Restoration reverses the input and output roles:

sudo dd if=/mnt/backup/sdc1.img of=/dev/sdc1 bs=4M status=progress conv=fsync
sync

Before running the command, confirm that the target is the intended partition and is at least as large as the image's original source. Writing the image destroys the target's current contents. Unmount the target first when appropriate, and do not restore over a partition actively used by the running system.

After the write completes, allow pending data to flush with sync. Then inspect the restored filesystem. A read-only mount, where supported, and a filesystem-specific check can reveal problems before the restored data is trusted. Follow the filesystem's own repair guidance; do not run a repair tool on a mounted filesystem unless that tool explicitly supports it.

Raw Image Size, Compression, and Sparse Files

By default, dd reads every block in the selected source range. A lightly used 500 GiB partition can therefore produce an image close to 500 GiB because unused blocks are copied too.

A sparse file represents runs of zero bytes without necessarily allocating physical storage for each run. Sparse handling can save space in some workflows, but it depends on the data and destination filesystem. It must not be confused with ordinary raw copying, which normally creates a fully allocated-sized output.

Compression can reduce storage for zero-filled or repetitive unused blocks:

sudo dd if=/dev/sdc1 bs=4M status=progress | gzip -c > /mnt/backup/sdc1.img.gz

To restore a compressed stream, reverse the pipeline and operands:

gzip -dc /mnt/backup/sdc1.img.gz | sudo dd of=/dev/sdc1 bs=4M status=progress conv=fsync

Compression trades storage space for CPU time and may make random access less convenient. Plan space for the uncompressed target during restoration.

Clone Systems and Understand Compatibility Limits

A clone is a duplicate storage copy created from an image. A full-disk image can deploy a known-good installation, while a partition image can duplicate only one filesystem.

The target must normally be the same size or larger than the source. A raw image cannot fit on a smaller target, even if little source space is used.
Different disk sizes can require partition expansion after restoration.
Partition tables, disk geometry assumptions, filesystem UUIDs, and labels may be duplicated. Duplicating a disk while the original remains connected can create identity conflicts.
Boot loaders and EFI data may be outside an individual partition. Restoring only a root partition may not restore bootability.
Firmware mode, such as UEFI versus legacy BIOS, affects boot configuration.
Different hardware may need different drivers, initramfs contents, network naming, or bootloader configuration.

Choose a full-disk image when partition layout and boot data must be reproduced. Choose an individual partition image when the partition is the only required object and boot components are handled separately.

Integrity Verification

A checksum is a digest used to detect accidental changes. Record a checksum after creating the image and validate it before restoration or long-term use.

sha256sum /mnt/backup/sdc1.img > /mnt/backup/sdc1.img.sha256
sha256sum -c /mnt/backup/sdc1.img.sha256

A matching checksum confirms that the image file matches the data used when the checksum was recorded. It does not prove that a live source was logically consistent when it was copied.

When practical, compare source and restored-target data using read-only methods. Also perform a filesystem-specific read-only check after restoration. A successful checksum of the image proves image integrity, not successful boot configuration or correct hardware compatibility.

Split and Reassemble Large Images

Large images may need splitting for removable-media limits, destination filesystem limits, or transfer constraints. Splitting does not reduce the total amount of data.

split -b 4G -d -a 3 /mnt/backup/sdc1.img /mnt/backup/sdc1.img.part-

This creates numbered pieces such as sdc1.img.part-000. Keep every piece and preserve the ordering. Stable zero-padded names prevent lexical ordering mistakes.

cat /mnt/backup/sdc1.img.part-* > /mnt/backup/sdc1.img
sha256sum -c /mnt/backup/sdc1.img.sha256

Reassemble the image before restoring it. Validate the complete assembled file before writing it to a device.

Text Filtering Is a Separate Shell Skill

Text filtering processes textual streams; it is not part of dd's raw byte copying. Common tools include:

grep selects lines matching a pattern.
sed performs stream edits and substitutions.
awk processes fields and records using programmable rules.
cut extracts selected fields or character ranges.
sort orders lines.
uniq removes or counts adjacent duplicate lines, usually after sorting.

For example, this filters and sorts filesystem types reported by block-device inspection:

lsblk -o NAME,FSTYPE --noheadings | awk '{print $2}' | grep -v '^$' | sort | uniq

Troubleshooting

The Image Is Nearly as Large as the Partition

This is expected for a raw image: unused blocks are included. Provide storage close to the source size, use suitable compression, or select a filesystem-aware backup tool when an exact image is unnecessary.

No Space Is Left on the Destination

The destination filesystem may be too small for the raw image or a reconstructed split image. Check df -h, choose larger storage, or redesign the backup method.

The Restored Partition Does Not Boot

A partition-only restore may omit boot records, an EFI System Partition, a partition table, or bootloader configuration. Determine whether a full-disk image is required, then repair or reinstall the bootloader for the system's firmware mode.

The Target Is Smaller than the Source

Raw restoration preserves the source length. Use an equal-or-larger target, or shrink the filesystem and partition with filesystem-specific tools before imaging.

The Restored Filesystem Is Inconsistent

The source may have changed during copying. Repeat the operation from an offline environment, a snapshot, or a consistency-aware backup method.

Read Errors Occur

Unreadable sectors usually indicate failing media or hardware. Preserve the source and use a recovery-oriented utility such as ddrescue, which is designed to handle read errors and maintain recovery logs.

A Split Image Fails Validation

A piece may be missing, damaged, or assembled in the wrong order. Confirm that all parts exist, use stable numbered names, reassemble them in sequence, and verify the complete image checksum before restoration.

Exam-Relevant Notes

if= is the source; of= is the destination.
Restoring an image reverses the creation command's input and output roles.
dd copies blocks, not files, and normally includes unused space.
An image of a partition does not automatically include the disk's partition table or boot data outside that partition.
Raw restoration destroys existing data at the target.
The target normally must be at least as large as the source.
status=progress provides visibility; conv=fsync or sync helps ensure writes are flushed.
Checksums detect changes but do not guarantee source consistency or bootability.

Safe Operational Sequence

Inspect devices with lsblk, blkid, findmnt, and mount.
Identify the exact source and destination, including whether each is a disk, partition, or image-file path.
Confirm destination capacity and keep the destination separate from the source.
Unmount the source or use a snapshot/offline environment when consistency matters.
Run dd with explicit operands, a practical block size, progress reporting, and output flushing.
Record and verify a checksum.
Keep a separate verified copy of important images.
Before restoration, recheck the target device one final time, then inspect and validate the restored filesystem.

For further study, review filesystem archiving and restoration alongside filesystem-aware backups, partition management, snapshots, bootloader recovery, and checksum verification.