Cloud Hosting Disaster Recovery: Building a Real Backup Plan

Most cloud hosting buyers treat disaster recovery the way people treat estate planning—something they will get around to eventually. The cloud feels permanent. The dashboard shows green checkmarks. The provider's SLA promises 99.99% uptime. And then a misconfigured deployment pipeline deletes a production database, or a ransomware attack encrypts every object in an S3 bucket, or the provider itself suffers a regional outage that takes down the control plane along with the data plane. At that moment, the difference between a business that recovers in hours and one that never recovers at all is a cloud hosting disaster recovery plan that was built before it was needed.

At HostingCaptain, we have helped businesses rebuild after disasters of every category—human error, malicious attack, provider failure, and natural catastrophe. The patterns are consistent: the businesses that survive had tested backups, documented procedures, and infrastructure designed for recovery. Those that failed had backups, but they were in the same region as the primary data, or they had never been tested, or the documentation for restoring them existed only in the mind of an engineer who had left the company six months earlier.

This guide explains the principles and practices of building a disaster recovery plan that works when it has to, drawing on the architectural patterns that major providers recommend and the lessons learned from real incidents. For background on the infrastructure that underpins cloud hosting, see Cloudflare's cloud explainer and our dedicated server guide, which covers the physical infrastructure complement to cloud environments.

Defining Disaster Recovery for Cloud Hosting

Disaster recovery (DR) is the set of policies, tools, and procedures that enable the restoration of IT services after a disruptive event. It is distinct from high availability (HA), which is about preventing downtime through redundancy, and from backup, which is about preserving data. DR is the process of turning backups and redundant infrastructure back into a working service. A business can have excellent backups and still fail at disaster recovery if the restore process is undocumented, untested, or reliant on components that are themselves affected by the disaster.

Two metrics define the quality of a DR plan. Recovery Time Objective (RTO) is the maximum acceptable duration between the onset of a disaster and the restoration of service. Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, measured in time—an RPO of one hour means you can tolerate losing up to 60 minutes of data, but no more. RTO and RPO are business decisions, not technical ones. A financial trading platform may need an RTO of under 60 seconds and an RPO near zero, while a portfolio website might accept an RTO of 24 hours and an RPO of 24 hours. The cost of achieving tighter objectives grows exponentially, so defining them honestly prevents over-engineering a DR plan that costs more than the downtime it prevents.

The Shared Responsibility Model and DR

Cloud hosting operates under a shared responsibility model. The provider is responsible for the security and availability of the cloud infrastructure—the physical data centers, the hypervisors, the network fabric, the storage systems. The customer is responsible for what they put in the cloud—the data, the application configuration, the access controls, and the backup strategy. When a cloud provider experiences a regional outage, that is the provider's responsibility. When a customer accidentally deletes a database, that is the customer's responsibility, and the provider's backup tools may or may not cover it depending on which services were used.

The shared responsibility model has a dangerous corollary: many cloud customers assume that because the provider is a multi-billion-dollar company with world-class infrastructure, their data is safe by default. It is not. AWS will not prevent you from deleting a DynamoDB table. Google Cloud will not stop you from overwriting a production Cloud SQL instance with a staging dump. These are customer-side operations that the provider's SLAs do not cover. Your DR plan is your responsibility alone. Our comparison of cloud vs VPS scalability covers how different hosting models distribute responsibility between provider and customer.

Backup Architecture: The Foundation of DR

A backup is not a disaster recovery plan, but a DR plan without backups is a hope, not a plan. The backup architecture must satisfy three requirements: durability (the backups survive the disaster that takes down the primary data), recoverability (the backups can be restored to a working state), and testability (the restore process is regularly exercised and documented). Most backup implementations satisfy durability and fail on recoverability and testability.

The 3-2-1 Backup Rule, Applied to Cloud

The 3-2-1 rule—three copies of data, on two different media types, with one copy off-site—is the minimum viable backup strategy. In cloud terms, this means: the primary data in your production region, a snapshot or replica in a different availability zone within the same region (fast recovery, but vulnerable to regional disasters), and a backup in a different cloud region or a different cloud provider entirely. The third copy is the one that survives when the entire region goes dark.

Region-level disasters are not hypothetical. In 2021, a fire at an OVHcloud data center in Strasbourg destroyed the primary data and the in-region backups of thousands of customers. Those with off-region backups recovered. Those without did not. An S3 bucket in us-east-1 that replicates objects to another bucket in us-east-1 is not following the 3-2-1 rule. Cross-region replication to us-west-2 or a completely different provider's object storage meets the rule.

Database Backup Specifics

