The setup
The second box runs restic’s REST server in append-only mode, so a compromised host can add snapshots but cannot delete old ones. Each host has its own repository and its own password, kept in my password manager and on paper.
restic -r rest:http://backup.lan:8000/host1 backup /etc /home /srv \
--exclude-caches --one-file-systemA systemd timer runs it at night. Pruning runs on the backup box itself, weekly, keeping seven daily, four weekly and twelve monthly snapshots.
The restore drill
Backups you have never restored are a hope, not a plan. I wiped a spare disk, installed the same Debian release, restored /etc and /srv, and started the services. The written steps are now in the repository next to the scripts.
restic beside the usual alternatives
The three tools I see most in home labs, compared on what decided it for me.
| restic | BorgBackup | rsync with hard links | |
|---|---|---|---|
| Licence | BSD 2-Clause | BSD 3-Clause | GPL 3 |
| Encryption | Always on | On by default; several modes | None; add it yourself |
| Deduplication | Yes, across all snapshots | Yes, across all archives | Unchanged files only, by hard link |
| Targets | Local disk, SFTP, S3-style storage, its own REST server | Local disk, SSH (Borg on the far side) | Local disk or SSH |
| Restore one file | restic restore or mount the repository | borg extract or mount the archive | Copy it back |
| Verdict | My pick: one binary, many targets | Just as good if both ends run Borg | Fine until you need encryption |
Licences checked against each project’s repository.
What I would change
The backup box sits in the same house. A second copy to cheap object storage, also with restic, is next on the list.