A box ticked years ago
Ask whether you have backups and someone will say yes. The hosting company does them, or there is a plugin, or the developer set up a script. Ask when anyone last restored one and the room goes quiet. Ask what exactly is backed up (the database, the uploaded files, the configuration, the email) and nobody is quite sure.
That is a common place to be, and it feels fine until the day a database is corrupted, a server fails, a staff member deletes the wrong folder, or ransomware encrypts everything it can reach.
Why backups fail when you need them
| Failure | How it happens |
|---|---|
| Backup job stopped | A password changed or disk filled, and nobody saw the error |
| Incomplete backup | The database is copied but the uploaded files or config are not |
| Same place as the original | Backups stored on the same server or account are lost with it |
| Encrypted by ransomware | Backups reachable from the network get encrypted too |
| Cannot be restored | Nobody knows the steps, or the format needs software you no longer have |
| Too old | Retention was set so short that the clean copy has already been overwritten |
The common thread is that nobody tested. A restore is the only real test of a backup, and it is the step almost everyone skips.
What an untested backup puts at risk
There is also a contractual and regulatory side. If you hold customer data, losing it may need to be reported, and customers or insurers may ask how your backups are tested. Saying that you assumed the hosting company had it covered is not a comfortable answer.
Everything the business cannot recreate: customer records, orders, invoices, documents, the website content. The cost of losing it ranges from days of re-keying to losing things that cannot be recovered at all. And when it happens, the pressure to restore quickly is the worst possible moment to be working out how.
How we set up backups you can trust
- List what needs protecting: databases, file storage, server configuration, code, cloud settings, and SaaS data such as Microsoft 365 or Google Workspace where appropriate.
- Agree two numbers with you for each system: how much recent data you could afford to lose, and how long you could manage without it. These decide how often backups run and how they are stored.
- Automate the backups using the right tool for each system, for example managed database backups on AWS or Azure, file-level backups, and point-in-time recovery where it matters.
- Store copies separately. At least one copy sits in a different account or location from the live system, with protection against deletion or change (immutable or versioned storage).
- Monitor the backup jobs, so a failed or unusually small backup raises an alert to a named person.
- Test restores regularly into a clean environment, check the restored data is complete, and time how long it took.
- Write the restore procedure down step by step, so someone other than its author can follow it under pressure.
What you have afterwards
You know what is backed up, where, how often and how far back. You know a restore works because one was done recently and written up. If something goes wrong, there is a procedure to follow rather than a search for the person who set it up. And if a backup stops working, someone hears about it the same day, not on the day it is needed.
Checklist
- Nobody can remember the last time a backup was restored.
- You are not sure whether uploaded files and configuration are included.
- Backups are stored on the same server or in the same account as the live system.
- Backup failures would not trigger an alert to anyone.
- There is no written restore procedure.