Does your backup restore? Only a restore test can say
A backup is a copy. Recovery is a capability, and it only exists once it has been tested. Until someone has restored the copy into a clean environment, timed the process and checked the result, your company has an assumption, not a plan. The restore test is what turns one into the other.
Why is having a backup not the same as being able to recover?
Because a copy proves only one thing: a file was written somewhere. It does not prove the file opens, that it is complete, that it holds everything the operation needs, or that anyone knows what to do with it at three in the afternoon on a Tuesday with the system down.
The failure modes are mundane. The job stopped running and nobody was told. The copy sat on the same server that failed. The encryption key was held by someone who left the company. The dashboard that says "backup completed" cannot see any of these, because it measures whether the copy was made, not whether it works.
The copy itself is infrastructure, and there are good manuals for it. What changes the outcome is the decision that comes first: what must be in the copy, how long the company can afford to wait, and who checks that the result is right.
What do the standards ask for beyond the copy?
They ask for evidence. CISA's guide recommends keeping backups offline and encrypted and regularly testing their availability and integrity in a disaster recovery scenario. The reason it gives is that many ransomware variants look for accessible backups to delete or encrypt.
NIST's contingency planning guide (SP 800-34) separates three activities: testing, training and exercises. Testing validates recovery capability. Exercises expose gaps in the plan. The document also treats checking backup media as routine, so that files are retrieved without errors or lost data.
Neither text names a tool. Both require that someone has actually restored. A practical consequence: a policy that says "we keep backups" is not evidence, and neither is a vendor report that says the job succeeded. The evidence is a restore someone timed and checked.
Which signals look like proof and are not?
Three are common. The first is the success message, which confirms the job ran. The second is the written policy, which confirms intent. The third is the confidence of the team, which is sincere and untested. Each is useful and none replaces the restore.
Confidence deserves a particular warning. The people who set up the backup are the people least likely to find its gaps, because they know what they meant to include. A restore performed by someone who needs the result, such as the person who closes the month or dispatches the crews, finds the gaps faster.
Which decisions does a restore test force?
Three, and none of them is technical.
The first is which system is the source of truth for each piece of data. If prices live in a spreadsheet, customer records in the ERP and order status in a chat thread, the ERP copy restores a third of the operation. The test shows what was left out because nobody had decided where that data lives. It is the same root as migrating off spreadsheets without stopping operations: until critical data has a defined home, no backup routine reaches it.
The second is how much data and how much time the operation can afford to lose. Contingency planning literature calls these the recovery point objective (RPO) and the recovery time objective (RTO). In plain words: up to what hour of the day must records come back, and within how many hours must the system be running. The operation's owner answers this, not the infrastructure supplier.
The third is the order of return. Invoicing depends on the customer master, which depends on the database, which depends on an access that only one person holds. Without a rehearsal, that chain shows up in the middle of the incident.
At Colo Saúde, Yowpi began with an audit because nobody could say what the real security state of the platform was. The pattern is the same: what was not verified has no owner, and what has no owner surfaces at the worst moment.
What does this look like in a mid-sized company?
Picture, as a hypothesis, an industrial maintenance company with 40 people. The ERP holds the work orders. The crew schedule sits in a spreadsheet kept by the coordinator on his laptop. The ERP backup runs at two in the morning and the panel shows success every day.
On a Tuesday at three in the afternoon, the ERP server fails. The numbers that follow are illustrative, not a measurement. The latest copy is 13 hours old, so every work order opened or closed since the small hours disappears. The restore, which everyone expected to take an hour, takes six because nobody knows the database password. And the crew schedule was never in the copy, so dispatching the next day becomes a phone call to each technician.
None of this is a technology failure. The copy did exactly what it was configured to do. Three decisions were missing, and the test would have forced them: whether the spreadsheet is in scope or stops existing, whether a 13-hour gap is acceptable, and whether the database password has more than one holder. A monthly inspection of internal systems already asks for a recent restore. The restore test shows what that restore reveals.
How do you run a first test without stopping operations?
Pick one system, preferably the one whose stoppage halts invoicing. Restore the latest copy into a separate environment, never over production, and time it from start to finish, including the time spent finding passwords and keys.
Ask the people who run the system to check a few recent records and one closed report. The question is simple: is this right? Write down three things: how long it took, how old the freshest restored data was and what was missing. Name an owner and a date for the next test. The first result can be uncomfortable, and that is what it is for.
Frequently asked questions
We have no IT specialist. Can we still test?
Yes. The technical part can sit with whoever maintains the system, in-house or external. What the company cannot delegate is the definition of "right": only the people who know the operation can say whether the restored report matches reality. The first test needs more business knowledge than infrastructure knowledge.
Is it worth the effort if we have never had an incident?
Without a past incident, the company has no way to know the size of the loss it would face. The test is how you find out without waiting for the incident. It costs a few hours of someone who knows the operation and a separate environment for the restore. Whether avoiding the surprise is worth that is your call, and the test is what supplies the numbers for it.
Our data sits in several systems and spreadsheets. Where do we start?
With the system whose stoppage halts invoicing. The test will surface dependencies that were off the map, and that map is already the first gain. Then repeat with the next system on the list. If the map shows that critical data lives in places no routine reaches, the conversation stops being about backups and becomes about where each piece of data should live.
The next step
If the test shows that your operation depends on data no system controls, the Operational Architecture Diagnostic, a 30-minute conversation, is the place to map it: talk to Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic