An enterprise application utilizing Cloud SQL for PostgreSQL experienced data corruption due to an accidental table deletion at 14:15:00 UTC. Point-in-time recovery (PITR) via write-ahead logging is active on the instance `db-main`. You must restore the database to its exact state at 14:14:00 UTC into a new instance and cut over production traffic while retaining the original instance for post-mortem inspection.
In what order should you execute these operational recovery steps?
- 1Identify the target UTC timestamp (14:14:00 UTC) immediately preceding the table deletion.
- 2Run `gcloud sql instances clone db-main db-recovery --point-in-time="2026-07-30T14:14:00.000000Z"` to provision the restored instance.
- 3Execute validation queries on `db-recovery` to confirm table structure and data completeness.
- 4Update application connection strings and DNS entries to direct database traffic to `db-recovery`.
Answer
The correct sequence of operations is: 1) Identify the target pre-corruption timestamp (14:14:00 UTC), 2) Clone the instance to `db-recovery` at that point in time using the `gcloud sql instances clone` command with the `--point-in-time` flag, 3) Perform data integrity validation on `db-recovery`, and 4) Update application connection parameters to redirect production traffic to `db-recovery`.
Point-in-Time Recovery (PITR) in Cloud SQL for PostgreSQL is performed by cloning the source instance into a new target instance using `gcloud sql instances clone` with the `--point-in-time` parameter. The workflow requires identifying the timestamp prior to corruption first, running the clone command second, validating data integrity on the new instance third, and updating application connection strings fourth.
Step-by-Step Solution
Key Concept
Cloud SQL Point-in-Time Recovery (PITR) and Instance Cloning Workflow