Every company we assess has backups. Almost every one of them has a console showing green. A much smaller number can tell us when they last restored something from those backups on purpose.
That gap is where most recovery failures live. A backup job reports that data was copied. A restore reports whether the copy is usable, whether anyone knows how to use it, and how long it takes. Only the second question matters on the day.
This is a test you can run in an afternoon, without buying anything.
What the green tick actually means
A successful job means the software read some data and wrote it somewhere without an error it recognized. It does not mean the right data was included, that the copy can be opened, that the destination is still reachable, or that anyone holds the credentials needed to bring it back.
The failures we find are almost always in that gap rather than in the software. A new server was built and never added to the schedule. A database was backed up as files while it was running, so the copy is inconsistent. Someone rotated a service account and the job kept succeeding against a share that had stopped receiving anything new. A cloud application was assumed to be backed up by its vendor, and its vendor assumed the opposite.
None of those show up in the console. All of them show up in a restore.
The three questions a restore answers
Before you test anything, write down the answers you expect. The test is worth far more when it can disagree with you.
- How much work would we lose? The gap between the last usable copy and the moment of failure — your recovery point.
- How long until people can work again? Not until the data is back, but until the system is usable by the people who need it — your recovery time.
- Is the restored data actually correct? Whether the thing that comes back opens, reconciles, and is complete enough to trust.
Most companies have never stated a target for the first two. That is fine as a starting point: state one now, as a guess, and let the test tell you how far off it was. A stated target that turns out to be wrong is more useful than no target, because it converts an argument into a measurement.
The afternoon test
Pick a quiet afternoon. Tell the people who would notice. Then restore three things, in this order, from smallest to largest.
First, a single file from around thirty days ago — not yesterday. Recent copies are usually fine; the question is whether your retention actually holds what you think it holds. Restore it to a scratch location and open it.
Second, a mailbox, or a folder from your file-sharing platform, including something that was deleted. This is where assumptions about the vendor's own retention get tested. Many teams discover here that their idea of how far back they can go is shorter than they believed.
Third, and this is the one people skip, a whole system. A virtual machine, a database, or an application server, restored to an isolated network where it cannot talk to production. Bring it up. Log in. Run something real against it — a report, a query, a transaction you know the answer to.
Time the third test with a clock, not with an estimate. The estimate is always wrong in the same direction.
Have someone who is not the usual administrator do at least one of these, working from the documentation. If the only person who can restore your systems is the person who set them up, you have tested the backup and not the recovery.
What to write down afterward
The record is the deliverable. Without it, you did an exercise; with it, you have evidence, a baseline, and an argument you can take to a board or an insurer.
- Date, who ran it, and who observed it.
- What was restored, from which copy, and how old that copy was.
- Where it was restored to, and confirmation that it was isolated from production.
- Elapsed time for each restore, measured rather than estimated.
- Whether the data was verified, by whom, and how they checked it.
- What failed, what was missing, and what surprised you.
- The follow-up actions, each with an owner and a date.
Keep it to one page. A short record that gets written every quarter is worth more than a thorough one written once. Auditors ask for exactly this under most frameworks, and insurers increasingly ask for it too, so a page you already produce answers a question you would otherwise scramble to answer.
The part ransomware changed
Backups used to protect against hardware failure and human error, both of which are indifferent to where the copy is kept. Attackers are not. They look for the backup system, and they have time to find it, because access usually predates the encryption by a while.
So the test has a second half. Ask whether an administrator account compromised in your production environment could also delete or encrypt the backups. If the answer is yes, the copies are not a control against the failure most likely to need them. What breaks that link is separation: credentials that do not exist in the production directory, a copy the primary system cannot modify, and a destination that is not simply another share on the same network.
Test that assumption the same way you test the restore. Take the account you believe cannot reach the backups, and try to reach the backups with it.
How often to do this
Quarterly for a full system restore, and after any material change: a new critical application, a migration, a change of backup product, or a change of the person who runs it. File and mailbox restores can be more frequent because they are cheap, and in practice you get them for free — someone deletes something important often enough that the small tests run themselves, if you record them.
A first test usually fails in some way. That is the useful outcome, and it is the reason to do it on a scheduled afternoon rather than during an incident. The company that has restored a system on purpose knows what the day looks like. The company relying on a green console is guessing, and will find out how good the guess was at the worst possible moment.