Glossary
Restore testing
Regularly restoring backups to prove they work, rather than trusting that backup jobs report success.
Also called Backup verification.
In plain terms
A backup you’ve never restored is a hope, not a plan. Jobs fail quietly, files are empty, permissions are wrong, and nobody finds out until the day they’re needed.
The fix is boring and effective: restore on a schedule, into a real environment, and check that the data is there and usable.
See what happens without it
The failure pattern this protects against, destructive operation without verified recovery, played out step by step.
Scroll the diagram sideways to see every system.
The backups were never tested, and they are empty.
What goes wrong:
- A cleanup job is supposed to delete the old staging database.
- A wrong variable points it at production instead.
- The team reaches for the backups.
- The backups were never tested, and they are empty.
With the safeguard:
- A cleanup job is supposed to delete the old staging database.
- Production has deletion protection, and the target must be confirmed by name.
- Backups are restored automatically every week to prove they work.
- Even a real mistake is recoverable in minutes.
When it mattered
In 2017 an engineer accidentally deleted a production database directory at GitLab. Five backup and replication methods turned out not to work, and about six and a half hours of data were lost.