Database backups require more thought than file backups because a database is a moving target—writes are happening continuously, and a backup taken at a single point in time may be inconsistent if the database was mid-transaction when the snapshot occurred. Most managed cloud databases (RDS, Cloud SQL, Azure Database) offer automated snapshots with point-in-time recovery that uses write-ahead logs to reconstruct the database to any second within the retention window, typically 7–35 days. These are excellent for recovering from human errors like a dropped table but are insufficient as a sole DR strategy because they usually reside in the same region as the primary database.

A complete database DR plan includes: automated snapshots for quick rollback, logical backups (pg_dump, mysqldump) exported to object storage in a separate region on a daily schedule, and for databases where RPO is measured in seconds, continuous log shipping to a standby instance in a separate region. The logical backup, while slower to restore, is portable across cloud providers and database versions, making it the ultimate insurance policy against provider lock-in during a disaster.

Object Storage and Static Assets

Object storage (S3, GCS, Blob Storage) is designed for 99.999999999% durability (11 nines), which means data loss due to hardware failure is practically impossible. However, object storage data can still be lost through accidental deletion, malicious action, or a bug in an application that overwrites objects with incorrect data. Enabling versioning on buckets preserves every version of every object, allowing recovery from deletions and overwrites. Cross-region replication copies objects to a bucket in another region, providing geographic redundancy. Both features should be enabled for any bucket that contains irreplaceable data.

Infrastructure as Code: The Other Half of DR

Data is half the recovery challenge. The other half is the infrastructure that serves that data: the virtual machines, load balancers, DNS records, firewall rules, and network configurations that must be recreated in a recovery region. Manually reconstructing infrastructure from memory during a disaster guarantees an extended outage and a high probability of misconfiguration. Infrastructure as Code (IaC)—using tools like Terraform, Pulumi, or AWS CDK to define infrastructure in declarative configuration files—solves this problem by making the infrastructure definition a version-controlled, reproducible artifact.

A well-structured IaC repository enables the following DR scenario: the primary region is unavailable. An engineer runs a single command that provisions an identical environment in the recovery region—the same VPC layout, the same instance types, the same security groups, the same load balancer configuration—in under 30 minutes. The database is restored from the cross-region backup. The DNS record is updated to point to the new load balancer endpoint, with a low TTL that propagates quickly. The application is back online before the business has finished assessing the scope of the outage.

This scenario is achievable today with moderate IaC investment, but it requires that the IaC repository be maintained in sync with the actual infrastructure. A Terraform state file that drifted from reality six months ago is worse than no IaC at all, because it will provision an environment that does not match production, and the resulting configuration errors will compound the outage. Drift detection tools, automated apply pipelines, and a culture of "all changes through IaC" prevent this scenario. Our analysis of data center standards explains how physical infrastructure considerations interact with cloud DR decisions, particularly when hybrid architectures are involved.

Ransomware and Security-Centric DR

Ransomware attacks targeting cloud-hosted applications increased significantly in 2025–2026, often exploiting compromised API keys or overly permissive IAM roles to encrypt data in place. Cloud-native ransomware does not need to exfiltrate data; it needs only to encrypt it and demand payment for the decryption key. Because cloud storage is accessible from anywhere with valid credentials, a compromised access key can encrypt terabytes of S3 objects or delete database snapshots within minutes.

Defending against ransomware in the cloud requires immutable backups—backups that cannot be modified or deleted, even by an attacker with full administrative access to the account. AWS Backup Vault Lock, GCP's retention policy locks, and Azure's immutable blob storage all provide this capability. Once a backup is written to a locked vault with a compliance-mode retention policy, it cannot be deleted or modified by anyone within the retention period, including the root account. This is the strongest defense against ransomware: the attacker can encrypt the production data, but they cannot touch the backup vault, and recovery proceeds from a known-clean snapshot.

IAM hygiene is the other half of ransomware defense. The principle of least privilege—granting each service, each user, and each application the minimum permissions required to function—limits the blast radius of a compromised credential. A web application that has write access to a single S3 bucket prefix can only encrypt objects within that prefix. A web application that has s3:* on * can encrypt every bucket in the account. The difference in recovery effort between those two scenarios is measured in weeks. Our exploration of AI hosting trends covers the security implications of increasingly autonomous cloud infrastructure.

Testing: The Missing Step in Every DR Plan

A disaster recovery plan that has never been tested is not a plan. It is a theory. At HostingCaptain, we have seen organizations invest months in designing DR architectures that fell apart on the first test because of a dependency nobody documented—a DNS record managed by a former employee's personal account, a TLS certificate issued by a CA that does not support the recovery region, a third-party API that rate-limits connections from unexpected IP ranges.

