(312) 313-3883 Order a server

Backups that actually restore

Setting up encrypted, offsite, versioned backups with restic, and testing restores so you know they work.

Updated October 28, 2026

A backup plan is three questions: where are the copies, how far back can you go, and when did you last restore one. This guide uses restic, which encrypts and deduplicates on the server before anything leaves it.

The rule to aim for

Three copies of the data, on two kinds of storage, one of them offsite. On a single dedicated server that usually means: the live data, a local snapshot or dump, and an encrypted copy in object storage in another facility.

Set up restic

apt install -y restic        # or: dnf install -y restic (EPEL)

# repository settings, readable by root only
install -m 600 /dev/null /root/.restic-env
# put these four lines in /root/.restic-env:
#   export RESTIC_REPOSITORY=s3:https://OBJECT_STORAGE_ENDPOINT/BUCKET/web1
#   export RESTIC_PASSWORD_FILE=/root/.restic-pass
#   export AWS_ACCESS_KEY_ID=...
#   export AWS_SECRET_ACCESS_KEY=...
openssl rand -base64 32 > /root/.restic-pass && chmod 600 /root/.restic-pass
. /root/.restic-env && restic init

Store a copy of the repository password somewhere other than the server. Without it the backups cannot be read by anyone, including you.

Back up files and databases nightly

#!/bin/sh
# /usr/local/sbin/nightly-backup
set -eu
. /root/.restic-env
mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql.sql.gz
restic backup /etc /var/www /var/backups --exclude-caches
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 6 --prune

Run it from a systemd timer or cron at a quiet hour, and send its exit status to your monitoring so a failed night gets noticed.

Test a restore

. /root/.restic-env
restic snapshots
restic restore latest --target /tmp/restore-test --include /var/www/example.com
diff -r /var/www/example.com /tmp/restore-test/var/www/example.com | head

Do this on a schedule, at least quarterly, and also restore a database dump into a scratch database. A restore you have never tried is the most common way backups fail.

What not to rely on