Safely create and restore Ubuntu disk images with dd

Creating and restoring disk images with dd on Ubuntu gives you a byte-for-byte copy of a drive, including its partition table and free space. It is useful for system recovery, cloning a proven installation, and preserving a drive before a repartitioning job.

The process is powerful rather than selective. A raw image can contain deleted files and must be handled like sensitive data, while copying a mounted filesystem can produce an inconsistent result unless its partitions are properly prepared or the source is offline.

Inspect disks before copying anything

Begin by inventorying every internal and removable drive. The lsblk command displays sizes, mount points, models, and serial numbers without modifying any data:

lsblk -e 7 -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo blkid

Treat the model and serial number as the real identity of a disk. Names such as /dev/sda and /dev/sdb can change between boots or when USB devices are connected. Ubuntu usually provides stable symlinks under /dev/disk/by-id/; resolving one before use can prevent a serious targeting mistake.

ls -l /dev/disk/by-id/
readlink -f /dev/disk/by-id/REPLACE_WITH_DEVICE_ID

Check the available space as well. A raw image normally occupies the full advertised capacity of the source disk, even when it contains lots of empty space. Australian drive listings commonly use decimal terabytes, so a 1 TB disk appears as roughly 931 GiB in Ubuntu. That difference is normal, but it can make a raw image appear larger than the free space reported by df -h.

Choose safe storage and image scope

The image file must be stored on a different physical disk from the drive being copied. Keeping both on the same device creates a circular backup and can overwrite the source while the copy is running. A common home-office arrangement in Sydney or Melbourne is to image a laptop SSD onto a 4 TB or 8 TB external USB drive, which works well when the USB drive is connected directly rather than through an unpowered hub.

Before reading the source, unmount every partition belonging to it. A source partition should not be mounted, and its filesystem should be clean before the copy begins. For the currently running root drive, boot an Ubuntu live USB and perform the imaging from that environment instead.

sudo umount /dev/REPLACE_WITH_PARTITION

Choose between a whole-device image and a partition image. Copying /dev/sdX preserves the partition table, partition boundaries, bootloader area, and every sector. Copying /dev/sdX1 captures only that partition’s contents and does not preserve the partition layout. A whole-device image is usually the better choice when the goal is a bootable recovery copy.

If the source reports repeated I/O errors, stop using dd. GNU ddrescue is designed to recover as much readable data as possible from a failing drive, whereas ordinary dd may spend a long time retrying bad sectors and produce an incomplete image.

Create the image with dd

Set the source to its stable by-id path, then create the image on the separate backup disk. The following example creates a raw file containing the entire source device:

SOURCE=/dev/disk/by-id/REPLACE_WITH_SOURCE_ID
sudo dd if="$SOURCE" of=/mnt/backups/ubuntu-disk.img bs=4M status=progress conv=fsync

Here, if identifies the input device, of identifies the output file, and bs=4M reads and writes in four-megabyte blocks. The progress display reports throughput, while conv=fsync asks dd to flush the completed output before returning.

Large images can be compressed to save storage. This pipeline writes a gzip-compressed file while dd continues to report its progress:

sudo dd if="$SOURCE" bs=4M status=progress | gzip -1 > /mnt/backups/ubuntu-disk.img.gz

The compression level affects speed rather than the restored contents. A low level such as 1 is faster and still saves considerable space, while a higher level can become expensive in processing time on an older Ubuntu machine.

dd copies until it reaches the end of the source device. It does not stop at the highest occupied sector, so the image will normally match the source’s complete advertised size. Keep the .img extension to make the raw format obvious and avoid accidentally selecting a compressed archive during restoration.

Check and protect the image

Calculate a SHA-256 checksum after the copy finishes. This detects later corruption and confirms that a file copied to another location arrived intact:

sudo sha256sum ubuntu-disk.img > ubuntu-disk.img.sha256
sudo sha256sum -c ubuntu-disk.img.sha256

For a compressed archive, test the gzip stream and hash the compressed file itself. The gzip integrity test detects damaged compressed data, while the checksum confirms that the archive has not changed since it was recorded.

