Almost every organisation we assess has a backup running somewhere. Far fewer have ever restored from one. Those are not the same thing, and the gap between them is where most of the bad days we get called into actually live.
A backup job that reports success is telling you that it finished writing. It is not telling you that the files it wrote can be opened, that the database inside them is consistent, that the encryption key still exists, or that anyone knows how to put the result back on a machine at eight in the morning with the phone ringing.
The twenty-minute version
You do not need a formal disaster-recovery exercise to learn most of what matters. Pick one file that changed last week and restore it to a scratch folder. Time it. Note every password, portal and person you needed along the way.
- If it took longer than you expected, that is your real recovery time – the rehearsed version is always faster than the first attempt.
- If you needed a credential nobody else has, your recovery plan currently depends on one person being reachable.
- If you could not find the backup at all, you have answered the question.
What we look for
When we take on a managed client, backup is one of the first things assessed and one of the few things we test rather than take on trust. That means confirming there is a copy somewhere the ransomware cannot reach, that a restore has been performed end to end at least once, and that the steps are written down somewhere other than in somebody’s head.
None of that is exotic and none of it is expensive. It is simply the difference between a backup that is a line item and a backup that is an answer. If you are not sure which one you have, ask us to look — the assessment is free, and we would rather tell you it is fine than meet you on the day it is not.