Having backups isn't the same as being able to restore them. A practical routine for setting recovery targets, keeping an offline copy and testing restores on a schedule.
Most organisations have backups. Far fewer have proof that those backups restore, in a reasonable time, to a working system. The difference only shows up on the worst day, which is the wrong time to find out.
Here’s a routine that turns “we have backups” into “we know we can recover”.
Agree how much you can lose, and for how long
Two numbers shape every backup decision:
- Recovery point objective (RPO): how much recent data you could afford to lose. If it’s one hour, you need backups at least hourly.
- Recovery time objective (RTO): how long the system can be down before it seriously hurts. If it’s four hours, restoring from a slow archive won’t do.
Agree these with the people who depend on the system, not just the IT team. They’re business decisions.
Keep more than one copy, in more than one place
A widely used rule of thumb is 3-2-1: three copies of your data, on two different types of storage, with one copy kept away from the main system.
Ransomware has made the “away” part more important. Attackers increasingly look for backups and encrypt or delete them too. The UK’s National Cyber Security Centre recommends keeping at least one backup offline or otherwise separated from your network, so it can’t be reached from a compromised account. Most cloud providers offer immutable or locked backups that can’t be changed or deleted for a set period, which serves the same purpose.
Test restores on a schedule
A backup you haven’t restored is a hope, not a plan. Put restore tests in the calendar:
- Restore to a separate environment, never over the live system.
- Check the result works: open the application, run a report, compare record counts.
- Time it, and compare the time against your recovery time objective.
- Write down what you did and anything that surprised you.
Monthly is a good rhythm for important systems. At the very least, test after any big change such as a migration or a new database version.
Write the runbook before you need it
When something goes wrong, people are under pressure and memory fails. A short runbook, saying where the backups are, who has access, the exact restore steps and who to tell, means anyone on the team can carry out a recovery. Keep a copy somewhere that doesn’t depend on the system it describes.
Watch for silent failures
Backup jobs fail quietly: a full disk, an expired password, a server that was moved. Make sure failures send an alert to someone who’ll act on it, and check the backup reports weekly rather than assuming no news is good news.
If you’d like an outside check of your backup and recovery setup, tell us what you have and we’ll test a restore with you.