Back to blog
Sooner or later it happens: an update that breaks the system, an rm -rf in the wrong folder, a vulnerable plugin that lets someone in, a service that expired. In every one of these cases, one thing makes the difference between a bad afternoon and a disaster: a backup that works.
The 3-2-1 rule
It is the simplest and most widely used backup rule:
- 3 copies of your data: the original plus two backups;
- on 2 different media or systems;
- with 1 off-site, away from the original server.
The last point is the important one. A backup on the same server as the data does not protect you if the server is deleted, compromised or no longer boots. And a backup that only lives in your provider's panel is convenient, but it is not independent.
Snapshots are not backups
Snapshots and panel backups are great for going back quickly, for example before a major update. But they live close to the server. For data you cannot afford to lose, you also need an external copy that you can check and restore on its own.
A concrete example: restic on a storage box
restic encrypts and deduplicates your backups, so it keeps many versions in little space. A storage box is reached over SFTP:
export RESTIC_REPOSITORY=sftp://<user>@<host>:<port>/backups/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /var/www /home
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
A few tips:
- databases: dump them first (
mysqldump,pg_dump) and back up the dump, rather than copying the files of a running database; - one sub-user per server: so a compromised server cannot read or delete the others' backups;
- scheduled snapshots on the box: they also protect you when the server itself deletes its own backups;
- keep the restic password off the server: without it, nobody can read the backups, not even us.
A backup you never tested does not exist
From time to time, restore a few files to a temporary folder and check them:
restic restore latest --target /tmp/restore-test
It is the only way to know the backup will really work on the day you need it. Automate everything with cron or a systemd timer and check the logs now and then: a backup that has been failing silently for three months is the worst kind.
