How this site’s backups are checked

A successful backup run tells you that a copy was made. Restoring it tells you whether you can use that copy to recover. Both checks are needed.

Know what needs to come back

For this site, the database holds accounts and discussions, while object storage holds uploaded files. The application configuration is another part of recovery. Keeping just the website code would not bring back the community’s data.

Restore somewhere separate

Use a scratch database or an isolated test service so the check cannot overwrite the running site. Restore the saved data, check representative records and try retrieving an uploaded file.

A row count can reveal an empty or incomplete restore, but it is only one check. The recovered application must also be able to use the data.

Check the things outside the backup

You need access to encryption keys, credentials and the instructions for restoring. Keep those available through an appropriate secure route if the original server is unavailable. An off-site copy helps when a local disk or the whole machine fails.

Make it repeatable

Record when a backup and restore were last checked, what was restored and whether anything failed. Schedule backups and failure notifications, and repeat restore checks after important changes.

To practise on a small dataset, follow Back up and restore files with restic or Back up and restore a PostgreSQL database.