There is a particular conversation I have had more times than I would like. Something has gone badly wrong, everyone is calm and professional, and someone says the reassuring sentence: "it is fine, we have backups". And they genuinely do. There is a backup server, it runs nightly, the dashboard is green.
Then you ask the second question. Where is the other copy? And the room goes quiet.
This is not a story about negligence. The businesses I am describing invested real money in backup. They bought the appliance, they pay the licence, someone checks it. What they bought was a backup, and what they needed was a recovery, and those are not the same purchase.
Why one copy fails exactly when you need it
A single backup copy protects you against a narrow set of problems: someone deletes a file, a disk dies, a database gets corrupted on a Tuesday. Those are real and they happen, and one copy handles them beautifully.
It does not protect you against the events that actually take businesses off the air. A fire or a flood in the room where both the server and its backup live. A ransomware operator who has been inside your network quietly for a fortnight and who knows perfectly well where the backups are, because finding and destroying them is the entire job before the encryption starts. A hardware failure in the backup appliance itself, discovered at the worst possible moment.
Modern attackers do not race you to encrypt. They take their time, they look around, and they go after the recovery path first, because a business that can restore does not pay. If your only copy is reachable from the network that just got compromised, you should assume it is part of the incident, not the answer to it.
A backup you can reach from the compromised network is not a lifeboat. It is another room on the same ship.
The three questions
You do not need to become a storage expert to know where you stand. Three questions, asked of whoever looks after your IT, will tell you almost everything.
1. Where does the second copy live?
Not the second schedule, the second copy. A different building, a different provider, somewhere that a bad night at your main site cannot touch. If the answer involves the same rack, the same room, or the same set of credentials as production, you have one copy with extra steps.
The simple version: if a single flood, fire or intruder can reach both copies, you have one.
2. Is it encrypted, and who holds the keys?
Your backups contain everything: payroll, client records, contracts, the lot. A copy sitting somewhere else is a copy sitting somewhere else, and it deserves the same protection as the live system. Encrypted at rest, encrypted in transit, and the credentials that can delete it held separately from the everyday administrator account.
That last part matters more than it sounds. If the account that runs your business day to day can also wipe your backups, then one compromised login removes both your data and your recovery in a single move.
The simple version: the keys to the backups should not sit in the same pocket as the keys to production.
3. When did someone last restore from it?
This is the question, and it is the one almost nobody can answer with a date. A green dashboard tells you a job completed. It does not tell you the data inside is usable, that the restore path still works after last quarter's upgrade, or how many hours the whole process takes with everyone watching.
I have seen backups that ran faithfully for a year and could not be restored, because a change made months earlier quietly broke the chain and nothing ever tested it. The job kept reporting success. It was reporting that it had finished, which is not the same as reporting that it had worked.
The simple version: a backup nobody has restored from is a theory, not a plan.
What good actually looks like
The standard we hold ourselves to is deliberately blunt. A backup counts when it is in more than one place, encrypted, and someone has restored from it recently enough to say so with a date. Miss any of the three and you have something, but you do not have a recovery.
Alongside that, two numbers are worth agreeing out loud with your leadership team rather than leaving to whoever configured the software. How much data can you afford to lose, measured in hours. And how long can you be down before the damage stops being an inconvenience and starts being a real commercial problem. Those two answers should drive the backup design. In most businesses I look at, the design came first and nobody ever checked it against the answers.
None of this is exotic and none of it is expensive compared with the alternative. I have written before about the true cost of an IT emergency, and the bill that arrives afterwards is never just the downtime. The single biggest thing that separates a bad week from an existential one is whether the recovery was real.
The honest summary
If you take one thing from this, make it the third question. Ask your provider, or your internal team, when they last performed a genuine restore and what it proved. A confident, specific answer with a date on it means you are in good shape. Hesitation is not a scandal, but it is information, and it is worth acting on this month rather than next year.
If you want an outside view, our security and resilience assessment covers exactly this ground, and we will tell you the truth about what we find. You can also read more about how we approach backup and continuity.
