Nearly every organisation we audit has backups running. A much smaller number can tell us how long a full restore takes, who performs it, or when it was last proven. That gap is the actual risk.
Backup software is good now. Jobs mostly succeed, and when they fail they usually say so. The failures that hurt are the ones where the job succeeded and the data still could not be used — wrong scope, unreadable target, missing encryption key, or a restore that would have taken four days.
Start with two numbers, honestly
Before any technology discussion, the business needs to answer two questions per system, and the answers should be uncomfortable:
- RPO — how much data can we afford to lose? If backups run nightly at 1am and the server dies at 5pm, you have lost a working day of entries. Is that survivable?
- RTO — how long can we be down? Measured from the failure, not from when someone gets round to starting the restore.
These are business decisions, not IT ones. The role of IT is to price each answer and let the business choose. "As soon as possible" is not an RTO — it is a way of avoiding the conversation.
An untested restore is a plan with an assumption in it. The assumption is the part that fails.
What a real restore test looks like
Opening a backup file and confirming it mounts is a file check, not a restore test. A restore test answers: can a named person, following written steps, bring a working system back inside the agreed RTO?
- Pick a system and restore it to isolated infrastructure — not over the live copy
- Start the service, log in, and have someone from the business confirm the data looks right
- Record the wall-clock time from start to usable, including the parts that are waiting
- Note everything that was not in the documentation and had to be worked out
- Update the runbook while it is fresh, then schedule the next test
Step four is where the value is. The first test of any environment finds missing credentials, an undocumented licence key, or a dependency nobody remembered.
Ransomware changed the requirements
Traditional backup design assumed hardware failure or human error. Neither of those goes looking for the backup server. Ransomware does, and it usually gets there first because the backup system is trusted on the network.
- Immutability — copies that cannot be modified or deleted for a defined retention period, whatever credentials the attacker has
- Separation — at least one copy that is not reachable using production credentials
- Retention depth — enough history to go back past the point of compromise, which is often weeks before detection
- Monitoring of the backup system itself — a quietly disabled job is a common precursor to an incident
Write it down where someone else can find it
The person who built the backup design is frequently not the person who will run the restore. It may be a colleague at 3am, or a different supplier entirely. The runbook needs to stand on its own:
- Which systems are protected, at what frequency, with what retention
- Where each copy physically lives, and how to reach it
- Credentials and encryption keys — stored somewhere that survives the outage
- Restore order, because systems have dependencies and some must come back first
- Who is authorised to declare an incident and start the process
A reasonable cadence
For most mid-sized estates: verify job success weekly, restore a single file or mailbox monthly, do a full system restore test quarterly, and run a tabletop walk through of the full scenario once a year with the business in the room.
That is not a large amount of work. It is considerably less than the week you will spend finding out the hard way.
