Backup and restore in GCP - Commands & Configuration

Introduction

Sometimes data can be lost or damaged. Backup and restore help you save a copy of your data and bring it back if needed. This keeps your information safe and available.

When you want to save a copy of your database before making big changes.

When you need to recover data after accidental deletion or corruption.

When you want to move data from one project or region to another.

When you want to keep historical copies of your data for compliance.

When you want to test restoring data to ensure your backup works.

Commands

This command creates a backup of your Cloud SQL instance named 'my-instance'. It saves the current state of your database.

Terminal

gcloud sql backups create --instance=my-instance

Expected Output

Created backup [backup-id] for instance [my-instance].

→

--instance - Specifies the Cloud SQL instance to back up.

This command lists all backups for the 'my-instance' database. It helps you see available backups to restore from.

Terminal

gcloud sql backups list --instance=my-instance

Expected Output

ID          STATUS    ENQUEUED_TIME          START_TIME            END_TIME

backup-id   SUCCESS   2024-06-01T10:00:00Z   2024-06-01T10:05:00Z  2024-06-01T10:10:00Z

→

--instance - Specifies the Cloud SQL instance to list backups for.

This command restores the 'my-instance' database from the backup with ID 'backup-id'. It replaces the current data with the backup data.

Terminal

gcloud sql backups restore backup-id --instance=my-instance

Expected Output

Restoring backup [backup-id] to instance [my-instance].

Restore operation started.

→

--instance - Specifies the Cloud SQL instance to restore the backup to.

This command shows the status of ongoing operations like restore. It helps you check when the restore finishes.

Terminal

gcloud sql operations list --instance=my-instance

Expected Output

ID          TYPE     STATUS    START_TIME            END_TIME

operation-1 RESTORE  RUNNING   2024-06-01T10:15:00Z  

→

--instance - Specifies the Cloud SQL instance to check operations for.

Key Concept

If you remember nothing else from this pattern, remember: always create backups before changes and verify restore success to protect your data.

Common Mistakes

Trying to restore from a backup ID that does not exist.

The restore command will fail because it cannot find the specified backup.

List backups first with 'gcloud sql backups list' and use a valid backup ID.

Not waiting for the restore operation to complete before using the database.

The database may be in an inconsistent state or unavailable during restore.

Check operation status with 'gcloud sql operations list' and wait until it shows success.

Not specifying the correct instance name in commands.

Commands will target the wrong instance or fail if the instance does not exist.

Always use the exact instance name with the --instance flag.

Summary

Use 'gcloud sql backups create' to save a backup of your Cloud SQL instance.

List backups with 'gcloud sql backups list' to find the backup ID you want to restore.

Restore your database using 'gcloud sql backups restore' with the backup ID and instance name.

Check restore progress with 'gcloud sql operations list' to ensure completion.

Practice

1. What is the main purpose of creating a backup in Google Cloud SQL?

easy

A. To save a copy of your database data safely for recovery

B. To increase the speed of your database queries

C. To permanently delete old data from your database

D. To automatically update your database schema

Solution

1. Step 1: Understand backup purpose

   Backups are copies of data saved to protect against data loss.

2. Step 2: Identify backup use in Cloud SQL

   In Cloud SQL, backups allow restoring data if something goes wrong.

3. Final Answer:

   To save a copy of your database data safely for recovery -> Option A

4. Quick Check:

   Backup = Safe data copy [OK]

Hint: Backup means saving data safely for later recovery [OK]

Common Mistakes:

• Confusing backup with performance improvement
• Thinking backup deletes data
• Assuming backup changes database structure

2. Which gcloud command correctly creates an on-demand backup for a Cloud SQL instance named my-instance?

easy

A. gcloud sql backup create --name=my-instance

B. gcloud sql instances backup create my-instance

C. gcloud sql backups create --instance=my-instance

D. gcloud sql create backup --instance=my-instance

Solution

1. Step 1: Recall correct gcloud backup syntax

   The correct command to create a backup is gcloud sql backups create --instance=INSTANCE_NAME.

2. Step 2: Match command to instance name

   Replacing INSTANCE_NAME with my-instance gives the correct command.

3. Final Answer:

   gcloud sql backups create --instance=my-instance -> Option C

4. Quick Check:

   Backup command = gcloud sql backups create [OK]

Hint: Use 'gcloud sql backups create --instance=NAME' to backup [OK]

Common Mistakes:

• Using 'instances backup' instead of 'backups create'
• Incorrect flag names like --name instead of --instance
• Wrong command order or missing 'create'

3. Given this command output snippet after restoring a Cloud SQL backup:

Restoring backup 2024-06-01_12-00 to instance my-instance... DONE

What does this output indicate?

medium

A. The backup was successfully restored to the instance

B. The backup creation failed

C. The instance was deleted

D. The backup is scheduled for later restoration

Solution

1. Step 1: Read the command output carefully

   The message says 'Restoring backup ... DONE', indicating completion.

2. Step 2: Understand the meaning of 'DONE'

   'DONE' means the restore process finished successfully.

3. Final Answer:

   The backup was successfully restored to the instance -> Option A

4. Quick Check:

   Restore output 'DONE' = success [OK]

Hint: Look for 'DONE' to confirm successful restore [OK]

Common Mistakes:

• Confusing restore success with backup failure
• Assuming instance deletion from restore message
• Thinking restore is scheduled, not completed

4. You run the command gcloud sql backups create --instance=my-instance but get an error: ERROR: (gcloud.sql.backups.create) The instance does not support on-demand backups.
What is the most likely cause?

medium

A. You typed the instance name incorrectly

B. The Cloud SQL instance is a First Generation instance which does not support on-demand backups

C. You need to enable billing on your Google Cloud project

D. The backup command requires a different flag for on-demand backups

Solution

1. Step 1: Understand error message about backup support

   The error says the instance does not support on-demand backups.

2. Step 2: Recall Cloud SQL instance generations

   First Generation instances do not support on-demand backups; only Second Generation and later do.

3. Final Answer:

   The Cloud SQL instance is a First Generation instance which does not support on-demand backups -> Option B

4. Quick Check:

   First Gen instances lack on-demand backup support [OK]

Hint: Check instance generation; First Gen lacks on-demand backups [OK]

Common Mistakes:

• Assuming typo in instance name causes this error
• Thinking billing is the cause
• Believing backup flag is incorrect

5. You want to restore a Cloud SQL instance prod-db to a previous state using a backup from June 1, 2024. Which sequence of steps correctly achieves this with minimal downtime?

hard

A. Restore the backup directly to the current instance while it is serving traffic

B. Delete the current instance, then restore the backup to the same instance name immediately

C. Export the backup to Cloud Storage, then import it back to the instance

D. Create a new instance from the backup, then switch your application to use the new instance

Solution

1. Step 1: Understand restore options for minimal downtime

   Restoring directly to a live instance causes downtime; better to create a new instance.

2. Step 2: Create new instance from backup and switch traffic

   Create a new instance restored from backup, then update your app to use it, minimizing downtime.

3. Final Answer:

   Create a new instance from the backup, then switch your application to use the new instance -> Option D

4. Quick Check:

   New instance restore + switch = minimal downtime [OK]

Hint: Restore to new instance, then switch app to avoid downtime [OK]

Common Mistakes:

• Deleting instance before restore causing data loss
• Restoring live instance causing service interruption
• Using export/import which is slower and more complex