Every organisation we assess has backups. Far fewer can tell us when they last restored from one. That gap is where most recovery failures live.
A backup job that reports success proves the job ran. It does not prove the data is complete, that the restore path works, or that anyone still working at the company knows how to run it.
What actually goes wrong
The failures we see repeat in a small number of ways:
- The backup was incomplete. A database was being written to during the job, or a critical share was never added to the scope after a migration.
- The restore takes longer than the business can survive. Nobody had defined an acceptable recovery time, so nobody noticed a full restore would take four days.
- The backups were reachable from the compromised network. Ransomware encrypted them along with everything else.
- The person who set it up has left. The process was never documented.
None of these are exotic. All of them are discovered during the incident, which is the most expensive possible time to find out.
Define the objectives before the tooling
Two numbers should drive the entire strategy, and both are business decisions rather than technical ones:
Recovery time objective. How long can this system be unavailable before the impact becomes unacceptable? Answer it per system, not for the organisation as a whole. Payroll and a marketing site do not need the same answer.
Recovery point objective. How much data can you afford to lose? An hour of transactions is very different from a day of them.
Once those exist, the tooling question mostly answers itself.
Test the restore, on a schedule
Recovery testing should be routine, not exceptional. At minimum:
- Restore a representative file set quarterly, and time it.
- Restore a full system annually into an isolated environment.
- Record who performed it, how long it took, and what went wrong.
- Fix what went wrong and note it for the next test.
The last two steps are the ones most often skipped, and they are where the value is. A test that surfaces no problems and produces no notes has usually not been run seriously.
Keep one copy out of reach
Ransomware operators look for backups specifically. At least one copy should be offline, immutable, or in an account with separate credentials from your production environment. If a single compromised administrator account can reach both, you have one copy of your data, not two.
Where to start
If you are not sure where you stand, the fastest useful exercise is to pick your single most important system and attempt a restore this month. Time it. Whatever you learn will be more informative than any amount of reviewing the backup console.
We can run that exercise with you as part of a backup and recovery engagement, or as part of a broader business continuity review.