Almost every business we assess has backups. Far fewer have restores.
The distinction matters more than it sounds. A backup job that reports success is telling you it finished writing a file. It is not telling you the file is complete, that it is readable, that it contains the databases you assumed it contained, or that anyone in your organisation knows how to turn it back into a working system.
The failure modes we see most
- The silent exclusion. A folder was added years after the backup job was configured and nobody updated the job. It has never been backed up.
- The open database. The file was copied while the database was mid-write. It backs up fine and restores to a corrupt state.
- The single copy on the same site. Fine for a failed drive. Useless for a fire, a flood or a theft.
- The credentials nobody has. The backup is intact, and the only person who could access it left the company in March.
- The ransomware case. The backup drive was permanently mounted, so the malware encrypted it too.
What to do about it
The old three-two-one rule still holds: three copies of the data, on two kinds of media, with one off-site. Add a fourth condition for the ransomware era: at least one copy must be offline or immutable, so a compromised machine cannot reach it.
Then test it. Pick a date, restore to a spare machine, and confirm the system actually runs. Write down how long it took and who did it. That number is your real recovery time, and it is almost always longer than people expect.
Do this quarterly. It is the cheapest piece of resilience work available to most businesses.