Automated, Encrypted Off-Site Backups with Borg and restic

When we set up backups for clients, two tools come up again and again: BorgBackup and restic. Both give you encrypted, deduplicated, incremental backups that are efficient to store and quick to restore. Here’s why we like them and how the pieces fit together.

What makes them good

• Encryption by default — your data is encrypted before it leaves the server, so the destination never sees plaintext
• Deduplication — only changed blocks are stored, so repeated backups are small and fast
• Incremental forever — no slow weekly “full” backups; every run is incremental yet restorable as a complete snapshot
• Many destinations — local disk, SSH targets and object storage are all supported

The shape of a good backup job

A solid setup has four ingredients: a scheduled job, a retention policy, an off-site destination and monitoring. Conceptually:

# Create an encrypted snapshot of your important paths
borg create --stats repo::'{hostname}-{now}' /etc /var/www /home

# Prune to a sensible retention policy
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 repo

# Verify the repository's integrity
borg check repo

The detail everyone forgets

Two things separate a real backup system from a false sense of security:

1. Off-site, encrypted storage — a backup sitting on the same server (or in the same building) won’t survive ransomware, theft or fire.
2. Restore testing — schedule regular test restores and verify the data actually comes back. An untested backup is a guess.

Don’t forget monitoring

Backups fail silently. Wire each job into your monitoring so a missed or failed run raises an alert, rather than being discovered the day you need to restore. Set it up once, verify it works, and check on it regularly — that’s the whole game.

---

#borgbackup #encrypted backups #linux how-to #restic