A full system backup with rsync is the simplest complete-copy tool in the toolbox: one command that walks the filesystem tree and reproduces it byte for byte on the destination, preserving every permission, ownership, timestamp and extended attribute along the way. The tool is already installed, the syntax is already known, and the result is a tree that can be browsed with cd and restored with cp, which is why the method survives every fashion in backup tooling. This article covers the flags that make the copy faithful, the directory boundaries and pseudo-filesystems to exclude, the SELinux and ACL attributes that xattrs carry, the hardlink and sparse-file handling, and the verification that proves the copy is real.
The flags that make the copy faithful
The working rsync command for a full system copy carries one flag set that is worth memorizing:
rsync -aHAXx --numeric-ids --info=progress2 / /mnt/backup/
Each letter earns its place. The archive set -a bundles the recursive walk with permissions, timestamps, ownership and group, the baseline contract. The H preserves hardlinks, because the kernel and the package managers create them and a backup without them reproduces the content twice instead of once. The A carries POSIX ACLs, the extended permission model that lives alongside the classic mode bits, and the X carries every other extended attribute, the SELinux labels, the capability bits, the user namespace attributes. The x restricts the walk to one filesystem, the guard against the pseudo-filesystems that would otherwise be walked into /proc and /sys. The --numeric-ids transfers the uid and gid numbers literally rather than by name, the flag that matters when source and destination have different user databases. And --info=progress2 is the modern output format that prints one updating line instead of a file per line.
The set is the answer to the question the backup community asks constantly, which rsync flags for a full copy, and the answer is always the same five letters plus two, because each one covers a property that a shorter set would lose.
What to exclude and why the exclusions are mandatory
The copy of a live filesystem needs an exclusion list, and the mandatory entries are the pseudo-filesystems and the volatile trees. The exclusion file, --exclude-from, carries the standard set:
/proc/*
/sys/*
/dev/*
/run/*
/tmp/*
/mnt/backup/*
/var/tmp/*
swapfile
Each entry is a filesystem that the kernel creates and populates at boot, or a volatile tree whose contents do not survive reboot anyway, or the backup's own destination, which must be excluded from itself or the copy will recurse into its own output. The /dev entry is the one that catches people, because the device nodes are kernel-created and the backup of them is meaningless, and the exclusion of the backup destination is the recursion guard that turns a self-consuming loop into a clean copy.
SELinux contexts, ACLs and the xattr depth
The extended attributes that the X flag carries include the SELinux labels, and on an SELinux-enforcing system this is not optional: a restored tree without its labels either fails to boot or fails to serve, because every access control decision depends on the type field of the label. The restore procedure on an SELinux system is the rsync with X plus the relabel that fixes any gaps:
restorecon -Rv /mnt/backup/
and the ACL model, the A flag, carries the fine-grained permission entries that the setfacl tool manages, the ones that a backup without A would silently flatten into the classic rwx model. The capability bits that the previous article's setcap set on binaries are also extended attributes, and the X flag carries them through the copy, so the restored system's tcpdump still captures without setuid, the property that separates a faithful backup from a stripped one.
Hardlinks and sparse files, the two special cases
The H flag preserves hardlinks, and its omission is the classic silent error: the backup takes twice the space for linked files, and the restored system behaves correctly until the disk fills with the duplicated content. The sparse files are the second special case: the files that report a logical size much larger than their disk footprint, the thin-provisioned images and the vacuumed database files, and rsync's sparse handling, the --sparse flag, preserves the footprint rather than materializing the zeros. The combination of the two flags is the complete answer to the question of why the backup is larger than the original, and the answer is always one of the missing flags.
Verification and the restore rehearsal
The verification of a full system backup has two levels, and both belong in the procedure. The file-level check is the rsync dry-run comparison, running the same command with --dry-run after the copy completes and confirming that the output is empty, the zero-delta that proves the destination matches the source. The functional check is the boot test, the restored tree booted in a VM or on spare hardware, the system coming up, the services starting, the proof that the backup is a system rather than a directory.
The restore path from the backup tree is the inverse of the copy, the same rsync command with source and destination swapped, run from a live environment with the destination mounted, and the boot configuration, bootloader and fstab, rebuilt as the final step because the device names on the restore target may differ from the source. The chroot-based procedure from the initramfs article in this series covers the bootloader repair in detail, and the full-system rsync restore is the procedure that ends with the same verification: boot, services, application response, the three checkpoints that close any restore.
Scheduling and the incremental pattern
The full-copy pattern has an incremental sibling that rsnapshot implements through hardlinks, and the choice between the two is the custody decision rather than a capability question. The daily full copy is the simplest schedule, one rsync run per day to a dated directory or to the same directory with the delete flag, the --delete flag that makes the destination a true mirror, removing files that no longer exist at the source. The mirror without the dated directories is the simplest possible schedule, and the dated version, one directory per day, links to the snapshot rotation story from the rsnapshot article.
The maintenance of the backup tree is the rotation: old directories deleted on the schedule the retention policy names, the rsync --delete handling the mirror pattern, and the disk space monitoring covering the backup destination the way every other filesystem in this series is monitored. The backup's own health is the newest copy's age and the dry-run's zero-delta, the two signals that confirm the system is working, and the quarterly boot test of the restored tree is the proof that the whole chain from production to recovery is live.
## The remote variant, pulling instead of pushing
The direction of the copy is a security decision, and the pull model, the backup host reaching into the source rather than the source pushing out, is the posture this series prefers. The pull runs from the backup host with the SSH connection and the rsync over it:
rsync -aHAXx --numeric-ids root@prod01:/ /mnt/backup/prod01/
and the production host holds no credentials for the backup, the compromise of the source cannot reach the backup the way a push-based system allows, the same architectural inversion the rsnapshot article described for its remote sources. The pull host holds the root key for the production hosts, a privilege with a specific blast radius, and the key's scope is the reason the bastion article's separation matters: the backup host's key reaches the source filesystem but not the source's management plane, and the SSH restriction on the key, the command= directive in authorized_keys, limits the access to the rsync protocol alone, the one-command key pattern that the Borg serve section and the SSH certificate article both built.
The remote variant's performance consideration is the network: a full copy across a gigabit link moves at the link's pace, the hundred-gigabyte system tree taking under fifteen minutes on a clean link, and the incremental runs, where rsync's delta algorithm transfers only the changed blocks, complete in the time the change rate takes. The bandwidth limit, --bwlimit, is the throttle for shared links, the same consideration every network transfer in this series carries, and the schedule for the pull is the nightly window that the backup articles established.
The recovery scenario on new hardware
The full-system restore onto new hardware is the scenario that separates a faithful backup from a directory copy, and the procedure has one extra step beyond the inverse rsync: the bootloader and the device names. The restored tree lands on the new disk, the partition layout may differ, and the /etc/fstab and the bootloader configuration reference the source's UUIDs, which the new hardware may not honor. The repair is the chroot procedure from the initramfs article: mount the restored root, bind the virtual filesystems, enter the chroot, update the fstab with the new UUIDs, reinstall the bootloader, and reboot. The UEFI systems add the ESP partition to the procedure, the EFI directory mounted and the bootloader files present, and the whole recovery is a thirty-minute procedure when rehearsed, a Sunday afternoon when it is not.
The rehearsal is the quarterly discipline the backup articles established, and the full-system rsync backup is the easiest of the three tools to rehearse: the restored tree boots in a VM on the same hardware or on any hypervisor host, the boot proves the filesystem and the bootloader, the services prove the system, and the rehearsal's fifteen minutes are the cheapest insurance the backup methodology can buy. The fleet that runs the full-copy backup weekly, the boot test quarterly, and the audit of the exclusion list on the same calendar has a recovery capability that the industry measures in RTO and RPO numbers, and the numbers it produces are the ones the stakeholders ask for and rarely get: recovery time in minutes, recovery point in hours, and evidence for both in the backup tree itself.
The closing frame on the full-copy pattern
The full rsync backup with xattrs is the method that the industry's tooling has grown around rather than replaced, because the pattern it produces, a directory tree that is the system, readable by anything, restorable by anything, is the substrate that every other backup format must eventually decompress into. The chunk-deduplicating tools compress the storage and encrypt the transport, and the rsync tree is the ground truth they restore into, the format that every verification ultimately reads. Keeping one full-copy backup in the architecture, alongside the deduplicated repositories, is the practice that gives the recovery procedure a format that never needs a tool to read it, and the tool that produces it is installed on every machine this series describes.
The full-system backup is the method that costs nothing to set up, nothing to learn, and nothing to maintain beyond the disk it writes to, and the discipline that makes it trustworthy is the verification loop, the dry-run that proves the copy and the boot test that proves the restore. The server that runs both on schedule has a recovery capability measured in minutes and a backup methodology measured in decades of practice.
The dry-run verification and the boot test take fifteen minutes combined on any host in the fleet, and the discipline that costs fifteen minutes is the one that returns the entire system in thirty when the disk dies.
It is the simplest tool that produces the most faithful copy, and that is the whole recommendation.
It works everywhere and always will.