Configuring Backup and Disaster Recovery for GCP Workloads

Overview and What You Will Learn

In this lab, you will configure a snapshot schedule for a Persistent Disk, enable automated backups on a Cloud SQL instance, and perform an actual test restore - the step most teams skip, and the one that genuinely proves the backup works.

Why This Matters in Production

A team configures nightly backups for their production database, sees the backup job report success every single night for a year, and only discovers during a real data-loss incident that the backup had actually been silently failing to capture a critical table for months. A completed backup job only proves data was written somewhere - it says nothing about whether that data can actually be restored into a working state.

Core Principles

Backup and disaster recovery in GCP spans several service-specific mechanisms, each protecting a different type of resource, and each needing its own actual restore test to be genuinely trustworthy.

Detailed Step-by-Step Practical Lab

1. Create a project, a disk, and a VM to demonstrate snapshot scheduling:

2. Create a Snapshot Schedule defining daily automated snapshots with a retention period:

3. Attach that schedule to the disk:

4. Trigger a manual snapshot immediately, rather than waiting for the next scheduled run, to have something concrete to restore in this lab:

5. Perform an actual test restore - create a new disk from that snapshot, proving the backup genuinely works:

Note

This restored disk is a completely new, independent disk created from the snapshot's data - attaching it to a test VM and verifying the actual file contents match what was expected is what genuinely proves the backup works, not just the fact that the create-disk-from-snapshot command completed without an error.

6. Create a Cloud SQL instance with automated backups enabled:

7. Trigger an on-demand backup rather than waiting for the scheduled run:

8. List available backups and restore to a new instance to test the restore process:

9. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Configuring backups and never actually performing a test restore. A backup job completing successfully only proves data was written to a snapshot or backup somewhere - it does not prove that data can actually be restored into a working state when it's genuinely needed.

Tip

Schedule a real restore test periodically - quarterly is a reasonable starting cadence for most production workloads - rather than treating backup configuration as a one-time setup task that never needs revisiting.

• Snapshot Schedules and retention policies should match actual business and compliance requirements, not an arbitrary default. A workload with a 7-year regulatory retention requirement needs a policy configured for that, not the default short retention window shown in this lab.
• Cloud SQL's point-in-time recovery only works within the configured retention window, and requires binary logging (--enable-bin-log) to be enabled - without it, only the daily backup snapshots themselves are available for restore, not recovery to an arbitrary point in time between them.

Quick Reference & Troubleshooting Commands