Backup, DR and Cyber Recovery: Building a Strategy That Actually Recovers
Backup, disaster recovery and cyber recovery are three different disciplines, and most organisations quietly treat them as one. That gap is exactly where ransomware wins. Traditional disaster recovery was built for a flood or a failed array, not for an attacker who deliberately goes after your backups first. Here is how to build a recovery strategy that holds up when someone is trying to make sure it does not.
Ask most organisations if they can recover from a disaster and they will point at their backups and their DR site and say yes. Ask whether they can recover from a ransomware attack that encrypted the production estate, reached the backup servers, and deleted the snapshots, and the confidence usually drains out of the room. Those are different questions, and the difference is the whole point of this guide. Recovery is not one capability, it is three, and the gaps between them are where recovery plans fail at the worst possible moment.
A backup you have never restored is a hope, not a plan. And a DR copy that a ransomware attack can reach and encrypt is not recovery, it is a second victim. The test of a recovery strategy is not whether the copies exist, it is whether you can prove you can bring the business back from them, cleanly, after a deliberate attack, in a time the business can survive.
Backup, DR and cyber recovery are not the same thing
The words get used interchangeably and they should not, because they solve different problems and demand different designs.
- Backup is about keeping copies of data so you can restore individual files, systems or datasets after loss or corruption. It answers "can I get the data back".
- Disaster recovery is about keeping the business running through the loss of a system or a site, failing over to a second copy fast enough to matter. It answers "can I keep operating". It is measured in how much data you can afford to lose and how long you can afford to be down.
- Cyber recovery is about recovering from a deliberate attack that targeted your data and your ability to recover it at the same time. It answers "can I come back when someone has tried to make sure I cannot". It is the newest of the three and the one most estates are weakest at.
You need all three, designed deliberately. Most organisations have the first two, built for an era when the threat was accident, not malice, and assume they add up to the third. They do not.
Why traditional disaster recovery fails against ransomware
Classic DR was designed for outages: a burst pipe in the data centre, a failed storage array, a power event, a region going dark. Its whole job is to replicate production faithfully and quickly to a second location so you can fail over. Against an accident that works beautifully. Against ransomware it becomes part of the problem, because DR replicates the attack as faithfully as it replicates everything else. Encrypt production and the encryption dutifully replicates to the DR site. Now both copies are ruined.
It gets worse, because a competent attacker knows this. Modern ransomware does not lunge straight at production. It dwells on the network, finds the backup infrastructure, and deletes or encrypts the backups and snapshots first, precisely so you have nothing clean to recover from and no choice but to pay. Your backup catalogue, your DR replicas, your snapshots on the same network, all reachable, all targets. A recovery plan that assumes the backups will simply be there is planning for the wrong enemy.
If your backups sit on the network, reachable with the right credentials, they are not a recovery guarantee, they are an inventory the attacker will work through before they trigger the encryption. Recoverability after a cyber attack depends on at least one copy the attacker cannot reach, alter or delete, and a way to bring it back that is not itself compromised.
What cyber recovery actually requires
Cyber recovery is what closes the gap traditional DR leaves open. It rests on a few things that are simple to state and easy to skip.
- Immutable, air gapped copies. At least one copy of the critical data that cannot be altered or deleted for a set period, and that is logically or physically isolated from the production network. This is the copy that survives when everything reachable has been hit. Our guide to immutable storage covers the mechanism in depth.
- A known good recovery point. Attackers often dwell for weeks, so the most recent backup may already be compromised. You need the ability to detect when the data was last clean and recover from that point, not blindly from the latest copy.
- An isolated recovery environment. A clean room, separate from the infected estate, where you can rebuild and validate systems without re infecting them the moment they come up. Recovering into the same compromised network just restarts the incident.
- A tested recovery runbook with an order. Recovery is not one button. It is identity first, then the systems everything else depends on, then the tiers of the business in priority order. That sequence has to be written, owned and rehearsed before the day you need it.
RPO and RTO: the two numbers that shape the whole design
Every recovery decision comes back to two questions, and it is worth being honest about them before a vendor sizes anything. Your recovery point objective is how much data you can afford to lose, measured in time: if you back up every night, an RPO of a day means a bad morning. Your recovery time objective is how long you can afford to be down before the impact becomes unacceptable. Tight numbers cost more, because they demand more frequent copies and faster failover. The mistake is setting them by aspiration rather than by what each system actually justifies. Not everything needs minutes. Some things cannot tolerate hours. Design to the real tolerance of each workload and you stop overpaying to protect the trivial and underprotecting the critical.
The 3-2-1 rule, brought up to date
The old discipline still holds, with an addition the ransomware era made essential. Keep at least three copies of your data, on two different types of media, with one held offsite. Then add one copy that is immutable or air gapped, and prove that zero of your recoveries fail by testing them. Three, two, one, one, zero. The last two are what turn a backup regime built for accidents into one that survives an attack. Most estates have the three, two and one. It is the immutable copy and the tested zero that decide whether you actually recover.
The single most common recovery failure is not missing backups, it is backups nobody has ever fully restored. Plans look complete on paper and fall apart in practice: dependencies nobody mapped, a recovery order nobody agreed, restores that take far longer than anyone assumed. The only way to know your RTO is real is to rehearse a full recovery, including a cyber scenario where the backups themselves are suspect. An untested plan is a document, not a capability.
This is now a regulatory expectation, not just good practice
For regulated sectors, recoverability has moved from prudent to mandatory. Operational resilience rules and, for financial services, DORA, expect firms to be able to withstand and recover from severe but plausible disruption, including cyber attack, and increasingly to have tested it. A recovery strategy that cannot be evidenced is a compliance gap as well as an operational one. Our guide to DORA and operational resilience works through what that obligation means in practice.
How C4C helps
This sits where our infrastructure and our security work meet, and it is a place where the datasheet and the reality diverge sharply. We help you separate backup, disaster recovery and cyber recovery into the three disciplines they are, set RPO and RTO to what each workload genuinely justifies rather than what a vendor wants to sell, design in the immutable and isolated recovery you need to survive an attack, and above all pressure test whether the plan actually recovers rather than assuming it does. Independent, with no backup product line to push. We spent years on the vendor side of storage and infrastructure, so we know how these platforms behave when you are genuinely trying to recover under pressure, not how the recovery demo goes, and that experience now sits on your side of the table.
Prefer to start with a free, no obligation diagnostic? Book our Ransomware and Cyber Recovery Readiness Assessment, an independent expert read of where you stand.
Confident you could actually recover?
Tell us what you are protecting and what worries you, an untested DR plan, ransomware exposure, a DORA obligation, or backups you are not sure are safe. We will give you an independent, vendor neutral view of whether your strategy would really recover the business, and a clear order of work to close the gaps. We have architected and stress tested this from the inside.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
What is the difference between backup, disaster recovery and cyber recovery?
They solve three different problems. Backup keeps copies of data so you can restore files or systems after loss or corruption. Disaster recovery keeps the business running through the loss of a system or site by failing over to a second copy fast enough to matter. Cyber recovery is recovering from a deliberate attack that targeted your data and your backups at the same time, which requires isolated, immutable copies and a clean environment to rebuild in. You need all three, and most organisations have the first two while assuming they add up to the third.
Why does traditional disaster recovery fail against ransomware?
Because DR is designed to replicate production faithfully to a second location, so when production is encrypted the encryption replicates to the DR site and both copies are ruined. Worse, capable ransomware deliberately finds and deletes or encrypts backups and snapshots before triggering the main attack, precisely so you have nothing clean to recover from. DR built for accidents like fire or hardware failure does not defend against an adversary who targets your ability to recover. That is what cyber recovery exists to address.
What is cyber recovery?
Cyber recovery is the ability to bring the business back after a deliberate attack that went after both your data and your means of recovering it. It rests on at least one immutable, air gapped copy the attacker cannot reach or delete, the ability to find a known good recovery point from before the compromise, an isolated clean room environment to rebuild and validate systems without re infecting them, and a tested recovery runbook with a defined order. It is the discipline that closes the gap traditional disaster recovery leaves open.
What is the 3-2-1 backup rule?
It is the long standing baseline for backup resilience: keep at least three copies of your data, on two different types of media, with one held offsite. The ransomware era added two more elements, making it three, two, one, one, zero: one copy that is immutable or air gapped so an attacker cannot alter it, and zero failed recoveries, proven by actually testing your restores. The original three, two, one protects against loss. The added immutable copy and tested recovery are what protect against a deliberate attack.
What are RPO and RTO?
They are the two numbers that shape a recovery design. Recovery point objective is how much data you can afford to lose, measured in time, so a nightly backup implies you could lose up to a day. Recovery time objective is how long you can afford to be down before the impact becomes unacceptable. Tighter numbers cost more because they need more frequent copies and faster failover, so the discipline is setting them to what each workload genuinely justifies rather than applying one aspiration to everything.
How often should we test our disaster recovery plan?
Regularly, and more thoroughly than most do. The most common recovery failure is not missing backups but backups nobody has ever fully restored, so plans that look complete on paper collapse in practice over unmapped dependencies and restores that take far longer than assumed. At minimum, rehearse a full recovery on a defined cycle and after any significant change, and include a cyber scenario where the backups themselves are treated as suspect. Until you have restored, you do not know your real recovery time, you only have an estimate.