How to Create and Restore Disk Backups With dd and rsync

Two backup approaches get confused because both involve a disk. One copies the blocks and brings back a bootable machine in one step; the other copies files and saves space. Choosing correctly depends on what you need to recover and how much time you have. The mechanics of the first are in using dd safely, and the commands assume GNU coreutils 9.x and rsync 3.3.

Block-level image

sudo umount /dev/sdb1
sudo dd if=/dev/sdb bs=4M status=progress | zstd -T0 -3 > sdb.img.zst
zstd -dc sdb.img.zst | sha256sum

Imaging the unmounted device gives a consistent copy. Compressing in the pipe shrinks empty space heavily, so a mostly empty 500 GB disk compresses to a fraction. The checksum of the decompressed stream is stored alongside, so a later restore can be verified against it. Restore with zstd -dc sdb.img.zst | sudo dd of=/dev/sdc bs=4M status=progress conv=fsync, to a disk of the same size or larger.

File-level backup

sudo rsync -aHAX --delete --numeric-ids \
  --exclude={'/proc/*','/sys/*','/dev/*','/run/*','/tmp/*','/mnt/*'} \
  / /mnt/backup/rootfs/

-a keeps permissions, times, owners and links. -H keeps hard links, -A ACLs and -X extended attributes, which matter for system files. The excludes skip virtual file systems that are not data. Run it twice: the second pass is quick and picks up what changed during the first. For a bigger picture of copying, read scp, rsync and sftp.

Snapshots make live backups consistent

sudo lvcreate --snapshot --size 5G --name rootsnap /dev/vg0/root
sudo mount -o ro /dev/vg0/rootsnap /mnt/snap
sudo rsync -aHAX /mnt/snap/ /mnt/backup/rootfs/
sudo umount /mnt/snap && sudo lvremove -y /dev/vg0/rootsnap

A busy file system changes under a copy, so a database file may be torn. A snapshot freezes a point in time. LVM and Btrfs both offer them, and the second is shown in Btrfs snapshots. Databases still need their own dump or a flush, since a snapshot of files in use is crash-consistent, not application-consistent.

Prove it restores

mkdir /tmp/restore-test
rsync -a /mnt/backup/rootfs/etc/ssh/ /tmp/restore-test/
diff -r /etc/ssh /tmp/restore-test && echo "restore sample matches"

At minimum, restore a sample and compare it. At best, boot the image in a virtual machine and run the service. Schedule that check; verifying a backup restores describes the routine. Copy the backup to a second location too, since a backup on the same disk fails with it.

Decide what you are protecting against

A backup design starts from the failure it must survive. Accidental deletion needs versions on the same disk, a snapshot or file history, and is cheap. A failed drive needs a copy on another device. A fire, a flood or a theft needs a copy in another place. A ransomware attack or a malicious administrator needs a copy that the compromised system cannot modify or delete, such as an offline disk or a store with immutability. Each level adds cost and delay, and most systems need a mix. The rule of keeping three copies on two kinds of media with one offsite is a useful checklist, not a law, and the right answer depends on what the data is worth and how fast it must come back.

State two numbers for each system: how much recent data you can afford to lose, and how long you can be without it. They decide the frequency of backups and the method of restoring, and they settle arguments about cost.

Image or files

An image of a whole disk captures everything, including the partition table, boot loader and file system, and restores a machine to the exact state in one operation. It is large, slow to take and hard to search, and it copies unused space unless the tool understands the file system. File-level backups copy only the data, support incremental runs that transfer changes only, allow restoring a single file and work across different hardware. Most servers are best served by file-level backups of data plus configuration management for the system, with an occasional image of the system disk as a convenience. Desktops often use file backups for the home directory and rebuild the system from installation media.

For databases and virtual machines, a file copy of a running system is inconsistent. Use the database's own dump or snapshot mechanism, or quiesce the application, before copying.

Consistency and atomic copies

A copy taken while files change can be internally inconsistent: a database file that is half old and half new is useless. The remedy is a point-in-time snapshot, from LVM, Btrfs, ZFS or the hypervisor, which freezes a consistent view while the copy runs from the snapshot. Take the snapshot, copy from it, then delete it. Check that your snapshots really are consistent for the workload by testing a restore, because crash-consistent is not the same as application-consistent. Tools such as rsync with --link-dest create dated directories that look like full backups but share unchanged files through hard links, giving cheap history.

Encrypt backups that leave the building, and keep the key separately from the data. A backup encrypted with a key that was only on the lost machine is no backup.

Prove it restores

The only measure of a backup is whether it restores. Schedule restore tests: pick a random file and a random date, restore it to a scratch location and compare it with the source. Periodically restore a whole system into a virtual machine and boot it. Time the exercise, because the recovery time you measured is the true one, and record the steps in a runbook that a colleague could follow. Monitor the backup jobs themselves: size, duration and a heartbeat on success, and alert on silence and on sudden changes in size, which often signal a broken exclusion or a failed mount. Keep a retention policy that matches the need, and delete expired backups deliberately so the storage does not fill and halt the job. A backup system is a service, and like any service it needs an owner, monitoring and regular drills.

Document the whole thing in one page: what is backed up, where it goes, how often, how long copies are kept, who is alerted, where the keys are and the exact commands for a restore. Print or store a copy outside the systems it describes, because a runbook kept only on the failed server is no help during the outage. Review it after every change in the environment and after every drill, and record the date of the last successful restore test at the top, so anyone can see at a glance how fresh the evidence is.

Where this does not apply

For data that changes by the minute, such as a database, use the database's own tool. For laptops with scattered files, a deduplicating tool like borg or restic gives history and encryption that raw rsync does not. An image of a LUKS-encrypted disk is encrypted at rest, which helps, but it also means you cannot restore single files without decrypting. See the rsync documentation for every flag.

The zstd project page documents the compression levels used above; level 3 is a good default for a disk image because it compresses quickly enough to keep up with the disk.