Disaster recovery strategies in GCP - Commands & Configuration

Introduction

Disaster recovery strategies help you prepare for unexpected problems like data loss or system failures. They make sure your cloud services can quickly recover and keep running with minimal downtime.

When you want to protect your important data from accidental deletion or corruption.

When you need to keep your website or app running even if one cloud region goes down.

When you want to quickly restore your services after a natural disaster or cyber attack.

When you want to test your backup and recovery plans regularly to avoid surprises.

When you want to meet compliance rules that require data protection and recovery plans.

Config File - main.tf

main.tf

provider "google" {
  project = "example-project"
  region  = "us-central1"
}

resource "google_compute_disk" "primary_disk" {
  name  = "primary-disk"
  type  = "pd-standard"
  zone  = "us-central1-a"
  size  = 50
}

resource "google_compute_disk" "backup_disk" {
  name  = "backup-disk"
  type  = "pd-standard"
  zone  = "us-east1-b"
  size  = 50
}

resource "google_compute_snapshot" "disk_snapshot" {
  name       = "primary-disk-snapshot"
  source_disk = google_compute_disk.primary_disk.id
}

resource "google_storage_bucket" "backup_bucket" {
  name     = "example-backup-bucket"
  location = "US"
  versioning {
    enabled = true
  }
}

This Terraform file sets up a primary disk in one zone and a backup disk in another zone for disaster recovery. It creates a snapshot of the primary disk to capture its state. It also creates a storage bucket with versioning enabled to store backups safely.

This setup helps recover data if the primary disk or zone fails.

Commands

This command initializes Terraform in the current directory. It downloads the Google provider plugin and prepares Terraform to manage resources.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/google...

- Installing hashicorp/google v4.0.0...

- Installed hashicorp/google v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!

This command applies the Terraform configuration to create the resources defined in the file. The -auto-approve flag skips the confirmation prompt.

Terminal

terraform apply -auto-approve

Expected Output

google_compute_disk.primary_disk: Creating...

google_compute_disk.backup_disk: Creating...

google_compute_disk.primary_disk: Creation complete after 10s [id=projects/example-project/zones/us-central1-a/disks/primary-disk]

google_compute_disk.backup_disk: Creation complete after 10s [id=projects/example-project/zones/us-east1-b/disks/backup-disk]

google_compute_snapshot.disk_snapshot: Creating...

google_compute_snapshot.disk_snapshot: Creation complete after 5s [id=projects/example-project/global/snapshots/primary-disk-snapshot]

google_storage_bucket.backup_bucket: Creating...

google_storage_bucket.backup_bucket: Creation complete after 3s [id=example-backup-bucket]



Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply without asking for confirmation

This command lists the snapshot created for the primary disk to verify it exists and is ready for recovery.

Terminal

gcloud compute snapshots list --filter="name=primary-disk-snapshot"

Expected Output

NAME                   DISK_NAME      STATUS    CREATION_TIMESTAMP

primary-disk-snapshot  primary-disk  READY     2024-06-01T12:00:00.000-07:00

→

--filter - Filter the list to show only snapshots with the specified name

This command lists the contents and details of the backup storage bucket to confirm backups are stored with versioning.

Terminal

gsutil ls -L gs://example-backup-bucket

Expected Output

gs://example-backup-bucket/: 

    Storage class: STANDARD

    Location constraint: US

    Versioning enabled: True

    Time created: 2024-06-01T11:50:00.000Z

    Labels: None

    Lifecycle: None

    Cors: None

    Logging: None

    Website: None

    Encryption: None

    Retention policy: None

    Default event-based hold: False

    Bucket Policy Only: Disabled

    Uniform bucket-level access: Disabled

    Public access prevention: Unspecified

    Default KMS key: None

    Requester Pays: Disabled

    Owner: [e-mail]

    Project number: 123456789012

Key Concept

If you remember nothing else from this pattern, remember: regularly create backups and store them in a separate location to recover quickly from disasters.

Common Mistakes

Not enabling versioning on the backup storage bucket

Without versioning, you cannot recover previous versions of files if they are overwritten or deleted.

Always enable versioning on backup buckets to keep multiple versions of your data.

Creating snapshots only in the same zone as the primary disk

If the entire zone fails, snapshots in the same zone may be lost or inaccessible.

Store snapshots or backups in a different zone or region to ensure availability during zone failures.

Not verifying backups after creation

Backups might fail silently or be incomplete, leading to failed recovery when needed.

Regularly check and test your backups and snapshots to confirm they are complete and usable.

Summary

Initialize Terraform to prepare for resource management with 'terraform init'.

Apply the configuration to create disks, snapshots, and backup storage with 'terraform apply'.

Verify snapshots exist using 'gcloud compute snapshots list' to ensure recovery points.

Check backup storage bucket details with 'gsutil ls -L' to confirm versioning and data safety.

Practice

