Rocky 10: incremental backups with rsync --link-dest

Test scope

In a Rocky Linux 10.2 container (rsync 3.5.0): three consecutive rsync -a --link-dest=... backups, checking stat inodes, du usage and whether deleted files survive in older backups. Log: plans/content-expansion/evidence/logs/rocky-rsync-incremental.log.

The idea: full directories, shared blocks

--link-dest=<previous backup> makes rsync hard-link unchanged files and only copy new or modified data. Every backup directory looks complete, while the disk grows by the delta only.

Measured across three backups

rsync -a /var/tmp/src/ /var/tmp/bak/data/2026-10-20-01/
du -sh /var/tmp/bak/data/2026-10-20-01

592K  /var/tmp/bak/data/2026-10-20-01

After modifying one file and adding another:

rsync -a --link-dest=/var/tmp/bak/data/2026-10-20-01 \
  /var/tmp/src/ /var/tmp/bak/data/2026-10-20-02/
stat -c '%i %n' /var/tmp/bak/data/2026-10-20-01/file1.bin /var/tmp/bak/data/2026-10-20-02/file1.bin

67129114 /var/tmp/bak/data/2026-10-20-01/file1.bin
67129114 /var/tmp/bak/data/2026-10-20-02/file1.bin

Identical inodes mean one copy of the data shared by two directories — direct proof that --link-dest worked.

Every backup is a full point-in-time view

cat /var/tmp/bak/data/2026-10-20-02/notes.txt
cat /var/tmp/bak/data/2026-10-20-01/notes.txt

v1
v2
v1

The modified file carries the new content in the new backup (v1+v2) while the old backup keeps v1. Each directory is an independent point in time, so restoring needs no incremental replay.

Deletions only affect later backups

After deleting file1.bin and taking a third backup:

ls /var/tmp/bak/data/2026-10-20-03
du -sh /var/tmp/bak/data /var/tmp/bak/data/2026-10-20-02

file2.bin
file3.bin
file4.bin
notes.txt
792K  /var/tmp/bak/data
788K  /var/tmp/bak/data/2026-10-20-02

The third backup has no file1.bin while the first two still do — exactly the semantics backups need: deletion does not rewrite history. Total usage is 792K, the delta.

Common traps

• Relative --link-dest: resolved relative to the destination, which links the wrong things; absolute paths are safest;
• Trailing slash on the source: src/ copies the contents, src copies the directory itself;
• Hard links across filesystems: the destination and --link-dest must live on the same filesystem or rsync falls back to copying;
• Omitting -a: permissions and timestamps are lost and link reuse stops working.

Practice: three snapshots and a link check

rm -rf /var/tmp/src /var/tmp/bak; mkdir -p /var/tmp/src /var/tmp/bak/data
echo v1 > /var/tmp/src/notes.txt
rsync -a /var/tmp/src/ /var/tmp/bak/data/01/
echo v2 >> /var/tmp/src/notes.txt
rsync -a --link-dest=/var/tmp/bak/data/01/ /var/tmp/src/ /var/tmp/bak/data/02/
stat -c '%i %n' /var/tmp/bak/data/01/notes.txt /var/tmp/bak/data/02/notes.txt
du -sh /var/tmp/bak/data

Checks:

1. notes.txt has different inodes in the two directories (its content changed)
2. Add an unchanged file and confirm its inode matches across backups
3. du -sh grows roughly by the new data only
4. cat 01/notes.txt still shows v1 while cat 02/notes.txt shows v1+v2

FAQ

常见问题

Do hard-linked backups affect each other?

No. Hard links share data blocks, but rsync writes modified files to a new file and replaces the link, so older backups keep their original content.

How is --link-dest different from --backup?

--link-dest reuses unchanged files from a previous backup to save space; --backup keeps a copy of a file before overwriting it. They solve different problems and can be combined.

Can I use hard links to another host?

No, hard links require the same filesystem. Cross-host backups still transfer only the delta, but each destination copy stores its own full data.

Next steps

• Growing storage: LVM growth
• Log rotation: logrotate in practice
• Scheduled jobs: systemd timers