Using dd for Linux disk cloning and backup

dd copies data in blocks from an input to an output. On Linux, it supports full-disk imaging, cloning a replacement drive, and taking a raw backup before migration. A whole-device copy can include partition tables, filesystem data, LVM metadata, and an encrypted-volume header.

dd is deliberately low-level. It does not understand files, mount points, or damaged sectors, and it overwrites the destination without asking. Confirm every path, work from a rescue environment where possible, and keep another copy of anything you cannot replace.

For active servers, rsync or restic is often more practical because it updates changed content and preserves ordinary file attributes. A block-level image remains valuable for migrations, forensic work, and restoring a workstation or virtual machine in its original layout.

Australian administrators in Sydney, Melbourne, Brisbane, Perth, and Adelaide commonly manage on-premises hosts, hypervisors, and cloud instances. Disk space is often less difficult than transferring large images away from a busy data centre, especially in Perth, far from the eastern states. Careful scheduling and realistic throughput estimates matter.

Understand what dd copies

Start by deciding what must be copied. Imaging a mounted root filesystem usually produces an inconsistent file because changes continue during the read. Stop application writes, unmount the source filesystem, or use a tested snapshot mechanism with the applications quiesced.

For a bootable clone or complete restore, copy the entire disk rather than one partition. This preserves the partition table and relationships between boot, EFI, swap, LVM, and data volumes. The 4M block size is a reasonable starting point on current RHEL, CentOS, and Fedora systems.

Identify disks before writing

Identify hardware by capacity, model, serial number, and mount state; never choose a target from a remembered drive letter. Names such as /dev/sda can change after reboot. A stable /dev/disk/by-id path is safer for scripts, but still needs checking against the intended disk.

Run these commands before moving any data:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
sudo blkid
findmnt --source /dev/sdb1
findmnt --source /dev/sdc1

The examples use /dev/sdb as the source and /dev/sdc as the destination. Unmount every destination filesystem and confirm neither disk is live. On RHEL, automating dnf updates keeps patching separate from a long imaging job; update and reboot before taking the final image.

Create an image backup

Store the image on a mounted backup filesystem with enough free space, preferably on different storage from the source. Keep another copy elsewhere: an image stored on the same disk offers little protection against that disk failing.

For a raw image, direct output to the backup filesystem:

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

Compression saves space but consumes CPU and may not keep pace with NVMe reads. In Bash, enable pipefail so a failed read is not hidden by a successful compression step, then check the pipeline status before using the archive.

set -o pipefail
dd if=/dev/sdb bs=4M status=progress | gzip -1 > /mnt/backup/server.img.gz

Restore an image safely

Restore to a blank or deliberately replaced disk of sufficient size. Check its identifier again, unmount its partitions, and make sure no rescue system is writing to it. An image larger than the destination cannot be restored correctly.

For a compressed image, decompress it straight to the device. For an uncompressed image, reverse the input and output arguments. Afterwards, compare checksums, mount restored filesystems read-only where possible, and repair boot dependencies before reconnecting the disk.

set -o pipefail
gzip -dc /mnt/backup/server.img.gz | sudo dd of=/dev/sdb bs=4M status=progress conv=fsync
sudo dd if=/mnt/backup/server.img of=/dev/sdb bs=4M status=progress conv=fsync

Clone directly between disks

Direct cloning avoids a temporary image, but it overwrites the target immediately. The target is erased block for block, including existing data. Use it only after checking that the target is unmounted, is not a system disk, and is not serving as another source.

sudo dd if=/dev/sdb of=/dev/sdc bs=4M status=progress conv=fsync

Use a destination at least as large as the source; matching capacity avoids GPT secondary-header complications. Keep the clone disconnected until its partition layout, UUIDs, and bootloader have been validated. Australian NAS and server-disk offers may be quoted with or without GST (Goods and Services Tax), so compare like-for-like prices and check warranty handling through local distributors.

Verify data and boot details

A zero exit status means the copy finished, not that the result is correct. For an uncompressed image, hash the image and restored device while filesystems are quiescent, then compare the digests. For a compressed image, verify the archive checksum, restore it, and hash the device. Because sha256sum reads every byte, allow enough time for another full-disk operation.

sha256sum /mnt/backup/server.img
sudo sha256sum /dev/sdb

The image contains the partition table, but save the output of sudo sfdisk --dump /dev/sdb as an extra reference. Bootloaders, initramfs images, and fstab entries may need rebuilding on different hardware; prefer UUIDs to copied device names. The guide to tuning sysctl parameters covers host tuning, but no I/O setting can repair an incomplete copy.

Keep images inside a recovery routine

The Australian Signals Directorate’s Essential Eight includes tested offline backups. Maintain tested file-level copies of active data, keep important images offline, and practise restoring a system instead of merely confirming that an archive exists.

Images containing personal information may be governed by the Privacy Act 1988 and the Notifiable Data Breaches scheme. Encrypt portable media, restrict access, and record where each image is held. Australian daylight-saving rules differ between states, so use UTC timestamps when scheduling and documenting long jobs.

Document the source, destination, block size, checksum, and restoration procedure. Remove customer names, serial numbers, and real device paths from any public copy; a broader technical reference page can use the sanitised workflow without exposing the device map. The practical standard is a verified, restorable image kept away from the host, with recovery tested on a regular schedule.