DR testing should follow a graduated approach. Tabletop exercises, where the team walks through the recovery procedure without touching infrastructure, identify documentation gaps and missing dependencies at zero risk. Simulated failover tests, where a non-production environment is failed over to the recovery region, validate the IaC, the backup restore procedure, and the application's ability to function in a new environment. Full-scale production failover tests are the gold standard but are disruptive and expensive; most organizations perform them annually or semi-annually and schedule them during maintenance windows.

The output of every DR test should be a list of issues, ranked by severity, with owners and deadlines. An issue that blocks recovery during a test and is not fixed before the next test represents organizational acceptance of that failure mode during a real disaster. Tracking DR test issues to resolution is the difference between a DR program that improves over time and one that goes through the motions.

Multi-Cloud DR: Ultimate Redundancy or Ultimate Complexity?

The most resilient DR architecture is one that spans multiple cloud providers. If AWS us-east-1 goes offline, the application can fail over to Azure East US or Google Cloud us-east4, running from backups stored in a provider-neutral format. Multi-cloud DR eliminates the single-provider failure mode that even the best single-cloud DR plan cannot address.

The cost of multi-cloud DR is complexity. Every cloud provider abstracts infrastructure differently. A Terraform configuration that provisions an AWS environment does not provision an Azure environment—it must be rewritten for each provider. Database backups are provider-agnostic (a pg_dump is a pg_dump), but managed database restore procedures are not (RDS restore and Cloud SQL restore use different APIs and produce different endpoint formats). The operational overhead of maintaining IaC for multiple providers, training the team on multiple ecosystems, and testing failover to multiple destinations may exceed the incremental risk reduction compared to a well-executed single-provider multi-region DR plan.

For most organizations, a multi-region strategy within a single cloud provider provides an appropriate balance of resilience and complexity. The exceptions are organizations where a cloud provider outage is an existential threat—financial exchanges, emergency services, large-scale e-commerce platforms during peak sales periods—and even then, a cost-benefit analysis should drive the decision rather than an abstract desire for maximum resilience. Our cloud vs VPS comparison covers the scalability and resilience dimensions of different hosting architectures.

FAQ

What is the difference between backup and disaster recovery?

Backup is the process of copying data to a secondary location so it can be restored if the primary copy is lost. Disaster recovery is the comprehensive process of restoring IT services after a disruptive event, which includes restoring data from backups but also includes provisioning infrastructure, reconfiguring networks, updating DNS, and validating that the restored environment is functional.

How often should I test my disaster recovery plan?

Tabletop exercises should be conducted quarterly. Simulated failover of a non-production environment should be conducted semi-annually. Full production failover should be conducted annually. The schedule may be adjusted based on how frequently the environment changes—an environment that deploys daily needs more frequent DR testing than one that deploys monthly.

Are cloud provider snapshots sufficient for disaster recovery?

No. Provider snapshots are typically stored in the same region as the primary data, making them vulnerable to regional disasters. They are useful for recovering from human errors and application bugs but should be supplemented by cross-region backups in a different geographic location for true DR coverage.

What is immutable backup and why does it matter?

Immutable backups are backups that cannot be modified or deleted for a specified retention period, even by users with administrative privileges. This protects against ransomware attacks where an attacker with compromised credentials attempts to delete backups to prevent recovery. Most major cloud providers offer immutable backup features through vault lock mechanisms.

How much does a disaster recovery plan cost?

The cost depends on RTO and RPO targets. A warm standby environment in a recovery region that can fail over in minutes incurs near-production infrastructure costs continuously. A cold DR strategy that restores from backups on demand costs only the backup storage (typically $0.02–$0.05 per GB per month) plus the compute cost during recovery. Most businesses should start with a cold DR strategy and invest in warmer recovery only when RTO targets require it.

What is the first step in building a DR plan?

Define your RTO and RPO with business stakeholders, not just the technical team. These numbers determine every subsequent architectural and financial decision. Then inventory every service, every data store, and every external dependency, noting which are critical (must be recovered to meet RTO) and which are non-critical (can be recovered later). The critical path defines the scope of the DR plan.

Disaster recovery is the least rewarding investment in hosting infrastructure—until the day it becomes the only investment that matters. At HostingCaptain, we have seen the full arc of this truth play out: the months of preparation that feel unnecessary, the disaster that arrives without warning, and the recovery that takes hours instead of weeks because the plan was in place. The cloud does not eliminate disasters. It changes their nature. The preparation required to survive them remains, at its core, a human discipline: write it down, test it regularly, and keep it current. Everything else is detail.