Disaster Recovery in 2026: RTO vs RPO, the Four DR Strategies, and What EU DORA Requires

Most engineering organisations have a disaster recovery plan. Far fewer have one that has been executed end to end against production-sized data in the last twelve months. That gap is expensive: in Uptime Institute's 2025 outage analysis, 54% of operators said their most recent significant outage cost more than $100,000, and 20% put the bill above $1 million (Data Center Knowledge, 2025). For financial entities in the EU, an untested plan is no longer just a risk, it is a compliance finding, because the Digital Operational Resilience Act now spells out backup, restoration and testing duties in law. Below are the questions engineering leaders actually ask about DR, with answers that hold up under audit.

Rows of server racks in a data center, the kind of physical capacity a disaster recovery strategy must be able to replace in a second location. — Photo: Carl Lender from Sunrise, USA / CC BY 2.0, via Wikimedia Commons

What is the difference between RTO and RPO?

Recovery Time Objective (RTO) is the maximum acceptable time between a disruption and the restoration of service. Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, expressed as time: an RPO of 15 minutes means you can lose at most the last 15 minutes of writes. RTO is about availability, RPO is about data. They are independent levers: continuous log shipping to a cold standby gives an RPO of seconds and an RTO of hours.

The practical consequence is that RTO and RPO must be set per business function, not per company. A payment authorisation path and an internal reporting dashboard do not deserve the same targets, and paying for one blanket target is how DR budgets get burned on systems nobody would miss for a day. The AWS Well-Architected Framework is blunt about this: you "should avoid implementing a strategy that is more stringent than it needs to be, as this incurs unnecessary costs" (AWS Well-Architected, REL13-BP02).

What are the four disaster recovery strategies?

The industry has converged on four patterns, ordered by increasing cost and complexity and decreasing RTO and RPO. The target ranges are the ones AWS publishes; the patterns apply equally on Azure, GCP or two colocation sites.

Backup and restore (RPO in hours, RTO in 24 hours or less). Data is backed up and copied to the recovery site; on disaster you rebuild infrastructure, redeploy code and restore. Point-in-time recovery can push RPO down to around five minutes in some cases. Infrastructure as code is what keeps the RTO honest here.
Pilot light (RPO in minutes, RTO in tens of minutes). Data is continuously replicated and the data tier is always on in the recovery site, but compute is not running. Recovery means provisioning application servers and scaling up.
Warm standby (RPO in seconds, RTO in minutes). A scaled-down but fully functional copy of the workload runs permanently in the recovery site and can take traffic immediately at reduced capacity. Scaled to full size, this becomes hot standby.
Multi-site active/active (RPO near zero, RTO potentially zero). The workload serves traffic from several sites at once. It is the most operationally complex option, mostly because concurrent writes to the same record in two regions must be avoided or reconciled.

The difference between pilot light and warm standby trips people up. The test is simple: can the recovery site process a request without anyone taking action first? If not, it is pilot light. Two design details matter more than the label. First, failover should depend on data plane operations (DNS health checks, routing controls) as far as possible, not on control plane calls such as creating or resizing resources, which AWS flags as an anti-pattern during recovery. The more pre-scaled the standby, the less control plane you depend on. Second, if your scale-up depends on capacity being available in the recovery region, reserve it; a pilot light that cannot get instances during a regional incident is not a strategy.

Is replication the same as a backup?

No, and this is the most common gap we see in otherwise mature setups. Replication faithfully copies whatever happens on the primary, including a bad migration, an accidental DROP TABLE or ransomware encryption. AWS notes that data replication "will not protect you against data corruption or destruction" unless the design also includes point-in-time recovery or versioning (AWS Well-Architected, REL13-BP02).

Attackers know this. In Sophos's survey of nearly 3,000 organisations hit by ransomware, 94% said attackers tried to compromise their backups during the attack, and 57% of those attempts succeeded. The median recovery cost for organisations whose backups were compromised was $3 million, against $375,000 where backups survived, and only 26% of the former were fully recovered within a week (Sophos, 2024). The engineering response is well known but unevenly applied: immutable or object-locked backup copies, a separate account or tenant with separate credentials for the backup vault, and no single identity that can delete both production and its backups.

What does EU DORA require for backup and recovery?

For Benelux banks, insurers, payment firms and their critical ICT providers, the Digital Operational Resilience Act (Regulation (EU) 2022/2554, applicable since January 2025) turns these practices into obligations (EUR-Lex). The articles engineering teams should read directly are 11 and 12:

Business impact analysis drives design. Article 11(5) requires a BIA and says ICT assets must be designed "in full alignment" with it, in particular to ensure redundancy of all critical components. That is a legal basis for per-function RTO and RPO, not a nice-to-have.
Test at least yearly, and after big changes. Article 11(6)(a) requires testing of ICT business continuity and response and recovery plans at least yearly, and whenever ICT systems supporting critical or important functions change substantively.
Documented backup scope and frequency. Article 12(1) requires backup policies that specify what data is backed up and at what minimum frequency, based on criticality, plus documented restoration and recovery methods. Article 12(2) requires those restoration procedures to be tested periodically.
Segregated restore environments. Article 12(3) requires that, when restoring with your own systems, you use ICT systems physically and logically segregated from the source system. A restore into the same compromised account does not qualify.
Recovery objectives tied to criticality. Article 12(6) requires RTO and RPO per function, taking into account whether it is critical or important, and that service levels are met in extreme scenarios.

Note what the regulation does not do: it does not prescribe a strategy. Backup and restore can be perfectly compliant for a non-critical function. What it does demand is evidence that the chosen strategy meets the stated objectives, which only testing can provide.

How often should you test a disaster recovery plan?

Annually is the regulatory floor, not the engineering target. The teams that recover cleanly treat DR as a continuously exercised capability rather than a yearly event:

Automated restore tests weekly or monthly. Restore a recent backup into an isolated account, run integrity checks and a smoke test, record the elapsed time against RTO. A backup that has never been restored is a hypothesis.
Game days quarterly. Fail over a real service, ideally in production during business hours with a rollback plan, and measure actual RTO and RPO. Then fail back, which is usually the harder half because data must be resynchronised to the original primary.
Runbooks as code. Failover steps scripted and versioned alongside the infrastructure, so that a manual decision to fail over becomes a single button rather than a 40-step wiki page. AWS recommends exactly this: automate the steps even when initiation stays manual, because automatic failover on noisy health checks has its own cost.
Change-triggered tests. A database engine upgrade or a move to a new region invalidates last quarter's result.

Report the measured numbers, not the designed ones. If the target RTO is 30 minutes and the last game day took 95, that is the number the board and the supervisor should see, together with the fix.

Where to start

If your DR posture is mostly documentation, the highest-leverage sequence is: run a BIA and assign RTO and RPO per function; make backups immutable and move the vault behind separate credentials; automate one full restore of your most critical datastore into a segregated account and time it; then pick the cheapest strategy per function that the measured result shows will meet its objective. That sequence satisfies the spirit of DORA Articles 11 and 12 and, more importantly, gives you a recovery you have actually seen work.