Your Backup Isn't a Backup Until You've Restored From It

Almost every business we take over has a backup running. Far fewer have one that would actually bring them back.

The quiet failure

Backup software is very good at telling you it succeeded. It is much worse at telling you that the thing it backed up is incomplete, that a new server got added six months ago and was never included, or that the encryption key nobody wrote down is required to read any of it.

These failures are silent by design - nothing is broken until you need the data, and by then it’s too late to fix the process.

The 3-2-1 rule, and why the “1” is the one that matters

• 3 copies of your data
• 2 different types of storage
• 1 copy off-site and disconnected from your network

That last one is what stops ransomware. Modern ransomware specifically hunts for backup drives and network shares and encrypts those first, precisely because it knows a working backup is what stops you paying. A backup drive permanently plugged into the server it protects is not a backup - it’s a second copy waiting to be encrypted alongside the first.

How to test a restore

You don’t need to simulate a disaster. You need to answer one question: can we get a specific file, and a whole system, back - and how long did it take?

1. Pick a real file from about a month ago. Restore it to a temp folder. Open it. Confirm it’s the right version and not corrupt.
2. Once a year, restore an entire system to a spare machine or a virtual machine and boot it.
3. Write down how long each took. That number is your actual recovery time - not the one in the brochure.
4. Confirm somebody other than one person can perform the restore, and that the credentials aren’t only in their head.

The questions worth asking today

How far back can we go? How long would it take to be running again? Is a copy off-site and disconnected? Who else can do the restore? If you can’t answer all four quickly, that’s the gap - and it’s usually cheap to close before it matters.