Incremental server backups that restore honestly
Ship only what changed since the last run with GNU tar incremental chains — including deletions — and verify every link daily so a restore never surprises you.
The problem with full backups every night
A 200 GB /var/www that changes 50 MB a day still costs 200 GB of transfer and storage per run. Incremental backups ship the delta: a periodic full, then small archives holding only what changed — GNU tar's --listed-incremental has done this reliably for decades.
How the chain works
A snapshot file records the state tar saw last time. The next run compares and emits only new or modified files — and, crucially, records deletions, so a restore doesn't resurrect files you removed on purpose. Restoring means replaying the chain: the base full, then each increment in order.
# level 0 (full)
tar --listed-incremental=/var/lib/snap.snar -czf full.tar.gz /srv/data
# level 1+ (only changes since the snapshot)
tar --listed-incremental=/var/lib/snap.snar -czf incr-1.tar.gz /srv/data
# restore: base first, then every increment, in order
tar --listed-incremental=/dev/null -xzf full.tar.gz -C /
tar --listed-incremental=/dev/null -xzf incr-1.tar.gz -C /What xbackupman automates
Toggle 'Incremental backups' on a server schedule and pick how often a fresh full runs. The snapshot file lives on persistent storage and only advances after the backup is safely recorded — a failed upload never desynchronizes the chain; the next run simply re-ships the same delta. If the remote tar isn't GNU, the run quietly falls back to a full instead of failing.
Chains are only as good as their weakest link
Deleting one middle increment breaks every restore after it. Two protections run automatically: retention only ever deletes whole chains once the entire chain has aged out, and a daily chain-verify pass confirms every link still exists in storage — a broken chain surfaces as a failed-verification badge the next morning, not on restore day.