You Have a Backup, But Can You Actually Restore It?

Sophos surveyed 2,158 IT and security leaders for its 2026 State of Ransomware report, and their experience lines up: in 96% of ransomware attacks, the attacker goes after the backups first, and succeeds 76% of the time. “We have a backup” isn’t reassurance anymore. The real question is whether you can actually restore it when it counts.

We still see the same scene in client environments: the backup software shows green, the report says “successful,” and nobody has run a full restore in the last six months. The first real test happens the day a server goes down — and by then it’s usually too late to fix what’s broken.

What the Numbers Show

Sophos’ data draws a sharp line between having a backup and having one that works:

Metric	Value
Attacks where backups are targeted	96%
Attacks where the attacker compromises the backup	76%
Recovery rate via a working backup on encrypted data	66%
Recovery cost when backups are compromised	8x higher
Average total incident cost	$1.7 million

The detail worth sitting with: even organizations whose backups survive intact don’t always recover cleanly — the success rate on encrypted data tops out at 66%. In the remaining 34%, the backup exists, but the restore stalls somewhere.

Why Backups Fail to Restore

Three patterns keep showing up in the field.

A corrupted backup chain. Attackers can sit inside a network for months before triggering encryption. Every incremental backup taken during that dwell time already carries the corruption — you find out at restore time, not before.

Deleted snapshots. If the backup console shares admin credentials with production, an attacker who gets domain admin can walk in and delete older copies before encrypting anything. Backup infrastructure without its own admin account and its own network segment is a liability by itself.

A recovery time the business can’t absorb. The backup restores fine technically — it just takes 40 hours. The business assumed it needed three. Nobody had put the real number on the table beforehand.

Immutable storage solves only part of this: it protects data from deletion and tampering. It doesn’t guarantee the restore will finish, that the application will actually come back online, or that the recovered data is free of dormant malware. An immutable backup is safer than an untested one — it’s not a substitute for a tested one.

How to Build a Restore-Testing Program

This doesn’t need to be elaborate. It needs to be regular and measured.

• Run a full restore test quarterly, in an isolated environment separate from production.
• Sample your critical systems rather than testing everything: mail server, ERP database, file server — pick the three that matter most.
• Measure the actual recovery time and compare it against the RTO you promised. If there’s a gap, fix the expectation first.
• At least once, restore a snapshot that’s 30+ days old — testing only yesterday’s backup won’t catch silent corruption that’s been accumulating.
• Write down the result and assign an owner. A recovery plan nobody has tested is an intention, not a plan.

We saw this play out last year at a 20-person manufacturer: their annual restore test turned up a corrupted three-month-old ERP database backup. They found the root cause and fixed it. Without that test, the database simply wouldn’t have come back in a real incident.

Which Systems Should Come First?

Testing everything on the same schedule wastes time; testing nothing is a straight risk. The practical way to strike a balance is to rank systems by “how many hours until someone notices it’s down”:

Priority	System type	Test frequency
High	ERP/accounting database, mail server	Quarterly, full restore
Medium	File server, CRM, production applications	Every six months
Low	Archives, logs, old project data	Annually, sampled

For a small business, even a spreadsheet tracking this is enough — what matters is that the schedule exists and someone owns it. We track this calendar as part of the maintenance agreement for our clients, because a forgotten test produces the same outcome as one that was never run.

Frequently Asked Questions

How often should we run a restore test? Quarterly full tests for critical systems, at least annually for everything else. Any change to your backup software or infrastructure should trigger an extra test.

Is immutable storage enough on its own? Immutability reduces the risk of deletion and encryption, but it doesn’t prove the restore will work. The two aren’t interchangeable — you need both.

Should our own team run the test, or an outside provider? Your internal team knows the daily operation; an outside provider brings an independent eye and has usually seen more failure scenarios. The two working together tends to catch the most.

If you’d like help reviewing your backup strategy and setting up a restore-testing schedule, get in touch.