GCP Disaster Recovery Strategies: RTO, RPO, Backup, Standby, and Multi-Region

Disaster recovery in GCP, simply explained

High availability and disaster recovery solve different problems. High availability keeps your service running during routine failures: a VM crash, a zone-level outage, a failed deployment. It works automatically and is designed to prevent downtime from ever reaching your users.

Disaster recovery handles the failures that HA cannot. An entire GCP region goes offline. A critical database is corrupted beyond what a single-region replica can fix. A security incident compromises your production environment. DR is not about preventing downtime. It is about recovering within an agreed time window after major downtime has already occurred.

A common misconception is that having backups means you have disaster recovery. Backups protect your data, but they do not restore your service. A Cloud SQL backup sitting in a secondary region does nothing until you provision compute, restore the data, configure the application, update traffic routing, and verify the system works. That full recovery process, not just the data, is what DR planning covers.

RTO and RPO: the two numbers that drive every DR decision

Every DR strategy is built around two targets that your business stakeholders (not your engineering team) must define.

Tighter RPO and RTO cost more. A financial services application processing real-time payments may need RPO of seconds and RTO of minutes, which requires synchronous replication and a hot standby. An internal analytics dashboard may have RPO of 24 hours and RTO of 8 hours, where daily backups and a manual restore process are sufficient. Neither is wrong. They reflect different business requirements and different investment levels.

How to choose a DR strategy

Use this decision table to quickly identify which DR pattern fits each workload. Match the criticality of your system to the recovery speed you need, then look at the cost and GCP services involved.

The four DR strategies in GCP

The industry-standard framing uses four DR patterns: backup and restore, pilot light, warm standby, and active-active. Google Cloud’s own documentation uses a simpler three-tier model (cold, warm, and hot) which maps closely to these four patterns. The table below reconciles both framings.

Backup and restore (cold)

How it works: You take regular backups of your data and application state and store them in a secondary region. When a disaster occurs, you provision infrastructure in that region and restore from the most recent backup. Nothing runs in the DR region during normal operation.

RPO equals your backup frequency. Hourly backups give an RPO of up to 1 hour; daily backups give an RPO of up to 24 hours. RTO is typically 4–24 hours depending on data volume and how long provisioning takes.

GCP implementation: Cloud SQL automated backups with point-in-time recovery (PITR), scheduled persistent disk snapshots copied to a secondary region, Cloud Storage versioning. Use Terraform to define your DR infrastructure so you can provision it quickly when needed. This is the cheapest strategy and is appropriate for non-critical systems or development environments.

Pilot light

How it works: The critical data components are deployed and running continuously in the secondary region at minimum scale. A Cloud SQL cross-region read replica keeps data synchronised. Compute is either absent or deployed at the smallest possible scale. If the primary fails, you scale up the secondary, promote the replica, and redirect traffic.

RPO is typically minutes, determined by the asynchronous replication lag. RTO is 30–60 minutes: the time to scale up compute, promote the database, and verify the environment.

GCP implementation: Cloud SQL cross-region read replica running continuously; minimal or zero Cloud Run instances in the DR region; DNS or load balancer failover configuration pre-built and ready to activate. The ongoing cost is the replica plus minimal compute, which is significantly less than a full warm standby.

Warm standby

How it works: A scaled-down but fully functional copy of your production environment runs continuously in the secondary region. Data replicates in near-real time. Failover means scaling up the standby to production capacity and redirecting traffic, a process that can be largely automated.

RPO is seconds to low minutes (near-real-time replication). RTO is 5–15 minutes.

GCP implementation: Cloud SQL cross-region replica or Firestore multi-region; a production-capable but low-traffic Cloud Run or MIG deployment in the secondary region; Global Load Balancer with the secondary region configured as a failover backend. This costs significantly more than pilot light because you are running real, functional infrastructure continuously.

Active-active multi-region (hot)

How it works: Both regions serve live traffic simultaneously. There is no failover to trigger. If a region fails, the Global Load Balancer automatically shifts traffic to the remaining healthy regions within seconds.

RPO is near-zero with synchronous replication. RTO is seconds to low minutes, fully automatic with no manual steps.

GCP implementation: Cloud Spanner for globally consistent relational data, or Firestore multi-region for document data; Cloud Run or MIG backends in multiple regions behind a Global Load Balancer. See the multi-region architectures guide for a full implementation walkthrough. This is the most expensive strategy and only justified for the strictest RPO/RTO requirements.

