GCP Landing Zone Series — Part 6a: Backup and DR by Application Tier How Google Cloud Backup and DR…

GCP Landing Zone Series — Part 6a: Backup and DR by Application Tier How Google Cloud Backup and DR implements the four-tier framework — and why resilience is designed in, not bolted on. The Series Part 1a — Resource Hierarchy and Application Tiering Part 1b — IAM Strategy and Workforce Identity Part 2 — Hybrid Network Architecture Part 3 — Enterprise DNS Architecture Part 4 — Security Controls That Cannot Be Bypassed Part 5 — Governance at Enterprise Scale Part 6a — Backup and DR by Application Tier (this article) Part 6b — Enterprise Billing and the Complete Landing Zone Resilience Is Not the Same as Availability Availability is keeping systems running. Resilience is recovering quickly when they fail. Most enterprises focus on availability — uptime SLAs, redundant VMs, multi-zone deployments. These matter. But they do not answer the question that matters most when something breaks: How fast can we recover? How much data do we lose? If the answer is "it depends on which team set up the backup" or "we think there is a snapshot somewhere" — you do not have resilience. You have hope. Resilience is not hope. It is a set of deliberate design decisions made before the first workload moves. Not after.

Why Backup Cannot Be an Afterthought In most enterprises backup is configured after migration. A workload moves to GCP. Someone remembers to set up a snapshot schedule. Maybe. Sometimes the schedule is daily. Sometimes it is weekly. Sometimes nobody remembers at all. Six months later an incident occurs. The team discovers the last backup was three weeks ago. Or the backup exists but has never been tested. Or the backup is in the same region as the failed workload — and the region is down. The fix is not better backup tools. It is classifying every workload before migration and automatically applying the correct backup policy at deployment time. No manual configuration. No missed workloads. No inconsistencies. This is what application tiering enables.

The Four-Tier Backup Framework Part 1a defined the four-tier application framework. Every workload is classified by business criticality through a joint decision between business and IT. The tier then drives the backup and DR strategy automatically. Tier 1 — Mission Critical Examples: ERP, payment processing, customer-facing APIs, supply chain execution Backup frequency: Continuous replication — real time Retention: 30 days minimum Storage: Multi-region Cloud Storage DR strategy: Active-passive cross-region — failover to secondary region RTO: Less than 8 hours RPO: Less than 4 hours DR test frequency: Quarterly DR runbook: Mandatory — tested every quarter Continuous replication means every write is replicated to the DR region in near real-time. When a failure occurs the secondary region has data that is minutes old — not hours or days. Cross-region DR means the backup is in a completely different Google Cloud region. A regional outage — natural disaster, power failure, network partition — does not affect the backup.

Tier 2 — Business Important Examples: Reporting systems, internal portals, HR systems, analytics platforms Backup frequency: Every 4 to 6 hours Retention: 14 days Storage: Regional Cloud Storage DR strategy: Single region — restore from backup RTO: Less than 24 hours RPO: Less than 8 hours DR test frequency: Bi-annual DR runbook: Mandatory — tested twice a year Tier 2 workloads can tolerate up to 8 hours of data loss. Backup every 4 to 6 hours ensures the RPO is always met. Regional storage is sufficient because the DR strategy is restore-in-place — not failover to another region.

Tier 3 — Standard Examples: Internal tools, batch jobs, administrative systems Backup frequency: Daily Retention: 7 days Storage: Regional Cloud Storage DR strategy: Restore from most recent daily snapshot RTO: Less than 48 hours RPO: Less than 24 hours DR test frequency: Annual DR runbook: Recommended Tier 3 workloads are important but not urgent. A daily snapshot with 7 day retention provides sufficient protection. Recovery from the most recent snapshot is acceptable — the business can tolerate up to 24 hours of data loss. Tier 4 — Dev/Test Examples: Development environments, test environments, CI/CD pipelines Backup frequency: None Retention: None Storage: None DR strategy: Terraform redeploy — recreate from code RTO: Best effort RPO: Best effort DR test frequency: Not required DR runbook: Not required Tier 4 workloads have no backup. They are ephemeral. If a development environment fails it is recreated from Terraform in minutes. No data worth preserving. No recovery time

