Ransomware hits on a Friday afternoon, as it so often seems to. IT reassures everyone that backups are in place and recovery will be quick. Three hours into the restore process, it becomes clear that a chunk of the backup files are corrupted and have been that way for months, unnoticed because nobody had ever actually tried restoring from them until this exact moment.
A backup you have never restored is a theory, not a plan
Backup software reporting a successful nightly job tells you that data was copied somewhere. It does not tell you that data can actually be restored, in full, within a timeframe your business can survive without serious financial pain. Those are very different claims, and the gap between them only becomes visible at the worst possible moment, which is precisely during an active ransomware incident when there is no room left for surprises or second attempts, and every hour of downtime carries a real cost.
Ransomware recovery in particular depends on backups being isolated from the systems an attacker has already compromised. If your backup storage is reachable from the same network as your production environment, a sufficiently capable attacker can encrypt or delete your backups in the same sweep as your live data, removing the one safety net the business was counting on. An internal network pen testing that includes ransomware simulation will test exactly this scenario, checking whether your backup architecture would actually survive contact with a real attack rather than just a healthy status dashboard.
What testing a restore actually reveals
Running a genuine test restore, on a schedule rather than as a one-off exercise, surfaces problems that never show up in a backup log. Corrupted archives that report success while holding unreadable data. Missing configuration files that never made it into the backup scope in the first place. Restore times that stretch into days rather than the hours your business continuity plan assumes, based on figures nobody has actually tested recently. Dependencies between systems that mean restoring one server is useless without three others coming back online in the right sequence.
William Fieldhouse has watched this discovery happen in real time during incident response work.
“During one ransomware recovery, we found the client’s backup set was six weeks out of date because a scheduled job had been silently failing since a server migration, and nobody had checked a single restore in that entire time”
— William Fieldhouse, Director of Aardwolf Security Ltd
Six weeks of data does not sound catastrophic until it is your invoicing records, your customer communications, and your project files all disappearing at once. The backup existed on paper. In practice, it had quietly stopped being useful long before anyone needed it, and nobody found out until the worst possible day.
Make restoration the test, not the assumption
A backup strategy is only as good as its last successful, verified restore. Schedule regular restore tests rather than trusting completion reports, keep at least one backup copy genuinely isolated from your production network, and build ransomware scenarios into your resilience planning rather than treating them as unlikely to happen to you specifically. Speak to Aardwolf Security about vulnerability scan services that reveals whether your backups would actually survive an attack, since your recovery plan deserves the same scrutiny as your live defences.
