Backup and restore in GCP - Time & Space Complexity
When backing up and restoring data in the cloud, it's important to know how the time needed changes as the data size grows.
We want to understand how the number of operations or API calls increases when we handle more data.
Analyze the time complexity of the following operation sequence.
// Backup and restore sequence in GCP
const backup = await gcp.storage.createBackup(bucketName, backupName);
const files = await gcp.storage.listFiles(bucketName);
for (const file of files) {
await gcp.storage.copyFile(file, backupName);
}
await gcp.storage.restoreBackup(backupName, bucketName);
This sequence creates a backup, copies each file to the backup, then restores the backup to the original bucket.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Copying each file to the backup storage.
- How many times: Once for every file in the bucket.
As the number of files grows, the number of copy operations grows at the same rate.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | About 10 copy operations |
| 100 | About 100 copy operations |
| 1000 | About 1000 copy operations |
Pattern observation: The operations increase directly with the number of files.
Time Complexity: O(n)
This means the time grows in direct proportion to the number of files being backed up or restored.
[X] Wrong: "Backing up many files takes the same time as backing up one file because it's just one backup operation."
[OK] Correct: Each file must be copied individually, so more files mean more copy operations and more time.
Understanding how backup and restore operations scale helps you design efficient cloud solutions and shows you can think about real-world system behavior.
"What if we changed the backup to copy files in parallel instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand backup purpose
Backups are copies of data saved to protect against data loss.Step 2: Identify backup use in Cloud SQL
In Cloud SQL, backups allow restoring data if something goes wrong.Final Answer:
To save a copy of your database data safely for recovery -> Option AQuick Check:
Backup = Safe data copy [OK]
- Confusing backup with performance improvement
- Thinking backup deletes data
- Assuming backup changes database structure
gcloud command correctly creates an on-demand backup for a Cloud SQL instance named my-instance?Solution
Step 1: Recall correct gcloud backup syntax
The correct command to create a backup isgcloud sql backups create --instance=INSTANCE_NAME.Step 2: Match command to instance name
Replacing INSTANCE_NAME withmy-instancegives the correct command.Final Answer:
gcloud sql backups create --instance=my-instance -> Option CQuick Check:
Backup command = gcloud sql backups create [OK]
- Using 'instances backup' instead of 'backups create'
- Incorrect flag names like --name instead of --instance
- Wrong command order or missing 'create'
Restoring backup 2024-06-01_12-00 to instance my-instance... DONE
What does this output indicate?
Solution
Step 1: Read the command output carefully
The message says 'Restoring backup ... DONE', indicating completion.Step 2: Understand the meaning of 'DONE'
'DONE' means the restore process finished successfully.Final Answer:
The backup was successfully restored to the instance -> Option AQuick Check:
Restore output 'DONE' = success [OK]
- Confusing restore success with backup failure
- Assuming instance deletion from restore message
- Thinking restore is scheduled, not completed
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?
Solution
Step 1: Understand error message about backup support
The error says the instance does not support on-demand backups.Step 2: Recall Cloud SQL instance generations
First Generation instances do not support on-demand backups; only Second Generation and later do.Final Answer:
The Cloud SQL instance is a First Generation instance which does not support on-demand backups -> Option BQuick Check:
First Gen instances lack on-demand backup support [OK]
- Assuming typo in instance name causes this error
- Thinking billing is the cause
- Believing backup flag is incorrect
prod-db to a previous state using a backup from June 1, 2024. Which sequence of steps correctly achieves this with minimal downtime?Solution
Step 1: Understand restore options for minimal downtime
Restoring directly to a live instance causes downtime; better to create a new instance.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.Final Answer:
Create a new instance from the backup, then switch your application to use the new instance -> Option DQuick Check:
New instance restore + switch = minimal downtime [OK]
- Deleting instance before restore causing data loss
- Restoring live instance causing service interruption
- Using export/import which is slower and more complex
Ready to prove it?
Pass the test and this pattern moves unknown
