Your backup is useless if you've never tested a restore

Green ticks in a backup console tell you a job finished. They tell you nothing about whether the data is usable.

Every business that has been hit by ransomware and paid a ransom had backups. That is the uncomfortable part. They weren't negligent. They had a backup product, it ran nightly, and the dashboard was green.

What they didn't have was proof that a restore would work when it mattered.

What a green tick actually means

A successful backup job means data was read from a source and written to a destination without an error the software noticed. That is genuinely useful information. It is also a much narrower claim than most people hear.

It does not confirm the backup contains everything you need. It does not confirm the files inside are intact and openable. It does not confirm the application they belong to will start once restored. And it certainly does not confirm you can complete a restore inside whatever timeframe your business can survive.

The failures that only appear during a real restore

• Something important was never in scope. A new server, a new share, a database that moved. The backup job was configured accurately two years ago and has been faithfully backing up an outdated picture ever since.
• The restore is technically fine but far too slow. Recovering four terabytes over the available connection takes three days. The business assumed hours. Nobody did that arithmetic in advance.
• The backup contains the infection. Ransomware often sits quietly for weeks before triggering. Restore from any point after the initial compromise and you reinstate the attacker's foothold along with your data.
• Nobody present knows the procedure. The person who set it up has left. Credentials are in a password manager that is itself on an encrypted server.

Every one of these is discoverable on a quiet Wednesday afternoon. All of them are catastrophic to discover mid-incident.

How to actually test one

You don't need a full disaster simulation to get most of the value. Start small and be honest about the result.

Pick a real business system, not a test file. Restore it to an isolated environment rather than over production. Time the whole thing from decision to usable, and write the number down. Then open the data and check it properly — start the application, run a report, have someone from that department confirm the content is right and current.

Then compare the time you recorded against what the business actually assumed. That gap is your real recovery position, and it is usually a surprise.

Make it boring and repeatable

Test quarterly. Rotate which system you test so everything gets covered over a year. Keep a short written record of what was restored, how long it took, and what broke. Document the procedure well enough that someone who didn't build it can follow it, and store that document somewhere that survives your primary environment being unavailable.

Backups that scan for malware before restore close the reinfection gap, and immutable storage means an attacker who reaches your network can't quietly delete your recovery points. Both are worth having. Neither replaces actually testing the restore.

The businesses that recover quickly are almost never the ones with the most expensive backup product. They are the ones that had already done this, on an ordinary day, before anything went wrong.