Backups

The goal isn't "a copy exists somewhere" - it's "when something breaks, I can get back a known-good state, and I've actually verified that I can."

The 3-2-1 rule

A widely used baseline: keep 3 copies of important data, on 2 different types of media, with 1 copy off-site. In practice for a typical setup: the live data itself, a local backup (a second disk, a NAS), and an off-site or cloud copy - so that no single failure (a disk dying, a fire, a ransomware attack that reaches locally-mounted backups) takes out every copy at once.

rsync: the workhorse for file-based backups

rsync -avz /home/alice/ backup-server:/backups/alice/

• -a (archive) - preserves permissions, ownership, timestamps, and symlinks, and recurses into directories; the flag you almost always want for a backup rather than a plain copy
• -v - verbose, so you can see what's happening
• -z - compress data in transit, useful over a slow network link

rsync only transfers what changed since the last run, making repeat backups of large trees fast compared to copying everything each time. See SSH for the connection rsync uses when the destination is a remote host, as above.

Space-efficient incremental backups with hard links

A well-known rsync technique keeps multiple dated snapshots without storing unchanged files repeatedly, using hard links (see Links: Hard vs. Symbolic) to share unchanged files between snapshots:

rsync -a --link-dest=/backups/2026-08-27 /home/alice/ /backups/2026-08-28/

Files unchanged since the previous snapshot become hard links to the same inode in the new snapshot directory - appearing as full copies at every date, while actually consuming disk space only once per unique file version.

tar: archiving

tar czf backup-2026-08-28.tar.gz /home/alice/
tar xzf backup-2026-08-28.tar.gz -C /restore/location/

c create, x extract, z gzip-compress, f specify the archive filename. Use tar when you want a single portable archive file (to move off-site, upload somewhere, or store long-term) rather than a live mirror directory the way rsync produces.

Dedicated backup tools

For anything beyond a simple script, purpose-built tools solve problems rsync/tar don't handle well on their own:

• restic and borgbackup - deduplicating, encrypted backups with efficient incremental snapshots, built-in retention policies (keep daily for a week, weekly for a month, etc.), and support for cloud storage backends directly
• Timeshift - filesystem-level snapshots on Btrfs or via rsync, aimed more at "restore my whole system to yesterday" than per-file backup

Scheduling backups

Run backups on a schedule with cron or a systemd timer - see Cron and Scheduled Tasks - and make sure failures are visible rather than silent (log output somewhere you'll actually check, or alert on a non-zero exit status).

Test the restore, not just the backup

The single most common way backups fail you is being discovered broken only when you need them - a permissions issue preventing the backup script from reading certain files, a corrupted archive, a config error that's been silently backing up an empty directory for months. Periodically restore from a backup to a scratch location and verify the data is actually complete and usable - treat an untested backup as an unverified claim, not a guarantee.