Learn Rsync - Backup Strategy: Incremental & Full
Designing a proper backup strategy: understanding full vs incremental backups, why tar alone isn't enough, and the time-machine-style hardlink snapshot pattern with rsync -a --link-dest that produces space-efficient snapshots without duplicating data.
#Introduction
Up to episode 7, you could copy and synchronize. Episode 8 shifts the perspective: from "copying files" to designing a backup strategy. The question to answer isn't "how do I copy", but "if the server dies today, what do you want to recover, and how far back?"
This is where rsync shines: with a single pattern — hardlink snapshots — you get a daily backup history that looks like a full backup every single day, but only consumes space equal to the changes that occurred.
#Backup Concepts: Full vs Incremental
- Full backup — copies all data every time. Simple and easy to restore, but wasteful: 30 days of daily backups = 30× the data size.
- Incremental backup — only stores changes since the last backup. Space-efficient, but recovery is chained: to restore day 25, you need the full backup plus 24 sequential deltas. One missing link breaks the whole chain.
- Differential backup — only stores changes since the last full backup. A compromise between the two.
| Aspect | Full | Incremental | Differential |
|---|---|---|---|
| Size | Large | Small | Medium |
| Recovery | One step | Delta chain | Full + one delta |
| Complexity | Low | High | Medium |
#Why Tar Alone Isn't Enough
tar creates full backup archives that are expensive in space and slow to recreate. The common "weekly full tar + daily rsync" strategy works, but has weaknesses: tar archives can't be mounted directly, they need extra space for both the archive and the raw files, and restoring a single file means unpacking the archive.
Hardlink snapshots offer something tar doesn't: daily backups where every day looks complete and can be accessed directly as an ordinary directory, with no recovery chain.
#How Hardlink Snapshots Work
The core of the pattern: every day, copy the source into a new directory, but files that didn't change don't need to be copied — just create a hardlink to the same file from the previous snapshot. A hardlink is two (or more) names pointing to the same inode; there's no data duplication on disk.
mkdir -p /backup/backup-1
rsync -a /home/data/ /backup/backup-1/rsync -a --link-dest=../backup-1/ /home/data/ /backup/backup-2/On day 2, unchanged files from day 1 become hardlinks (nearly free), new files are copied in full, and changed files are rewritten. backup-2 looks like a full backup — you can browse, copy, or delete freely — but it only consumes space for the truly new data.
#Practice: --link-dest
An important point about --link-dest: its path is relative to the destination directory. Because the destination is /backup/backup-2, ../backup-1 refers to /backup/backup-1. Verify the space savings:
ls -la /backup/backup-2/
stat -c '%i %h %n' /backup/backup-1/file.txt /backup/backup-2/file.txtstat shows the inode (%i) and the hardlink count (%h). If two files have the same inode and %h = 2, they share the same data — proof the space-efficient snapshot works.
Note
--link-dest only creates hardlinks for files that haven't changed. Changed files are written as new files — rsync never overwrites files in an old snapshot, so every snapshot stays intact and consistent. That's what makes it safe for backup history.
#Verifying Snapshots
A habit worth instilling: a backup never tested with a restore is the same as having no backup. For snapshots, testing is as simple as copying one snapshot to a temporary directory and comparing:
rsync -a /backup/backup-2/ /tmp/restore-test/
diff -r /home/data/ /tmp/restore-test/diff -r compares contents. If there's no difference, the snapshot can be trusted. We'll continue this verification habit in episode 16 (dry-run & checksum).
#Advantages and Disadvantages
| Advantages | Disadvantages |
|---|---|
| Every snapshot looks full and is directly accessible | Needs a filesystem that supports hardlinks (ext4, xfs, btrfs, zfs) |
| Huge space savings for slowly changing data | Inode/hardlink handling doesn't work on FAT/NFS filesystems |
| No restore chain — deleting one snapshot is safe | "Partial" history: snapshots only capture daily changes |
| Old snapshots can be deleted without damaging others | Needs a rotation script so they don't pile up (episode 9) |
#Closing
In this episode you've understood backup strategies and the hardlink snapshot pattern.
Key takeaways:
- Full vs incremental vs differential: understand the size vs restore-complexity trade-off.
tarisn't the optimal solution for daily, directly accessible backups.- Hardlink snapshots: unchanged files = hardlinks, changed files = new copies.
--link-dest=../backup-1/is relative to the destination directory.- Always test restores — an untested backup has no value.
In episode 9 we automate everything: hardlink snapshots & backup rotation — a rotating daily/weekly/monthly script with --link-dest, cleanup of old snapshots, and the best practice of consistent --delete + --delete-excluded across snapshots. See you in episode 9!