How to make a full disk image of a server with dd

When an image is the right tool, and when it is not

dd copies a device block by block: partition table, bootloader, every filesystem and the free space. Use it when you need a disk back exactly as it was:

• Before a risky change to the disk: repartitioning, converting a filesystem, an in-place upgrade with no snapshot feature.
• Moving a whole server to a host that lets you write a raw disk: a rescue system elsewhere, a Proxmox or KVM host, bare metal.
• Keeping an exact copy of a disk you are about to wipe.

For routine backups it is the wrong tool: every image is the size of the disk, one file back means unpacking and mounting it, and the server is offline while it runs. Use file tools such as restic or tar plus database dumps. On a cloud server, the provider's snapshot does an image's job without downtime (snapshots vs backups).

Never image a mounted disk

Files change while dd reads a running system, so early blocks no longer match later ones and the image's filesystem can come out damaged, not just out of date. Instead:

• Boot a rescue system: most providers offer a rescue or recovery boot with your disk attached but not mounted. Without one, stop the server and attach its disk to another.
• Or image a frozen LVM snapshot device. That covers one volume, not the partition table and bootloader. On ZFS, use zfs send instead of dd.

Find the disk

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Image the whole disk (TYPE disk: vda, sda, nvme0n1), not a partition like vda1, so the partition table and bootloader come along. In the rescue system, your server's disk is the one without mount points; names can differ from a normal boot. Older lsblk: MOUNTPOINT. For the restore, note the size in bytes (-b) of the disk alone (-d):

lsblk -b -d -o NAME,SIZE /dev/vda

Zero the free space first

Free space still holds what deleted files left, and a compressor can't shrink that. On the running server, just before the rescue boot, fill the free space with zeros, then delete the file (once per filesystem on the disk):

sudo dd if=/dev/zero of=/zero.fill bs=4M status=progress conv=fsync

sudo rm /zero.fill

dd ends with dd: error writing '/zero.fill': No space left on device and exit status 1: the expected end, so don't let set -e stop a script there. conv=fsync flushes the zeros before dd exits, even after the error; otherwise deleting the file can discard zeros still in memory.

Worked example, on a 64 MiB test image with 16 MiB of incompressible data: with 45 MiB of leftover random data in the free space, zstd -T0 made 63,965,024 bytes (61 MiB); with it zeroed, 16,779,500 bytes (16 MiB). gzip -1: 63,992,445 and 17,002,698. Real leftovers compress better than random bytes, never as well as zeros.

Make the image and send it to another machine

In the rescue system, as root:

dd if=/dev/vda bs=4M status=progress | zstd -T0 | ssh [email protected] 'cat > /srv/images/web-01-vda.img.zst'

A healthy disk needs no conv= options. Without zstd, gzip -1 makes a .img.gz the same way. If the rescue system has no key for the backup host, pull from the backup host instead: ssh [email protected] 'dd if=/dev/vda bs=4M | zstd -T0' > web-01-vda.img.zst.

Prove the copy: sha256sum /dev/vda in the rescue system must match this on the backup host. Each reads the whole disk, so allow as long as the image took.

zstd -dc /srv/images/web-01-vda.img.zst | sha256sum

Check the image without restoring it

On the machine holding it, test the file. zstd prints the uncompressed size, which should equal the disk's:

zstd -t /srv/images/web-01-vda.img.zst

Unpack with --sparse so runs of zeros become holes. Our 64 MiB test image took 16 MiB of disk with it, 64 MiB without:

zstd -d --sparse /srv/images/web-01-vda.img.zst

fdisk -l /srv/images/web-01-vda.img

fdisk lists the image's partitions and start sectors as for a disk. To read files, attach it as a read-only loop device:

sudo losetup -P -r -f --show /srv/images/web-01-vda.img

-f --show takes the first free loop device and prints it (say /dev/loop0); -P scans the partition table, giving /dev/loop0p1 and so on; -r makes it read-only.

