Every hosting dashboard shows a green tick next to "Last backup: successful". That tick means a job ran and wrote something somewhere. It doesn't tell you whether you can get your business back after a bad deploy, a deleted table or a compromised server.
We've seen backups that were empty because the database user lost permissions, backups stored on the same disk as the server they protected, and backups that restored fine but took nine hours when the business could afford one. Each team found out during an incident.
Decide what "recovered" means
Before choosing tools, agree on two numbers with the business:
- How much data can you lose? If the answer is "an hour of orders", nightly backups aren't enough.
- How long can you be down? If the answer is "an afternoon", a restore process that takes a full day fails, however good the backup is.
These two numbers decide backup frequency, whether you need point-in-time recovery, and how much automation the restore needs.
Store copies away from the thing they protect
Our baseline:
- Automated daily database backups plus point-in-time recovery where the platform offers it
- A copy in a different account or provider, so one compromised set of credentials can't delete both
- File storage (uploads, documents) versioned, with deletes recoverable for at least 30 days
- Backups encrypted, with the keys stored separately
The separate account matters. Ransomware and angry insiders both go for the backups first.
The restore drill
Once a quarter, for every system we look after, someone restores the latest backup into a fresh environment and checks:
- The restore completes, and we write down how long it took.
- The app starts and connects to the restored data.
- Recent records exist. We look for orders or sign-ups from the day before the backup.
- File uploads referenced in the database open.
We log the result, the time taken and any step that needed manual work. If the restore took longer than the agreed downtime, fixing that becomes a ticket.
Write the runbook while it's calm
The drill produces a runbook: the exact commands, where the credentials live, who has access, and what to check afterwards. During a real incident nobody should be reading documentation for the first time. We keep the runbook next to the code and update it after every drill.
Small sites too
This isn't only for large systems. A WordPress site for a small business needs the same test at a smaller scale. Download last night's backup, restore it to a staging copy, and click around. It takes an hour and you'll know the answer before you need it.