gzip -t ubuntu-disk.img.gz
sha256sum ubuntu-disk.img.gz > ubuntu-disk.img.gz.sha256
sha256sum -c ubuntu-disk.img.gz.sha256

A raw image can expose deleted files, saved browser data, and encryption keys that remain in unallocated areas. Restrict access on filesystems that support Unix permissions, and use full-disk LUKS or an encrypted container when the image contains sensitive material. A second encrypted copy is especially useful for regional Australian users, where intermittent power or limited connectivity can make replacement hardware harder to obtain. Equipment stored in a hot Brisbane office also benefits from ventilation and a separate copy, since heat and electrical interruptions can affect both the source and its backup.

Restore the image onto a target disk

The target must be at least as large as the image, and every partition on it must be unmounted. Identify it by model and serial number, then inspect its existing signatures with the read-only option of wipefs. This does not erase anything, but it helps confirm that you have selected the intended device.

TARGET=/dev/disk/by-id/REPLACE_WITH_TARGET_ID
sudo wipefs -n "$TARGET"

Restore an uncompressed image by writing it directly to the target block device:

sudo dd if=/mnt/backups/ubuntu-disk.img of="$TARGET" bs=4M status=progress conv=fsync

For a gzip archive, decompress it while dd writes to the target:

gzip -dc /mnt/backups/ubuntu-disk.img.gz | sudo dd of="$TARGET" bs=4M status=progress conv=fsync

Verify the restored bytes where the target is exactly the image size. The byte limit prevents comparison from continuing into unused space on a larger disk:

sudo cmp -n "$(stat -c %s ubuntu-disk.img)" ubuntu-disk.img "$TARGET"

A compressed image can be compared in the same way after decompression. Never restore an image to a smaller disk, and do not assume a successful write means the copied system will boot on different hardware.

Handle SD cards and compressed images

SD cards appear as /dev/mmcblk0 when connected through a reader built into a computer, but many USB card readers present them as /dev/sdX or /dev/sdb. Remove and reconnect the card while watching lsblk if its identity is uncertain. Always write to the whole card, such as /dev/mmcblk0, rather than a partition such as /dev/mmcblk0p1.

For the operating-system side of a Raspberry Pi build, the Raspberry Pi setup guide provides the relevant installation details. A raw dd image is useful when an exact block-level copy is required, but it is not a substitute for a distribution-specific setup workflow.

Parallel gzip can reduce compression time on a modern multi-core system. Ubuntu provides it through the pigz package:

sudo apt install pigz
sudo dd if="$SOURCE" bs=4M status=progress | pigz -1 > ubuntu-disk.img.gz

Restore that archive with the matching parallel decompression command:

pigz -dc ubuntu-disk.img.gz | sudo dd of="$TARGET" bs=4M status=progress conv=fsync

SD cards have limited write endurance, so repeated full-card restorations consume useful capacity and wear. Record the card’s identifier and keep separate images for different systems rather than overwriting one generic card image each time.

Finish the recovery and protect future data

Check the restored disk before attempting to boot it. lsblk should show the original partitions and mount points, while blkid confirms that their filesystem identifiers were preserved. Do not repair or resize a filesystem until the restored contents have been checked and any required data copied elsewhere.

sudo lsblk -f "$TARGET"
sudo blkid

A whole-disk image preserves the partition layout, but a restored Ubuntu installation may still require attention. Moving it to another computer can involve a different UEFI or legacy boot mode, vendor drivers, Secure Boot, or a bootloader tied to the original disk. A target larger than the source may contain unused space that remains outside the restored partition until the partition and filesystem are expanded with appropriate tools.

Use an ISO-style filename with a UTC timestamp, because Australia’s day-first date display and AEST or AEDT clock changes can make manually written names harder to order. The command date -u +%Y-%m-%dT%H%M%SZ produces an unambiguous label. The practical takeaway is to identify both disks by model and serial, keep the image on separate hardware, verify the saved bytes with a checksum, and rehearse the restore before the original drive becomes unusable.