Your backup works. Your restore is the part you never tested.

The backup runs every night. You get a green tick, or at least you would if you ever looked, and the reassuring knowledge that “we have backups” sits quietly in the back of your mind. It’s the one bit of disaster planning most small businesses can honestly say they’ve done. So the box feels firmly ticked.

The trouble is that a backup is only half a promise. The half that matters — the part where you actually get your files back, intact, quickly, on the worst day of the year — is the part almost nobody tests. And two things tend to go wrong precisely because they’re invisible until you try: the backup you’ve been taking may not restore cleanly, and if it runs on the same login and network as everything else, the same ransomware that encrypts your live files reaches straight into the backups and encrypts those too. You discover both facts at the same moment, and it’s the worst possible moment to discover them.

That’s the quiet failure: not a missing backup, but an untested one — a safety net you’ve never once stood under, hanging exactly where the same fire can reach it.

Why it stays invisible

A backup job is designed to reassure you. It reports success when it finishes copying data, and “finished copying” is not the same as “can be restored” — a backup can complete every night while quietly holding corrupt, incomplete or unreadable files, and nothing tells you, because nothing ever reads them back. The only honest test of a backup is a restore, and a restore is the one thing a nightly job never does on its own.

So the failure hides in the gap between running and restoring. Automated restore-testing is the feature everybody has and nobody switches on: when Acronis looked across its own disaster-recovery platform this year, 82% of setups had automated testing set — literally — to “never”, which means the first real read of the backup is the emergency itself.

The second trap is worse because it feels like belt-and-braces. If your backup lives on a drive that’s always connected, or in a cloud account reachable with your normal admin login, on the same network as your servers, then from an attacker’s point of view it’s just another folder. Modern ransomware specifically hunts for and encrypts backups first, because the operators know a business with working backups won’t pay. “We have backups” offers no protection if the backups are sitting in the blast radius — which is how, in Kaseya’s recent figures, 31% of organisations that had backups still failed to get their data back after ransomware.

Find it yourself

You can test the part that actually matters in about ten minutes. You don’t need a spare server — you need to prove you can get one thing back, and to check where the backup lives.

1. Restore one real file, right now. Pick a document you can identify, delete it (or better, pick one already gone), and restore it from your backup to a different location — a temp folder on your desktop, not over the original. Open it. Confirm it’s the right file and it isn’t corrupt. That single successful restore tells you more than a month of green ticks.

2. Restore something bigger than one file. A single document is a start, but the day you need this you’ll be restoring a whole folder or mailbox. If your tool allows it, restore a folder to a scratch location and check the files inside actually open. Note how long it took — that number is your real recovery time, and it’s usually longer than people guess.

3. Check whether the backup shares your fate. Ask two plain questions. Can the backups be deleted or encrypted using the same admin login you use every day? And are they on a drive or share that’s permanently connected to your network? If the answer to either is yes, the backup is inside the blast radius. You want at least one copy that is offline or immutable — a copy that ransomware, and a compromised admin account, simply cannot reach or overwrite.

4. No command line, no problem. Every reputable backup tool — from Windows File History to Time Machine to your cloud backup’s web console — has a “restore” or “recover” button. This whole check is doable from those buttons; you don’t need to be technical to prove a file comes back.

The usual surprise is at step 2: not that the restore fails, but that it takes far longer than anyone assumed — long enough to change what you’d promise a customer.

The fix

Good here isn’t a bigger backup. It’s a backup you’ve proven you can restore, kept somewhere the same disaster can’t reach.

Follow the 3-2-1 shape. Keep three copies of anything important, on two different kinds of media, with one copy off-site or offline. The off-site/offline copy is the one that survives ransomware, fire and a compromised admin account alike — it’s the whole point of the rule.

Keep one copy out of reach. Aim for at least one backup that is immutable (it can’t be altered or deleted for a set period, even by an administrator) or genuinely offline. Many cloud backup services now offer immutability as a setting — turn it on. This is the single change that stops “they encrypted the backups too”.

Separate the keys. The backup system shouldn’t be reachable with the same login that runs everything else. Give it its own credentials and its own two-factor, so one phished admin password doesn’t hand over both your live data and your safety net.

Test restores on a schedule, not on the day. Put a recurring reminder — monthly is ample — to restore a file or two and confirm they open. If your tool can run and verify test restores automatically, switch that on; it’s the feature that turns “we think it works” into “we watched it work last week”.

None of this requires a disaster-recovery consultant or new kit. It needs one restore done today, in the calm, to find out what you’d actually be dealing with — and one copy of your data kept somewhere the fire can’t follow. A backup you’ve restored from once is a different thing entirely from a backup you merely have.