Cloud SQL gives you two layers of data protection that the Professional Cloud Architect exam expects you to understand. Point-in-time recovery lets you rewind a database to any past state, and the backup system gives you scheduled and on-demand copies you can restore from. They solve different problems, and the exam questions usually hinge on knowing which one to reach for.
Point-in-time recovery, or PITR, lets you restore a Cloud SQL database to any specific moment in the past. That moment can be a few minutes ago, or it can be days back if you have configured retention to keep the necessary logs. The use case is the kind of incident where a backup is too coarse. Someone runs a bad UPDATE without a WHERE clause, an application bug corrupts rows for an hour before anyone notices, or a deployment writes garbage data. A nightly backup snaps you back to the previous night. PITR lets you snap back to one minute before the bad statement ran.
Cloud SQL implements PITR using transaction logs from the underlying database engine. The mechanism differs by engine, and the exam can ask about the distinction.
For Cloud SQL for MySQL, PITR uses binary logging. Binary logs record every change made to the database in a binary format, written after each transaction commits. Every INSERT, UPDATE, and DELETE that lands in the database is captured in the binary log as a replayable event. To recover to a specific point, Cloud SQL takes the most recent automatic backup before that point and replays the binary log forward up to the timestamp you choose.
For Cloud SQL for PostgreSQL, PITR uses write-ahead logging, abbreviated WAL. Write-ahead logging is the inverse pattern. Changes are written to the log first, before they are applied to the database files themselves. The database guarantees that nothing is committed unless it has been durably recorded in the WAL, which is what gives PostgreSQL its crash recovery story. For PITR purposes, Cloud SQL keeps these WAL segments around so it can replay them on top of a base backup to reach any point you ask for.
The shared idea is that both engines maintain a continuous, ordered record of every change. PITR works because that record exists. Without it, the best you can do is restore the most recent backup, which loses everything written after that backup ran.
Cloud SQL has three distinct backup mechanisms, and the Professional Cloud Architect exam expects you to know the differences between them.
The first is automatic backups. You configure a 4-hour daily window, and Cloud SQL takes a backup once per day inside that window. Retention defaults to seven days, meaning the last seven daily backups are kept and older ones are pruned. Automatic backups are the default protection layer for any production Cloud SQL instance, and you generally want them on. They are also what PITR builds on, because PITR needs a base backup to apply transaction logs against.
The second is manual backups. You trigger these on demand, at any time, with no schedule. Manual backups are retained until you delete them. They are the right tool before any risky operation, like a major schema migration, a data import that might go sideways, or a version upgrade.
The third is scheduled exports to Cloud Storage. This is the one that gets confused on the exam. Automatic backups are stored inside Cloud SQL, which is fine for normal operations but limited for compliance scenarios. The seven-day default retention is short, and even if you extend it, the backups still live inside the Cloud SQL service. If you have a regulatory requirement to keep database snapshots for years, or you want them in a separate storage layer for disaster recovery, you export them to Cloud Storage. From there you can apply object lifecycle policies, move them to Coldline or Archive storage classes, and keep them for as long as the policy demands.
A few patterns repeat. If a question describes accidental data loss that happened at a specific time, and the requirement is to recover the database without losing recent transactions, the answer is point-in-time recovery, not a backup restore. If a question asks about long-term retention beyond seven days for compliance, the answer is exporting backups to Cloud Storage, not extending the automatic backup retention. If a question asks about the underlying mechanism that enables PITR, the answer is binary logging for MySQL and write-ahead logging for PostgreSQL.
The other thing to remember is that PITR is not free in storage terms. Keeping enough transaction log history to support recovery to any point over a long window costs storage, and that storage scales with how active your database is. For the Professional Cloud Architect exam this rarely matters, but knowing it exists is the kind of detail that distinguishes a question about appropriate retention windows.
My Professional Cloud Architect course covers Cloud SQL point-in-time recovery and backups alongside the rest of the databases material.