commitment. This is also where Spot VMs are used. 60 to 90% cheaper than standard VMs. Can be preempted with 30 seconds notice. Acceptable for development — unacceptable for production.

Google Cloud Backup and DR Google Cloud Backup and DR is the managed service that implements these policies. It is not a standalone backup tool — it is a policy engine that enforces backup governance at scale. Centralized management. All backup policies across all projects managed from one console. The platform team defines policies. Workloads inherit the correct policy based on their tier tag. Policy-based. Define a backup policy once — frequency, retention, storage location, consistency type. Apply it to all resources matching specific labels. Every Tier 1 workload gets the Tier 1 policy automatically. No manual configuration per workload. Application-consistent backups. For databases — Cloud SQL, PostgreSQL, MySQL — backups are application-consistent. The database is in a consistent state when the backup is taken. No corrupted backups from mid-transaction snapshots. Immutable backup storage. Backups cannot be deleted during the retention period. This protects against ransomware. An attacker who compromises a GCP identity cannot delete backups to prevent recovery. The immutability is enforced at the storage layer — not just IAM. Cross-region backup. Tier 1 backups are stored in a different region from the production workload. Regional failure does not affect backup availability.

DR Runbooks — Why Documentation Without Testing Is Worthless Every Tier 1 and Tier 2 application has a documented DR runbook. The runbook answers five questions: What is the recovery sequence? Which systems come up first? What dependencies must be restored before this application? Where is the backup? Which region? Which storage bucket? What credentials are needed to access it? Who executes the recovery? The Technical Owner — not the platform team. The person who operates the application daily is the person who recovers it. How long does recovery take? Validated through actual DR tests — not estimated from documentation. What is the communication plan? Who is notified? What status updates are provided? When is the all-clear given? DR tests are production events. Quarterly DR tests for Tier 1 applications require change management approval. They have a defined rollback plan. Results are documented in a post-test report. Findings are remediated before the next test. A DR runbook that has never been tested will fail when needed. The test is what validates the runbook — not the documentation.

Backup as Code — Terraform Backup policies are defined in Terraform. Not configured manually in the console. Not set up by individual teams with different standards. The Terraform backup module accepts the application tier as a variable and applies the correct policy automatically: Tier tag on the project — tier-1, tier-2, tier-3, tier-4 Terraform module reads the tier tag Applies the matching backup policy — frequency, retention, storage, DR strategy Creates monitoring alerts for backup job failures Why this matters: No missed workloads. Every new project with a tier tag gets backup automatically at deployment time. Consistency. Every Tier 1 workload gets identical backup configuration. No drift between teams. Auditability. Backup configuration is version controlled. Every change goes through pull request review. Auditors can see exactly what backup policy applies to every workload. Recovery from code. If the backup infrastructure itself needs to be recreated — the Terraform code recreates it identically.

Backup monitoring integration. Failed backup jobs trigger immediate alerts via Cloud Monitoring: Tier 1 — Critical alert to Technical Owner and platform team. PagerDuty. Immediate response. Tier 2 — High alert to Technical Owner. Same day investigation. Tier 3 — Standard alert. Next business day review. Tier 4 — No backup monitoring. No alerts. A missed backup on a Tier 1 workload is treated as a critical incident — not an operational inconvenience. The SLA for investigating a failed Tier 1 backup is the same as investigating a production outage.

What’s Next — Part 6b: Enterprise Billing and the Complete Landing Zone The final article in this series covers the enterprise billing architecture — hub and spoke billing model, BigQuery FinOps reporting, budget alerts at three levels — and brings the entire five-phase Landing Zone framework together.