Cloud SQL gives you two distinct ways to preserve your data, and they solve different problems. Backups exist for disaster recovery and restoring an instance to an earlier state. Exports exist for moving or reusing data across environments. The Professional Cloud Database Engineer exam tends to test whether you can tell these two apart, because several of the scenarios it presents could plausibly be answered with either, and the right choice depends on what you are actually trying to do. Getting the distinction clear up front makes most of the related questions straightforward.
A backup captures the full instance disk. It preserves the entire state of your database exactly as it is, and Cloud SQL stores it in its own backup storage that is independent of the instance disks. That separation matters, because it means the backup remains available even if the primary disk fails. Backups are managed by Cloud SQL itself according to retention policies you define, so the service handles creating and deleting them based on your rules. The common use cases are disaster recovery and point-in-time restoration within the service.
An export is different. It produces files that are stored in Cloud Storage, and it can include selected data or specific objects rather than the whole disk. That gives you the flexibility to take only what you need, such as a single table. Because exports live as standard files in Cloud Storage, you can download them or move them to other environments, and you manage their lifecycle yourself using Cloud Storage features like moving older files to colder storage tiers. Exports are commonly automated using Cloud Scheduler and Cloud Run Functions, with an optional Pub/Sub layer, which lets you build event-driven workflows for data movement.
So the short version is that backups are managed by the service and aimed at recovery, while exports are managed by you and aimed at portability. When a question describes restoring an instance after a failure, that points to backups. When it describes moving a subset of data into another environment, that points to exports.
Within backups, Cloud SQL distinguishes between automated and on-demand. Automated backups run daily within a specific four-hour window that you configure, and they protect your data consistently without manual intervention. You can set a retention period anywhere from 1 to 365 days. There is an important limit hiding in that range. If your compliance needs require retaining data beyond a year, automated backups alone will not get you there, and you have to export the backups to Cloud Storage to keep them longer.
On-demand backups cover the case where you need a recovery point outside of your scheduled window. These are manual backups you can create at any time, for example right before a risky schema change. Unlike automated backups, on-demand backups are kept for as long as you need them, so they are not bound by the retention period. That makes them useful when you want to capture a specific database state and hold onto it deliberately. The contrast the exam looks for is that automated backups are scheduled and bound by a 1 to 365 day retention, while on-demand backups are manual and persist until you remove them.
Exports come in two forms as well, and the difference is about where the work runs. A standard export executes directly on the primary instance. It is a straightforward way to move data to Cloud Storage, but because it shares resources with your active database, it is best suited for smaller export operations where the performance impact stays minimal.
A serverless export creates a temporary instance to handle the export, offloading the work so the primary instance is not affected. The tradeoff is that provisioning that temporary instance adds to the total execution time. For large export operations that would otherwise put significant load on your production database, that extra time is worth it, so serverless exports are the better choice for large datasets. When a scenario weighs protecting a busy primary instance against raw speed on a small job, that is the standard versus serverless decision. We would generally lean toward serverless exports whenever the export is large enough that running it on the primary would degrade production performance.
There is one specific behavior in Cloud SQL for PostgreSQL worth committing to memory, because it is the kind of detail the Professional Cloud Database Engineer exam likes to test. Unlogged tables are tables that are not written to the database write-ahead log, which improves their performance. In Cloud SQL, backups exclude unlogged tables to prioritize speed. The consequence is that the data in those tables is simply not present during a standard restore.
To recover that data, you cannot rely on a backup. You have to export the database, which produces a dump file, the exported SQL script of the database, and then edit that file. Inside the dump you insert ALTER TABLE statements to change the affected tables to logged before reloading the data into a new instance.
ALTER TABLE table_name SET LOGGED;In short, to recover unlogged tables you set them to logged in the dump file and then import it. The reason this comes up is that a candidate who assumes backups capture everything will get the wrong answer when an unlogged table is involved, and the correct path runs through an export rather than a restore.
Our Professional Cloud Database Engineer course covers Cloud SQL backups and exports alongside high availability and point-in-time recovery, with practice questions that drill these distinctions.