GCP services for disaster recovery

Each DR strategy uses a different combination of GCP services. This section maps the key services to their role in a DR plan.

Data protection

Cloud SQL backups and PITR. Enable automated backups with point-in-time recovery on every production Cloud SQL instance. PITR lets you restore to any second within the retention window, not just a daily snapshot. For cross-region protection, export backups to a Cloud Storage bucket in your DR region or create a cross-region read replica. See the Cloud SQL backups and high availability guide for detailed setup.

# Enable automated backups and PITR on Cloud SQL
gcloud sql instances patch my-app-db \
  --backup-start-time=02:00 \
  --retained-backups-count=30 \
  --enable-point-in-time-recovery \
  --project=my-app-prod

Cloud Storage versioning and cross-region replication. Enable object versioning on buckets containing critical data so you can recover deleted or overwritten objects. For geographic redundancy, choose a dual-region or multi-region bucket location. Dual-region buckets with turbo replication target a 15-minute RPO. Default replication targets 99.9% of objects replicated within 1 hour, with a 12-hour RPO for full coverage. Cross-bucket replication provides an alternative for replicating between specific buckets, though without a guaranteed RPO.

Persistent disk snapshots. Schedule incremental snapshots of persistent disks and store them in your DR region. Snapshots are incremental after the first full copy, keeping storage costs manageable.

# Create a daily snapshot schedule
gcloud compute resource-policies create snapshot-schedule daily-backup \
  --region=us-central1 \
  --max-retention-days=30 \
  --daily-schedule \
  --start-time=04:00 \
  --project=my-app-prod

# Attach to a disk
gcloud compute disks add-resource-policies my-data-disk \
  --resource-policies=daily-backup \
  --zone=us-central1-a \
  --project=my-app-prod

Firestore multi-region. Firestore provisioned in a multi-region location replicates data across regions automatically with strong consistency. For document-based workloads that do not need relational semantics, this provides built-in cross-region data protection without additional configuration.

Cloud Spanner. For workloads that require globally consistent relational data with near-zero RPO, Cloud Spanner’s multi-region configurations replicate writes synchronously across regions before acknowledging the commit. This is the strongest RPO guarantee available in GCP, but it comes at a significant cost premium.

Backup and DR Service. Google Cloud’s managed backup service provides centralised backup management across Compute Engine, Cloud SQL, GKE, and third-party databases. It is useful for organisations that need a single pane of glass for backup operations across multiple services.

Standby compute

Cloud Run. Deploy a minimal Cloud Run service in the DR region. During normal operation, set —min-instances=0 to avoid idle costs (pilot light) or —min-instances=2 to keep warm instances ready for faster failover (warm standby). During failover, update the service configuration to point at the promoted database and let it scale to handle production traffic.

Regional managed instance groups. For VM-based workloads, create a managed instance group in the DR region using the same instance template as production. Keep the group at minimum size during normal operation. During failover, scale it up to production capacity. The instance template ensures the DR environment matches production configuration.

Traffic failover

Global Load Balancer. GCP’s Global External HTTPS Load Balancer runs health checks independently against each regional backend. If all backends in the primary region fail health checks, traffic automatically shifts to the next nearest healthy region with no DNS change or manual intervention required. For warm standby and active-active patterns, this is the primary failover mechanism.

Cloud DNS. For architectures that do not use a global load balancer, Cloud DNS supports weighted routing and geographic steering policies. DNS-based failover is simpler to set up but slower to propagate than load balancer failover because of DNS TTL caching.

Automation and monitoring

Terraform and infrastructure as code. Define your DR infrastructure in Terraform or another IaC tool so you can provision it quickly and consistently. For cold DR patterns, this means you can run terraform apply to stand up a full environment in the DR region. For warm and hot patterns, IaC ensures the DR environment stays in sync with production configuration changes.

Cloud Monitoring and alerts. Configure Cloud Monitoring uptime checks against your production endpoints. Set up alerting policies that notify your on-call team immediately when a regional outage is detected. Monitoring is how you know a disaster has occurred. Without it, your DR plan cannot be triggered in time.

How disaster recovery works in GCP

A complete DR plan has five layers. Missing any one of them means your recovery will be slower than expected or will fail entirely.

1. Data protection

