Every business we audit has backups. Most of them have never been restored. Those two facts sit together more comfortably than they should.
A backup is not a file. It is a promise that, on a bad day, you can get back to working. The only way to know whether the promise holds is to test it, and the only good time to test it is before you need it.
The ways backups quietly fail
- The job has been erroring for four months and the alert email goes to someone who left.
- The database dumps fine but the uploaded files were never included, so the records come back without their documents.
- The backups live on the same server as the thing being backed up. Ransomware encrypts both.
- Retention is seven days, and the corruption started three weeks ago.
- The archive restores, but nobody knows the sequence to bring the application back up around it.
What good looks like
- Three copies, two media, one off-site. The old rule still holds. Off-site means a different provider, not a different folder.
- Everything, not just the database. Uploads, configuration, environment variables, certificates, DNS records and the deployment definition.
- Retention that outlives the problem. Daily for a fortnight, weekly for three months, monthly for a year is a sensible default for most businesses.
- Encrypted, with the key stored separately. A backup you cannot decrypt and a backup you have lost are the same thing.
- Monitored on success, not failure. Alert when a backup has not completed, rather than hoping a failure email arrives.
The restore drill
Once a quarter, take the most recent backup, restore it to a clean environment, and open the application. Time it. Write down the steps as you go, because the person doing this during a real incident will not be thinking clearly.
At the end you will have two numbers: how much data you would lose, and how long you would be down. Those numbers are the only honest answer to “are we covered?” Everything else is a hope with a cron job attached.