Short answer
A disaster recovery strategy is a decision, per system, about how quickly you must recover (RTO) and how much data you can afford to lose (RPO). In the cloud there are four main options: backup and restore, pilot light, warm standby and multi-site active/active, rising in cost as recovery gets faster. Choose per system by business impact, keep point-in-time backups, and test recovery regularly.
- 4 - cloud disaster recovery strategies, from backups to active/active
- 2 - numbers that drive the choice: RTO and RPO
- ≈0 - recovery time possible with active/active, at the highest cost
- 0 - value in backups you have never restored
Disaster recovery is the plan for getting a system back after a serious failure: a region outage, ransomware, a bad deployment or deleted data. It is defined by two numbers. The recovery time objective (RTO) is how long the business can tolerate the system being down. The recovery point objective (RPO) is how much recent data it can afford to lose. Everything else follows from those two decisions.
RTO and RPO in plain English
TermQuestion it answersExampleRTO: recovery time objectiveHow long can this system be unavailable?Checkout must be back within 1 hourRPO: recovery point objectiveHow much recent data can we lose?No more than 5 minutes of orders
Set RTO and RPO with the business, not inside IT. A reporting dashboard might tolerate a day of downtime and a day of lost data; payments might tolerate minutes. Lower numbers cost more, so different systems deserve different targets.
Put a price on downtime first
RTO and RPO are hard to agree in the abstract and easy to agree with a number in front of everyone. For each critical system, estimate what one hour of downtime costs: revenue that can’t be taken, or that customers take elsewhere; contractual penalties and service credits; extra staff and overtime during recovery; and harder costs to count, such as reputation and customer trust. Do the same for data loss: what does it cost to lose an hour of orders, or of customer records?
Cost elementHow to estimate itExample: online store with $50,000 revenue a dayLost revenueRevenue per hour × share not recovered later$50,000 ÷ 24 ≈ $2,100 an hour; if half returns later, about $1,050Penalties and creditsFrom customer contracts and SLAsNone for consumers; check B2B contractsRecovery effortPeople involved × hours × cost per hour6 people × $100 an hour ≈ $600 an hourLost dataValue of transactions or records you couldn’t recreateOrders placed since the last recovery point
In this illustrative example, an hour of downtime costs about $1,650 before reputation. That makes the trade-off concrete: a warm standby that costs a few thousand dollars a month is easy to justify for a system losing that much per hour, and hard to justify for an internal report.
Business continuity guidance, such as NIST’s contingency planning guide (SP 800-34), adds one more number: the maximum tolerable downtime, the longest a business process can be unavailable before the damage becomes unacceptable. Your RTO must sit comfortably below it, leaving time to check data and resume work after systems are back.
The four cloud disaster recovery strategies
StrategyHow it worksRecovery speedCostBackup and restoreBack up data, code and configuration; rebuild infrastructure from code in the recovery region when neededSlowest (hours)LowestPilot lightData replicated continuously; core infrastructure ready, application servers switched off until failoverFaster (tens of minutes)LowWarm standbyA scaled-down but fully running copy of production that can take traffic immediately, then scale upFast (minutes)MediumMulti-site active/activeProduction runs in several regions at once and serves traffic from all of themNear zero for most disastersHighest
These are the four approaches described in AWS’s disaster recovery whitepaper, and the same patterns apply on Azure and Google Cloud. Recovery speeds above are indicative: your achieved RTO depends on automation, data size and practice.
Recovery tiers: matching targets to systems
Grouping systems into a few tiers keeps decisions simple and stops every team asking for the fastest option. The targets below are a common starting point, not a standard; set your own with business owners from the cost of downtime.
TierTypical systemsExample RTOExample RPOUsual strategyTest at leastTier 1: criticalPayments, checkout, core customer productMinutesSeconds to minutesWarm standby or active/activeEvery quarterTier 2: importantCustomer portals, order managementUnder 4 hoursUnder 1 hourPilot lightTwice a yearTier 3: business supportInternal tools, reporting, CRM integrationsWithin 1 dayWithin 1 dayBackup and restoreOnce a yearTier 4: deferrableArchives, test environmentsSeveral daysLast backupBackup and restoreRestore a sample once a year
Backups still matter, even with replication
Continuous replication gives a near-zero recovery point for infrastructure failures, but it faithfully copies corruption, bad deployments and malicious deletions too. Every strategy, including active/active, needs point-in-time backups, ideally copied to a separate account so a compromised production account cannot delete them. This is central to ransomware recovery, which we cover in our cyber resilience guide.
Backups also have to cover more than data. AWS points out that a recovery region needs the code, configuration and machine images to rebuild the system, ideally defined as infrastructure as code. Without them, restoring can take far longer than the RTO allows. For decision makers, the useful question is simple: if production disappeared today, do we have everything needed to rebuild it, stored somewhere an attacker with our production credentials couldn’t reach?
How to choose a strategy for each system
Most companies end up with a mix: backup and restore for internal tools, pilot light or warm standby for important customer-facing systems, and active/active only where downtime is extremely expensive. Cost discipline matters here too; our FinOps playbook covers keeping standby environments lean.
Test, or it is not a plan
- Restore real backups to a clean environment on a schedule and check the data is usable.
- Run failover exercises for critical systems, ideally during working hours with the people who would be on call.
- Measure achieved RTO and RPO and compare them with targets.
- Keep runbooks current and automate the steps so failover is close to pushing a button.
- Check service limits and capacity in the recovery region before you need them.
A related decision is whether failover starts automatically or by a person. AWS notes that automatic failover based on health checks should be used with caution: recovery time and data loss are always greater than zero, so failing over on a false alarm causes real losses. Many teams start failover manually but automate every step after that decision, so starting it is like pressing a button. Check service quotas in the recovery region too, so it can scale to full production when needed.
Mature cloud practices make all of this easier: infrastructure as code, automated deployments and good observability. If those are missing, DR plans tend to exist on paper only, a gap we describe in cloud maturity.
Questions to ask your technology leaders
Could we recover from a disaster tomorrow?
- What are the agreed RTO and RPO for each of our critical systems, and who signed them off?
- Which DR strategy protects each system, and does it meet those targets?
- When did we last restore from backup and fail over for real, and what did we achieve?
- Are backups stored in a separate account that a compromised production account cannot delete?
- What would a regional cloud outage mean for customers today?
Cloud & DevOps
Not sure your recovery plan would work?
We agree RTO and RPO with your business owners, design the right DR strategy for each system and run the first recovery test with your team.
Sources
- Disaster recovery options in the cloud (AWS whitepaper)
- Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1 (NIST)
Originally published at phpscientist.com.
Top comments (0)