1. What is the main goal of a disaster recovery strategy in cloud infrastructure?

easy

A. To improve user interface design

B. To keep services running during unexpected problems

C. To increase the speed of data processing

D. To reduce the cost of cloud services

Solution

1. Step 1: Understand disaster recovery purpose

   Disaster recovery aims to keep systems available and data safe during failures or disasters.

2. Step 2: Identify the main goal

   The main goal is to maintain service uptime and data integrity despite problems.

3. Final Answer:

   To keep services running during unexpected problems -> Option B

4. Quick Check:

   Disaster recovery = keep services safe [OK]

Hint: Disaster recovery means service stays up during trouble [OK]

Common Mistakes:

• Confusing disaster recovery with cost saving
• Thinking it improves speed or UI
• Ignoring service availability

2. Which GCP service is commonly used to store backups for disaster recovery?

easy

A. Cloud Pub/Sub

B. Google Compute Engine

C. Google Kubernetes Engine

D. Google Cloud Storage

Solution

1. Step 1: Identify backup storage service

   Backups need durable, scalable storage. Google Cloud Storage is designed for this.

2. Step 2: Exclude compute and messaging services

   Compute Engine and Kubernetes Engine run workloads, Pub/Sub handles messaging, not backups.

3. Final Answer:

   Google Cloud Storage -> Option D

4. Quick Check:

   Backup storage = Cloud Storage [OK]

Hint: Backups go to Cloud Storage, not compute or messaging [OK]

Common Mistakes:

• Choosing compute services for backup storage
• Confusing messaging service with storage
• Not knowing Cloud Storage purpose

3. Consider this GCP setup code snippet for disaster recovery:

resource "google_compute_instance" "primary" {
  name         = "primary-instance"
  zone         = "us-central1-a"
  machine_type = "e2-medium"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
}

resource "google_compute_instance" "backup" {
  name         = "backup-instance"
  zone         = "us-central1-b"
  machine_type = "e2-medium"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
}

What is the main benefit of this configuration for disaster recovery?

medium

A. It creates two instances in different zones to improve availability

B. It reduces the cost by using smaller machines

C. It backs up data automatically to Cloud Storage

D. It enables faster network speed between instances

Solution

1. Step 1: Analyze instance zones

   The two instances are in different zones (us-central1-a and us-central1-b), which protects against zone failure.

2. Step 2: Identify disaster recovery benefit

   Having instances in separate zones improves availability and fault tolerance during disasters.

3. Final Answer:

   It creates two instances in different zones to improve availability -> Option A

4. Quick Check:

   Multi-zone instances = better availability [OK]

Hint: Different zones mean better uptime during failures [OK]

Common Mistakes:

• Assuming cost reduction is main goal
• Thinking data backup happens automatically
• Confusing network speed with disaster recovery

4. You have a disaster recovery plan that uses snapshots for backups. After a disaster, the recovery fails because snapshots are missing. What is the most likely error?

medium

A. Snapshots were stored in the same zone as the primary data

B. Snapshots were not scheduled regularly

C. Snapshots were encrypted with the wrong key

D. Snapshots were created from the wrong disk

Solution

1. Step 1: Understand snapshot storage risk

   If snapshots are stored only in the same zone, a zone failure can destroy both primary data and backups.

2. Step 2: Identify cause of missing snapshots

   Storing snapshots in the same zone risks losing them during a disaster affecting that zone.

3. Final Answer:

   Snapshots were stored in the same zone as the primary data -> Option A

4. Quick Check:

   Backups must be in different zones [OK]

Hint: Backups in same zone vanish with disaster [OK]

Common Mistakes:

• Ignoring backup location importance
• Assuming encryption or disk choice caused failure
• Not scheduling snapshots regularly

5. You want to design a disaster recovery plan for a critical GCP application that must recover within minutes after a regional outage. Which combination of strategies is best?

hard

A. Use multi-zone deployment with weekly snapshots and manual recovery

B. Use single-zone deployment with daily manual backups to Cloud Storage

C. Use multi-region deployment with automated failover and continuous data replication

D. Use single-region deployment with monthly backups and no failover

Solution

1. Step 1: Identify recovery time objective (RTO)

   Recovery within minutes requires fast failover and minimal data loss.

2. Step 2: Evaluate strategies for fast recovery

   Multi-region deployment with automated failover and continuous replication ensures quick switch and up-to-date data.

3. Step 3: Compare with other options

   Single-zone or single-region with manual backups are slower and risk data loss; weekly or monthly backups are too infrequent.

4. Final Answer:

   Use multi-region deployment with automated failover and continuous data replication -> Option C

5. Quick Check:

   Fast recovery needs multi-region + automation [OK]

Hint: Fast recovery needs multi-region and automation [OK]

Common Mistakes:

• Choosing single-zone or single-region for critical apps
• Relying on manual backups for quick recovery
• Ignoring continuous data replication