Cloud Disaster Recovery: RPO, RTO, and DRaaS Explained

Two numbers run every disaster recovery decision

Almost every disaster recovery conversation eventually comes down to two numbers, and most teams cannot state theirs. Get them defined and the rest of the plan — architecture, budget, tooling, drills — falls into place. Leave them vague and you will discover the real values during an outage, which is the worst possible time.

• RPO — Recovery Point Objective. How much data you can afford to lose, measured in time. An RPO of 15 minutes means that after a failure you accept losing up to the last 15 minutes of transactions. RPO is set by how often you replicate or back up. Continuous replication pushes RPO toward zero; a nightly backup gives you an RPO of up to 24 hours.
• RTO — Recovery Time Objective. How long the business can be down before the service is restored. An RTO of one hour means you must be running again within 60 minutes of declaring a disaster. RTO is set by how fast you can stand up compute, restore data, repoint networking, and validate the application.

RPO looks backward at data loss; RTO looks forward at downtime. They are set per workload, not per company. A payment ledger may demand an RPO of seconds and an RTO under an hour; an internal wiki might tolerate a 24-hour RPO and a full day of recovery. Tiering workloads this way is the single most effective way to control cost, because protection gets dramatically more expensive as both numbers approach zero.

The four DR strategies, and what each really costs

Cloud disaster recovery is a spectrum of standby readiness. The more infrastructure you keep warm, the faster you recover and the more you pay to have it waiting. Four patterns cover almost every design.

1. Backup and restore

Data and machine images are backed up to durable object storage in a second region or provider. On disaster, you provision infrastructure from scratch and restore from those backups.

• Recovery profile: RPO of hours (backup frequency), RTO of hours to a day.
• Cost: Lowest. You pay mainly for storage, not idle compute.
• Fits: Tier-3 workloads, dev/test, and anything where a day of downtime is an inconvenience rather than a crisis.

2. Pilot light

A minimal core of the environment runs continuously in the recovery region — the database replicating in near real time, core networking configured — while application servers sit as pre-built images, switched off. In a disaster you scale the "flame" up around the always-on core.

• Recovery profile: RPO of minutes, RTO of tens of minutes.
• Cost: Low to moderate. You pay for continuous replication and a small always-on footprint, not a full duplicate stack.
• Fits: Important workloads that need fast data currency but can tolerate a short scale-up window.

3. Warm standby

A scaled-down but fully functional copy of the environment runs at all times in the recovery region. Everything is on; it is simply sized smaller and can absorb traffic immediately, then scale to full capacity.

• Recovery profile: RPO of seconds to minutes, RTO of minutes.
• Cost: Moderate to high. You run a second, smaller environment around the clock.
• Fits: Revenue-generating and customer-facing systems with a low downtime tolerance.

4. Active-active (multi-site)

The workload runs live in two or more regions simultaneously, sharing traffic. If one region fails, the others carry the load — often with no human intervention.

• Recovery profile: RPO near zero, RTO near zero.
• Cost: Highest. You run full capacity in multiple places and take on the engineering complexity of data consistency across regions.
• Fits: Tier-0 systems where even minutes of downtime carry regulatory or material financial consequences.

The trade is consistent across all four: recovery speed and data currency are bought with standing infrastructure. Rather than force one strategy onto everything, mature teams map each tier of workload to the cheapest pattern that still meets its RPO and RTO. A well-designed cloud footprint usually mixes all four.

A backup you have never restored is a hope, not a plan

The most common failure in disaster recovery is not a missing backup — it is an untested one. Teams discover during a real incident that a backup job silently failed weeks ago, that restores take four times longer than assumed, that a dependency the runbook forgot blocks the whole sequence, or that no one knows who has authority to declare a disaster. The plan looked complete on paper and collapsed under pressure.

Testing is the only way to convert an assumed RTO into a proven one. Make it routine:

1. Schedule real restore drills — at least quarterly for critical workloads, and after any significant architecture change.
2. Restore full systems, not single files. A single-file restore proves the backup exists; a full-system, application-level recovery proves you can actually run.
3. Measure the clock. Time each drill end to end and compare it against the documented RTO. If reality exceeds the objective, the objective is fiction until you fix the gap.
4. Rotate the responders. Recovery cannot depend on one hero who happens to be reachable. Different team members should be able to execute the runbook.
5. Record and close findings. Every drill produces gaps. Track them like incidents until resolved.

Tested recovery is where disaster recovery meets business continuity: the broader discipline of keeping the organization running — people, processes, communications, and priorities — while technical recovery proceeds.

Immutability: the control ransomware cannot defeat

Modern ransomware crews hunt backups first. They know that if they encrypt or delete your recovery copies, you have no choice but to pay. Online backups reachable with ordinary domain credentials get destroyed right alongside production, and a DR plan that assumed clean restore data suddenly has none.

Immutability is the answer. An immutable backup is written once and cannot be altered or deleted for a defined retention window — not by an administrator, not by stolen credentials, not by the ransomware itself. Pair it with disciplined design:

• Follow 3-2-1-1: three copies, on two media types, one offsite, and one immutable or air-gapped.
• Isolate backup credentials from production identity so a domain compromise cannot reach the recovery copies.
• Set retention to outlast dwell time. Attackers often linger for weeks before detonating, so immutable retention must be long enough that a clean, pre-intrusion restore point still exists.

Immutability turns backups from a target into a guarantee. Combined with tested restores, it is the core of resilient managed backup and disaster recovery.

Where DRaaS fits

Disaster Recovery as a Service (DRaaS) delivers all of the above — replication, standby capacity, orchestration, and failover — as a managed service rather than a build-it-yourself project. A provider replicates your workloads to their cloud, maintains the runbooks and automation, runs the drills with you, and, in a declared disaster, executes and validates the failover.

DRaaS earns its place when:

• You lack a second region or a team to engineer and staff DR internally.
• You want failover orchestration and non-disruptive testing built in, not scripted from scratch.
• You need contractual, tested RPO and RTO commitments rather than best-effort hope.
• Compliance or cyber-insurance requires demonstrable, regularly exercised recovery.

The value is not just the technology — it is the operational discipline of someone who runs recovery for a living, keeps the automation current, and has done it under real pressure before it was your turn.

Start with your two numbers

Disaster recovery is not a product you buy once; it is an RPO and an RTO per workload, matched to the right standby strategy, proven by regular drills, and hardened with immutable copies. If you cannot state those numbers today, that is where to begin. intSignal designs, tests, and operates cloud disaster recovery and DRaaS for organizations that cannot afford to guess — mapping each workload to the cheapest architecture that still meets its targets, then proving it holds. Talk to our cloud team to set defensible recovery objectives and build a plan you have actually tested.