Backups that actually restore: 3-2-1 in practice

The 3-2-1 rule without pedantry

Three copies of the data, on two different media, one off-site. In practice for a VPS this means: live data on the server, an encrypted backup in S3-compatible storage at a different provider — done. A backup on the same server (or at the same provider in the same DC) is not a copy, it’s an illusion: lose the account and you lose everything.

restic: encryption and deduplication out of the box

restic encrypts everything client-side, stores snapshots incrementally and speaks any S3. A single binary, no daemons.

$ export RESTIC_REPOSITORY=s3:s3.storage.example.com/backup-bucket
$ export RESTIC_PASSWORD_FILE=/root/.restic-pass
$ restic init                        # once
$ restic backup /srv/app/data /etc \
    --exclude='*.tmp'
$ restic forget --keep-daily 7 --keep-weekly 4 \
    --keep-monthly 6 --prune

Don’t copy live database files — dump first, back up the dump:

$ docker exec db pg_dump -U app -Fc app > /srv/backup/app.dump
$ restic backup /srv/backup

A backup doesn’t exist until it’s been restored

The step everyone skips: restores must be rehearsed. Not “someday, when it burns”, but on a schedule. The minimum — a weekly restic check --read-data-subset plus restoring the dump into a temporary database and checking that it opens.

# in cron, weekly:
restic check --read-data-subset=10%
restic restore latest --target /tmp/restore-test \
    --include /srv/backup/app.dump
pg_restore --list /tmp/restore-test/srv/backup/app.dump

Checklist