What Is Disaster Recovery?
Disaster recovery (DR) is the set of processes, technology, and planning an organisation uses to restore IT systems and data after a disruptive event — a hardware failure, ransomware attack, natural disaster, or human error that takes critical systems offline. A DR strategy defines exactly how systems get back online, in what order, and how much data (if any) is lost in the process.
It's easy to assume backup and disaster recovery are the same thing. They're related, but distinct: backup protects your data; disaster recovery protects your ability to keep operating. A business with backups but no DR plan can usually recover its files eventually — but may have no clear process for getting systems back online quickly, no failover site, and no tested plan for who does what during an outage.
RTO and RPO: The Two Numbers That Define Your DR Strategy
Every DR strategy comes down to two measurements:
RTO — Recovery Time Objective
How long can your business tolerate being down? RTO is the maximum acceptable time between a disaster and systems being back online.
RPO — Recovery Point Objective
How much data can you afford to lose? RPO is the maximum acceptable gap between your last good backup or replication point and the disaster.
A business that can tolerate a few hours of downtime and a day's data loss needs a very different (and much cheaper) DR setup than one that needs failover within seconds and zero data loss. Getting RTO and RPO right for your actual business needs — not over-engineering, not under-protecting — is the starting point for any DR strategy.
Core Components of a Disaster Recovery Strategy
Data replication
Copying data to a secondary location — another site, or the cloud — so a copy survives even if the primary site is lost.
Failover infrastructure
A secondary system or site capable of taking over operations, whether that's a full DR site or cloud-based failover.
Immutable & air-gapped copies
Backup copies that ransomware and insider threats can't reach — critical given how much modern DR planning is driven by cyberattack recovery, not just hardware failure.
A tested, documented plan
Who does what, in what order, and how the plan is actually tested — an untested DR plan is a guess, not a strategy.
Not sure what RTO and RPO make sense for your business? Talk to us about the right level of DR protection for your actual risk profile — not more, not less.
Speak to our team →How Modern Storage Hardware Supports Disaster Recovery
DR strategy isn't purely a software or process question — the storage hardware underneath it matters. Fortuna Data's storage range includes several genuine DR-relevant capabilities:
- IBM FlashSystem 9500 supports three-site replication and HyperSwap technology for automatic failover between geographically dispersed sites with zero downtime, plus Safeguarded Copy for immutable, ransomware-resistant snapshots.
- IBM TS7700 extends mainframe tape storage to public or private cloud for flexible DR, with air-gap and WORM capabilities acting as a genuine cyber-resilience layer.
- Tiered storage and active data archiving reduces the volume of data that needs replicating to a DR site in the first place — meaning DR restores only need to cover data that's actually on the primary file server.
Disaster Recovery vs. Backup: Getting the Distinction Right
This is worth restating clearly, because it's the single most common point of confusion: a backup that isn't part of a tested recovery plan doesn't protect your business continuity — it just protects your files. For a fuller breakdown of where the two overlap and where they genuinely differ, see our dedicated Backup vs Disaster Recovery guide.
Building a DR Plan That Actually Works
A DR plan that's never been tested is a document, not a strategy. The organisations that recover fastest from real incidents are the ones who've rehearsed the process — not just backed up the data. If you're starting from scratch, or reviewing a DR plan that hasn't been touched in years, the right starting point is understanding your actual RTO/RPO requirements, then working backwards to the infrastructure and process that delivers them — rather than buying technology first and hoping it fits.