Ensure your data survives the loss of the primary region. This means backups stored in a different region, database replicas running in a different region, or a multi-region database that replicates automatically. The method you choose determines your RPO.

2. Standby compute

Data in a secondary region is useless without compute to process it. Depending on your strategy, this ranges from nothing (cold, where you provision on demand) to a full production deployment (hot, already serving traffic). The level of standby compute is the primary driver of both your RTO and your ongoing DR cost.

3. Traffic failover

When the primary region fails, traffic must reach the DR environment. A Global Load Balancer handles this automatically for warm and hot patterns. For cold or pilot light patterns, you may need to update DNS records or load balancer backends manually or via a script. The failover mechanism you choose directly affects your RTO.

4. Configuration and secrets

Restoring compute and data is not enough if the DR environment cannot find its configuration. Environment variables, secrets stored in Secret Manager, service account permissions, SSL certificates, API keys for third-party services, and Cloud Run service definitions must all be available in the DR region. Use infrastructure as code and cross-region secret replication to keep this in sync.

5. Recovery testing

A DR plan that has never been tested is an assumption, not a strategy. Testing validates that all four layers above actually work together. Measured RTO during a drill is the only RTO that matters. Estimated RTO is a guess.

Implementing warm standby failover in GCP

The warm standby pattern for a typical web application has three components working together.

Database: cross-region read replica

Create a Cloud SQL cross-region read replica in the DR region. The replica receives writes from the primary continuously via asynchronous replication. During failover, promote it to a standalone primary.

# Create a cross-region replica
gcloud sql instances create my-app-db-dr \
  --master-instance-name=my-app-db \
  --region=europe-west1 \
  --project=my-app-prod

# Promote to primary during failover (irreversible until re-replication)
gcloud sql instances promote-replica my-app-db-dr \
  --project=my-app-prod

Compute: scaled-down deployment in DR region

Keep a minimal Cloud Run deployment or managed instance group in the DR region. During normal operation it receives no traffic. During failover, update its configuration to point at the promoted database and scale up to production capacity.

Traffic redirection: Global Load Balancer

Add the DR region as a backend on your Global Load Balancer. During failover, remove the primary region’s backends from the backend service or let health checks detect the failure automatically. The Global Load Balancer routes all traffic to the DR backend with no DNS change required.

When to use each strategy

Choosing a DR strategy is easier when you match it to a real workload type rather than thinking abstractly about RTO numbers.

Testing your DR plan

An untested DR plan is not a recovery plan. It is a hypothesis that has never been validated. The most common DR failures in real events are not infrastructure problems. They are operational: the runbook is outdated, a required IAM permission was never granted in the DR project, the database replica stopped replicating three weeks ago, or a step that “should take 5 minutes” takes 45 minutes because of a dependency nobody documented.

Three levels of DR testing

What to validate during every test

• Can you actually access the DR environment? Are IAM permissions, VPN tunnels, and SSH keys in place?
• Does the promoted database contain the data you expect? Check for replication lag and data integrity.
• Does the application in the DR region connect to the promoted database successfully?
• Are secrets, environment variables, and certificates available and current in the DR region?
• Does the load balancer or DNS correctly route traffic to the DR environment?
• Do third-party integrations (payment gateways, email services, monitoring) work from the DR region?

DR runbooks

A complete DR runbook for a GCP application covers every step from detection to verification. Write it so any member of the on-call team can execute it under pressure, not just the system’s primary engineer.

1. Detection and declaration: Who declares the disaster? What signals confirm the primary region is actually unavailable (not a transient issue or false alarm)?
2. Database promotion: Steps to promote the Cloud SQL replica in the DR region, including verification that the promotion completed and the new primary is accepting writes.
3. Application configuration: Steps to update application config in the DR region to point at the promoted database. Include connection strings, Secret Manager references, and environment variables.
4. Compute scale-up: Steps to scale DR compute to production capacity. Update Cloud Run min-instances, scale up the MIG, or trigger a Terraform apply.
5. Traffic redirection: Steps to redirect traffic via the load balancer or DNS. Specify which backends to remove or which DNS records to update.
6. Verification: Smoke tests to confirm the DR environment is serving traffic correctly. Include specific URLs, expected responses, and monitoring dashboards to watch.
7. Communication: Who to notify (customers, internal teams, management), when, and through which channel. Use the incident response framework your team has established.