A backup you have not restored is a hope, not a plan
Backup jobs report success for years while quietly protecting the wrong things. The only test that counts is putting the data back, timed, in front of someone who cares how long it took.
Backup is the control businesses are most confident about and least able to evidence. The job runs nightly, the dashboard is green, and nobody has restored anything more than a deleted file since the system went in.
Green means the job completed. It does not mean the data is recoverable, that it covers what matters now rather than what mattered when it was configured, or that you can be operational again inside a timeframe the business could survive.
The four ways a green backup fails you
It is protecting the 2021 estate. Backups get configured once, against the servers and shares that existed then. Since then the business moved a critical process into a SaaS product, someone stood up a new database, and the line of business application changed vendors. None of that got added, and nothing complained, because a backup job cannot know what you forgot to tell it about.
The restore takes longer than the business can wait. This is the most common one and the least discussed. Recovery from cold storage across a rural connection, for a dataset that has grown fivefold since anyone measured, can be days. If the business can tolerate four hours, then a working backup with a three-day restore is a failed control that reports success.
It is reachable from the thing that will encrypt it. A backup on a share the domain admin can write to is a backup ransomware can delete. Immutability and a copy that is genuinely out of reach are not luxuries; they are the difference between an outage and an extinction event.
Nobody knows the order. Even with good data, recovery is a sequence: identity first, then the application, then the integrations, then the reporting. Working that out during the incident, from memory, at 2am, is where the hours go.
The test that actually settles it
Pick your most business-critical system. Restore it, to somewhere isolated, and time it. Write down the number.
Then ask the business, in plain terms, whether that number is survivable. Not the IT team. The person whose revenue stops.
That conversation is short and it changes budgets, because it converts an abstract technical control into a specific answer: we would be down for eleven hours, and we would lose everything since 9pm last night. Both of those are decisions the business should be making knowingly rather than discovering.
What good looks like
- Two numbers, agreed with the business. How much data you can afford to lose, and how long you can afford to be down. Every technical choice follows from those, and without them you are guessing at spend.
- Scope reviewed on a schedule. Whenever a system is added, someone asks whether it is backed up. This is a five-minute question that prevents the worst-case discovery.
- One copy out of reach. Different credentials, immutable or offline, unreachable from the production environment.
- A tested restore, with a date on it. Not a claim. A record, because this is also the single most useful piece of evidence you can hand an insurer or a customer asking about recovery.
- A written order of recovery. Boring, short, and worth more than any product at the moment it is needed.
The uncomfortable question
When did you last restore something significant, and how long did it take?
If the answer is a shrug, that is not a criticism of anyone. It is simply the honest state of the control, and it is much cheaper to find out on a Tuesday afternoon than during the incident.