Cloud Disaster Recovery: RPO, RTO and Failover

Disaster recovery (DR) in the cloud is the set of plans, tools and tested procedures that let you restore your systems and data after something serious goes wrong, such as a region outage, data corruption, a deleted database or a ransomware attack. Two numbers define it: the recovery point objective (RPO), which is how much data you can afford to lose measured in time, and the recovery time objective (RTO), which is how long you can afford to be down. Everything else, from backups to standby environments, is a way of meeting those two numbers at a cost the business accepts.

A common misunderstanding is that putting systems in the cloud makes them disaster-proof. Cloud providers build resilient infrastructure, but under the shared responsibility model the recovery of your data and applications remains yours to design and test. This guide explains the terms, the strategies from cheapest to most resilient, and how to build a plan that actually works.

RPO and RTO in plain English

• RPO (recovery point objective): the maximum acceptable data loss. If your RPO is one hour, you must be able to restore to a state no more than one hour old. That dictates how often you back up or replicate.
• RTO (recovery time objective): the maximum acceptable downtime. If your RTO is four hours, service must be restored within four hours of the incident being declared. That dictates how prepared your standby environment and your procedures are.

The two are independent. A system can tolerate losing an hour of data but must be back in ten minutes, or the reverse. Set them per system, not for the whole company: the order-taking platform and the internal wiki rarely deserve the same targets. Related terms you may hear are the maximum tolerable downtime (the point at which the business is seriously harmed) and the recovery level for degraded service, where only critical functions come back first.

The key discipline is that the business sets RPO and RTO, based on the cost of downtime and data loss, and technology then prices the options. Tighter targets always cost more, so the conversation should be a trade-off, not a wish list.

Backup versus failover

These are different tools, and you usually need both.

	Backup	Failover (replication and standby)
Purpose	Restore data to an earlier point in time	Keep service running by switching to a second environment
Protects against	Deletion, corruption, ransomware, human error	Hardware, zone or region failure
Does NOT protect well against	Long downtime during restore	Logical errors, because mistakes replicate instantly
Typical RPO	Interval between backups	Seconds to minutes
Typical RTO	Hours or longer, depending on data size	Minutes
Relative cost	Lower	Higher

The critical point is that replication copies mistakes. If someone deletes a table or ransomware encrypts files, a real-time replica faithfully deletes or encrypts the copy too. Only point-in-time backups, kept separate, let you go back to before the problem. A mature design combines a replica for availability with versioned, isolated backups for recoverability.

Four common DR strategies

AWS describes four patterns in its documentation on disaster recovery, and they translate well to other platforms, including Azure. In order of increasing cost and decreasing RTO:

1. Backup and restore. You keep backups in another region or account and rebuild the environment from code when needed. Cheapest, with the longest recovery time. Suitable for non-critical systems.
2. Pilot light. Core pieces, such as the database replica, run continuously in a second region, while application servers are defined but switched off. During a disaster you start them and scale up.
3. Warm standby. A scaled-down but running copy of the full environment sits in the second region and is scaled up on failover. Faster recovery, ongoing cost.
4. Multi-site active-active. Both regions serve live traffic. Potentially minimal downtime, but the highest cost and the greatest engineering complexity, especially for data consistency.

Most businesses are best served by backup and restore or pilot light for the majority of systems, with warm standby for the few that justify it. Active-active is rarely necessary and is easy to get wrong.

Understand the failure scales

Disasters come in different sizes, and your plan should address each:

• Instance or disk failure: handled by auto-recovery and redundant instances.
• Availability zone failure: design applications across multiple zones within a region, which is a basic resilience step that does not need a second region.
• Region failure: rare, but the reason for cross-region copies and standby options.
• Data corruption or deletion: needs point-in-time recovery and versioning.
• Security incident or ransomware: needs immutable or isolated backups, clean-room recovery and credentials the attacker cannot reach.
• Human or deployment error: needs fast rollback, as covered in blue-green and canary deployments.

A frequent insight is that most real incidents are the last three, not a regional outage. Plan for them first.

Building a DR plan step by step

1. Inventory and rank systems. List applications, data stores and dependencies such as DNS, identity and email. Give each a criticality tier.
2. Agree RPO and RTO per tier with the business owners, using the cost of downtime as the guide.
3. Choose a strategy per tier from the four above.
4. Implement backups properly. Automated, versioned, encrypted, stored in a separate account or subscription and ideally a second region, with retention that matches legal and business needs and with deletion protection or immutability where available.
5. Describe infrastructure as code. If your environment is defined in Terraform or similar, rebuilding in another region is a repeatable run rather than a memory exercise.
6. Write runbooks. Step-by-step recovery instructions, with who declares a disaster, who does what, how customers are told and how to fail back.
7. Protect the recovery path itself. Credentials, documentation and tooling must not depend on the environment that has failed.
8. Test, then test again. Restore from backup into a clean environment, run a failover exercise, and record actual recovery times against the targets.
9. Review after every change and every test. Architecture changes quietly invalidate old plans.

What to back up

• Databases, with point-in-time recovery enabled where the platform supports it.
• Object storage, with versioning and a protected copy.
• Virtual machine disks and configuration, if you do not rebuild from code.
• Infrastructure and pipeline code, plus the secrets and keys needed to deploy.
• Configuration of SaaS tools and identity systems.
• Encryption keys. Backups are useless if you lose the key.

Retention is a cost lever as well as a safety one: keeping everything forever is expensive, which is why our cost optimisation guide recommends deliberate retention rules rather than default ones.

Detection and communication

Recovery begins with knowing something is wrong. Good monitoring and alerting shortens the time between failure and response, and RTO usually starts counting from impact, not from the moment someone notices. Prepare communication templates for staff and customers, and decide who authorises a failover, because a hesitant or confused decision costs minutes.

Common mistakes

• Never testing restores. An untested backup is a hope, not a control. Many teams discover corrupt or incomplete backups only during an incident.
• Treating replication as backup. It copies deletions and corruption instantly.
• Keeping backups in the same account and region as production. A compromised account or a regional event can destroy both.
• One RPO and RTO for everything. It either overspends or leaves critical systems exposed.
• Forgetting dependencies. DNS, certificates, identity, third-party APIs and licence servers can block recovery.
• Documentation that lives only in the failed environment. Keep a copy somewhere independent, including offline.
• Ignoring failback. Returning to the primary site needs its own plan and data reconciliation.
• Underestimating restore time. Restoring large datasets takes as long as it takes; measure it.
• Assuming the provider's SLA is your DR plan. An SLA describes service credits, not your recovery.
• Set and forget. Systems change, and the plan must change with them.

A simple readiness checklist

• RPO and RTO agreed and written down for each critical system.
• Backups automated, encrypted, versioned and stored in a separate account and location.
• At least one full restore tested in the last review period, with time recorded.
• Infrastructure reproducible from code.
• Runbooks current, with named roles and contact details.
• Failover or rebuild exercise completed and lessons recorded.
• Communication plan ready.

Summary

Set RPO and RTO with the business, pair replication with isolated, versioned backups, choose the cheapest strategy that meets each system's targets, and test until recovery is routine. If you want a recovery plan built around your actual systems and budget, CloudWiss's cloud and DevOps services include disaster recovery and backup strategies, and our managed support offering also covers backup and recovery.