sudo mount -o ro /dev/loop0p1 /mnt/image

An image of a disk that wasn't cleanly unmounted needs a journal replay, which a read-only device can't take; -o ro,noload (ext4) or -o ro,norecovery (XFS) skips it, and the docs warn the result may be inconsistent. Then sudo umount /mnt/image and sudo losetup -d /dev/loop0.

Restore the image

Boot the target into its rescue system. Its disk must be at least the size lsblk -b showed. As root:

ssh [email protected] 'cat /srv/images/web-01-vda.img.zst' | zstd -dc | dd of=/dev/vda bs=4M iflag=fullblock conv=fsync status=progress

• iflag=fullblock reads until each 4 MiB block is full; a pipe delivers smaller pieces. The data is the same without it, in smaller writes.
• conv=fsync flushes to disk before dd exits: finished means written.
• No conv=sparse onto a disk: it skips zero blocks, leaving old data in them.

Partition table, bootloader and UUIDs come back as they were, so /etc/fstab and the bootloader still find their filesystems. So do the hostname, SSH host keys and static network settings, which may not fit a new host; fix those from the provider's console. The target must boot the same way (BIOS or UEFI). A copy attached next to its original duplicates their UUIDs: give an unmounted ext4 copy a new one with tune2fs -U random.

On a larger disk, GPT's backup header is no longer at the end. For our 64 MiB image on a 96 MiB disk, fdisk -l reported GPT PMBR size mismatch (131071 != 196607) will be corrected by write. and The backup GPT table is not on the end of the device. Still in the rescue system, move the header, then grow the partition that ends last (1 here; check fdisk -l):

sfdisk --relocate gpt-bak-std /dev/vda

echo ', +' | sfdisk -N 1 /dev/vda

After booting, grow the mounted filesystem: sudo resize2fs /dev/vda1 (ext4) or sudo xfs_growfs / (XFS).

Alternatives to dd

partclone copies only the blocks a filesystem uses, so the image is about the size of the data and needs no zeroing. It works per partition: save the table with sfdisk -d /dev/vda > vda.sfdisk (restore: sfdisk /dev/vda < vda.sfdisk).

partclone.ext4 -c -s /dev/vda1 -o - | zstd -T0 | ssh [email protected] 'cat > /srv/images/web-01-vda1.pcl.zst'

-c clones, -s names the source, -o - writes to standard output. Restore into a partition at least as large by piping the image into partclone.ext4 -r -s - -o /dev/vda1. Other filesystems have their own (partclone.xfs, partclone.btrfs).

Provider snapshots image a cloud server without a rescue boot: DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, Lightsail, Google Cloud and Azure. File backups restore onto any new server, whatever its disk size (restoring a server from backup).

dd's output and errors explained

Every dd run ends with three lines. This is our 64 MiB test image restored through a pipe without iflag=fullblock:

0+1037 records in
0+1037 records out
67108864 bytes (67 MB, 64 MiB) copied, 1.76665 s, 38.0 MB/s

W+P is W whole blocks plus P partial ones, reads or writes that moved less than bs. Every pipe read here was partial, yet the checksum matched; iflag=fullblock gave 16+0.

Frequently asked questions

Can I use dd on a running server?

Not on its mounted disk: files change while dd reads, and the image can hold a damaged filesystem. Boot a rescue system, or image an LVM snapshot (on ZFS, use zfs send).

How big is a dd image?

Uncompressed, exactly the disk's size. Compressed after zeroing free space, close to the compressed size of the data actually stored.

What do "records in" and "records out" mean in dd?

Blocks read and written, as whole+partial. 16+0 is 16 full blocks; 0+1037 is 1037 short reads, normal when reading from a pipe.

Can I restore a dd image to a smaller disk?

No. dd writes every block and stops with "No space left on device". Restore from file backups instead, or shrink the filesystem and partition before taking the image.