·2 min read
A backup you've never restored isn't a backup yet
Having a nightly backup file isn't enough. What matters is whether you can restore when something breaks, how long it takes, and how much data you lose.
Ask the people running a system whether they have backups and the answer is usually "yes". A cron job runs at 2 a.m., dumps the database and pushes it somewhere. The harder question is: when did anyone last restore from that file?
If the answer is "never", what you have is an assumption.
How backups fail quietly
Backups rarely fail loudly. More often:
- The job still runs, but the file is empty or truncated. The disk filled up, a timeout hit, or the database password changed.
- Only the database is backed up, not user uploads, so the invoices, photos and contracts in
uploads/are missing. - The backup lives on the same server as the data. A dead disk or ransomware takes both.
- Nobody knows the restore procedure. The person who wrote the script has left, and the restore command was never written down.
- Versions don't match. A dump from an older MySQL won't load into a newer one without edits.
Two numbers to know before an incident
RPO (Recovery Point Objective): how much data can you afford to lose? A nightly backup means losing up to a day of orders. For many businesses that's acceptable; for some it isn't.
RTO (Recovery Time Objective): how long can you afford to be down? Restoring a database of tens of gigabytes, reconfiguring the app and checking the data all take real time. Only a test tells you whether it's 30 minutes or a full day.
The business sets these numbers, not the engineer. The engineer's job is to measure what the current setup actually achieves, so the decision-maker has something to go on.
A minimal restore test
It doesn't need to be elaborate. Every month or quarter:
- Take the latest backup from the real storage location (not a copy on someone's laptop).
- Restore it into an isolated environment, such as a temporary VPS or a container.
- Point the application at it, log in, open a few critical screens.
- Write down how long it took and how recent the newest data is.
- Update the restore documentation wherever a step required guessing.
If you can do those 5 steps without calling the person who wrote the original script, you have a real backup.
When to bring in someone else
If you're not sure whether backups are running, where they live or how to restore them, check now, before an incident. When I do a Health Check, backups and restores are among the first things I look at.
Sound like your system?
A 2–4 day Health Check tells you what to fix first and what can wait.