Open source backup software

Backup is the discipline the rest of the noteset keeps gesturing at: High Availability says “single doombox means backups + reprovision speed are the HA strategy”; Embedded databases reminds that in-process data dies with the process. The tool landscape splits along what gets backed up and how the restore works — file-level vs database-aware vs full client-server fleet.

The axes that actually separate the tools:

• Deduplication model — content-addressed chunking (restic, borg, wal-g: incremental forever, space proportional to unique data) vs snapshot/hardlink trees (rsnapshot: space proportional to changed files, full filesystem views) vs tape-lineage catalog (Bareos: server tracks everything, clients run agents)
• Encryption — authenticated encryption built in (restic, borg) vs transport/none by default (rsnapshot) vs server-managed (Bareos)
• Verification — borg’s check (cryptographic integrity of the whole repo) and restic’s check vs rsnapshot’s implicit trust in the filesystem; the unspoken rule: a backup without a tested restore is a rumor
• Client/server vs single-host — Bareos is a fleet product (director + storage daemon + file daemons, cross-network, catalogs in PostgreSQL/SQLite); the rest are single-host tools you orchestrate yourself

The field (all captured)

• restic (OSS) (36.4k★, Go, BSD-2) — the modern default: content-defined chunking, snapshot-based, authenticated encryption, dedup across snapshots; backends pluggable (S3, B2, rest-server, rclone). The “fast, secure, efficient” triangle done right; the price is a restic-specific repo format (no plain filesystem browsing) and historically memory-hungry pruning.
• borg (OSS) (13.8k★, Python+C, BSD-3) — restic’s older sibling: same dedup+encryption ideas, mature and battle-tested, mountable FUSE archives, borg check integrity verification. SSH-native remotes. The known trade: one writer per repo, and single-threaded until the 2.0 saga.
• borgmatic (OSS) (Python, GPL-3) — the config-driven wrapper that makes borg a system service: YAML pipelines for create/prune/check/compact, hooks (pre/post, per-repository), monitoring integrations, borgmatic --restore interactive picker. The “full-featured side” of the KRZ full+KISS script convention, pre-built.
• rsnapshot (OSS) (3.7k★, Perl, GPL-2) — the elder: rsync + hardlinked snapshot trees (hourly.0 … daily.6 …), each snapshot is a full browsable filesystem. No encryption, no dedup beyond hardlinks — but a snapshot restores with cp -a, no tool needed at restore time. Still the KISS answer for LAN-only backup to a fileserver.
• bareos (OSS) (1.3k★, C++, AGPLv3) — the Bacula lineage, alive: cross-network client/server backup (director, storage daemon, file daemons per OS), catalog in PostgreSQL/SQLite, tape/virtual-tape-silo support, jobs/schedules/retention pools. The enterprise-shape answer when “backup” means “fleet policy,” not “my scripts.” Heavy: this is a system you run, not a binary you call.
• wal-g (OSS) (4.3k★, Go, Apache-2) — the database-aware one: archival/restoration for Postgres/MySQL/MS SQL — WAL streaming + incremental base backups straight to object storage (S3/GCS/Azure), delta restores, and the point-in-time recovery that file-level tools structurally cannot give a live database. (Via @GithubProjects — clippings/x-2106648013129372145.md.)

The honest selection ladder

1. Files on one/few machines → object storage or another box: restic (or borg+borgmatic if you want YAML pipelines and FUSE mounts). Encrypt by default; verify with check on a schedule.
2. Files on a LAN where the destination is a fileserver: rsnapshot still wins on simplicity — every snapshot is plain files.
3. Databases: wal-g (or the engine’s own tooling — the cloudnative-pg (OSS) operator barreled physical backups to S3 into its reconcile loop). Never file-copy a live database.
4. A fleet with policies, tapes, and auditors: Bareos.

The KRZ homelab read: restic/borg for the hosts, wal-g-shaped tooling when the databases arrive, Bareos overkill at this scale — and every tier needs the restore test (Do-nothing scripting is the right shape for it: a do-nothing restore script whose steps become restore → diff → report over time).

Related: High Availability (what backups substitute for at homelab scale) · Do-nothing scripting (restore drills) · Kubernetes Operators (backup as reconciliation, cloudnative-pg style) · Embedded databases (the data worth backing up)