The 2 a.m. Restore That Doesn't Come

The Backup You Never Tested Is the Outage You'll Never Forget

It is 2:14 a.m., and Rohan Agarwal, the CISO of a logistics firm in Pune, is watching the one thing that was supposed to save him, refuse to work. The ransomware hit four hours ago. The board has been told, calmly, that there is no need to pay because the company has backups. Now the restore is running, and it is failing. Some backups are there, but corrupt. Others were reached by the attackers days before the encryption and quietly disabled. The "immutable" copy restores, but only to a server that is still infected, so it re-encrypts within the hour. By dawn, the question in the room has changed from "when will we be back?" to "do we pay?" 

Rohan did nothing obviously wrong. He had backups, as almost every victim does. What he did not have was a tested recovery, and on the worst night of his career, he learned the difference the hard way. You can learn it now instead. 

Why Do Backups Fail When You Need Them Most? 

Because in a ransomware attack, the backup is no longer a safety net behind the action; it is a target in the middle of it. Attackers know that an organisation that can restore will not pay, so they go after the backups first. In the Sophos State of Ransomware 2025 study, 94% of organisations hit said the attackers tried to compromise their backups, and 57% of those attempts succeeded. More than half the time, the very thing the victim was relying on had already been undermined before the ransom note appeared. A backup architecture designed for accidental data loss, a deleted file, a failed disk, is not designed for an adversary actively hunting it, and the gap between the two is where recovery plans die. 

Backup Is Not Recovery 

This is the reframe that matters, and it is the one Rohan wished he had internalised a year earlier. A backup is a copy of your data. Recovery is the ability to get the business running again, from data you know is clean, within a time the business can survive. The first is a noun you possess; the second is a capability you have proven. "Do we have backups?" is the wrong question, because the answer is almost always yes, and it tells you almost nothing. The right question is "can we recover, completely, by a deadline we have actually measured?" If you have never run the test, you do not know, and not knowing is the same as not being able to, right up until the night you find out. 

What Does a Tested Recovery Actually Involve? 

Four things, practised, not assumed. A defined recovery-time objective and recovery-point objective, so you know how fast you must be back and how much data you can afford to lose, as numbers, not hopes. Regular restore drills, where you actually rebuild systems from backups and confirm they work, rather than trusting that the backup job reported success. A clean environment to recover into, isolated from the compromised one, so you are not restoring straight back into the attacker's hands. And verification that the recovered data is intact and the application functions, not just that the files copied. A recovery you have rehearsed is a known quantity; one you have only designed is a hypothesis. 

Why Immutable Backups Alone Aren't Enough 

Immutable backups have rightly become the headline defence, copies that cannot be altered or deleted once written, so an attacker who reaches the backup system cannot destroy them. They are necessary. They are not sufficient. Rohan had immutability, and it still ended in a 2 a.m. crisis, because immutability protects the copy, not the recovery.  

You still have to be able to restore it fast enough to meet your RTO, and you have to restore it into a clean environment rather than the infected one, or the malware simply encrypts your good data again. Immutability without a tested recovery and a clean-room to restore into is a locked safe with no rehearsed plan for opening it under pressure. The full defence is immutable, isolated, tested, and recovered into a clean environment, working together. 

How Often Should You Test Recovery? 

Often enough that the test is boring, which means on a schedule and after every significant change. A recovery capability decays quietly: systems change, dependencies shift, the person who knew the runbook leaves, and a restore that worked last year fails this year for reasons nobody noticed. Regular drills, with the most critical systems tested most frequently, keep the capability real and surface problems while they are cheap to fix, in a planned test, rather than expensive to discover, in a live attack. The organisations that recover calmly are the ones for which recovery is a routine rehearsal, not a first attempt under the worst possible conditions. 

A Quick Self-Check: Would Your Backups Survive an Attack? 

Answer these honestly, the way Rohan now wishes someone had made him. 

Can you state your recovery-time objective for your critical systems as a number? Have you fully restored a critical system from backup in the last quarter, not just checked that the backup job succeeded? Are your backups both immutable and isolated, so an attacker inside your network cannot reach them? Do you have a clean environment to recover into, separate from production? Would your monitoring tell you if backups were being tampered with before the encryption began? Does someone other than the original author know how to run the recovery? 

A "no" or an "I think so" to any of these is a gap, and gaps in recovery are invisible until the night they are not. The value of the self-check is that it turns a vague confidence into a specific list of things to fix while you still have time. 

Closing the Gap 

The fix is not more backup software; it is turning backup into recovery you can prove. That means immutable copies an attacker cannot destroy, isolation or an air gap so they cannot reach them, a clean environment to restore into, recovery objectives measured as numbers, and drills frequent enough to keep the whole thing real. None of it is exotic. What it takes is treating recovery as a capability to be tested and owned, rather than a product to be bought and assumed, and most organisations are one honest assessment away from knowing where they stand. 

Make Recovery a Tested Fact, Before 2 a.m. 

Rohan's firm recovered, eventually, at a cost in downtime and reputation that a single rehearsed restore would have avoided. The difference between his night and a calm one was not the backup product; it was whether recovery had been proven before it was needed. Building that, immutable and isolated backups, a clean-room to recover into, measured objectives, and the drills that keep them honest, is where an experienced partner turns a hope into a tested fact. 

Proactive Data Systems designs and runs data protection and cyber recovery for Indian enterprises, built around recovery you can prove, across Veeam, Veritas, Rubrik, ExaGrid and Dell EMC. We are a Cisco Preferred Cloud and AI Partner, Dell Platinum Partner and NetApp Preferred Partner, with 35 years in enterprise IT, more than 1,500 organisations served, and a 24/7 service desk in India. To find out whether your backups would actually survive an attack, you can ask Proactive for a cyber-recovery readiness assessment.