When you create a new instance in the Google Cloud console, bothautomated backupsandpoint-in-time recovery (PITR)are automatically enabled. You can configure PITR for any existing instance by
doing the following:
Open the more actions menufor the instance you
want to enable PITR on and clickEdit.
UnderCustomize your instance, expand theData Protectionsection.
Select theEnable point-in-time recoverycheckbox.
In theDays of logsfield, enter the number of days to retain
logs, from 1-35 for Cloud SQL Enterprise Plus edition, or 1-7 for Cloud SQL Enterprise edition.
ClickSave.
gcloud
Display the instance overview:
gcloudsqlinstancesdescribeINSTANCE_NAME
If you seeenabled: falsein thebackupConfigurationsection, enable scheduled backups:
If you're enabling PITR on a
primary instance, you can also configure the number of days for which you want
to retain transaction logs by adding the following parameter:
resource "google_sql_database_instance" "postgres_instance_pitr" {
name = ""
region = "us-central1"
database_version = "POSTGRES_14"
settings {
tier = "db-custom-2-7680"
backup_configuration {
enabled = true
point_in_time_recovery_enabled = true
start_time = "20:55"
transaction_log_retention_days = "3"
}
}
# set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
# use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
deletion_protection = false
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called aroot module).
InCloud Shell, create a directory and a new
file within that directory. The filename must have the.tfextension—for examplemain.tf. In this
tutorial, the file is referred to asmain.tf.
mkdirDIRECTORY&& cdDIRECTORY&& touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly createdmain.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the-upgradeoption:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and enteringyesat the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud projectto view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set thedeletion_protectionargument tofalse.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
enteringyesat the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and enteringyesat the prompt:
terraform destroy
REST v1
Before using any of the request data,
make the following replacements:
PROJECT_ID: the ID orproject numberof the Google Cloud project that contains the instance
INSTANCE_NAME: the name of the primary or read replica instance that you're configuring for high availability
Open the more actions menufor the instance you
want to set the transaction log on and selectEdit.
UnderCustomize your instance, expand theData Protectionsection.
In theEnable point-in-time recoverysection, expandAdvanced options.
Enter the number of days to retain logs, from 1-35 for Cloud SQL Enterprise Plus edition or
1-7 for Cloud SQL Enterprise edition.
ClickSave.
gcloud
Edit the instance to set the number of days to retain
write-ahead logs.
Replace the following:
INSTANCE_NAME: The name of the instance you want to
set the transaction log on.
DAYS_TO_RETAIN: The number of days of transaction logs
to keep. For Cloud SQL Enterprise Plus edition, the valid range is between 1 and 35 days,
with a default of 14 days. For Cloud SQL Enterprise edition, the valid range is
between 1 and 7 days, with a default of 7 days.
If you don't
specify a value, then Cloud SQL uses the default value.
This is valid only when PITR is enabled. Keeping more days of
transaction logs requires a bigger storage size.
Before using any of the request data,
make the following replacements:
PROJECT_ID: the project ID.
INSTANCE_ID: the instance ID.
DAYS_TO_RETAIN: the number of days to retain transaction logs. For Cloud SQL Enterprise Plus edition, the valid range is between 1 and 35 days, with a default of 14 days. For Cloud SQL Enterprise edition, the valid range is between 1 and 7 days, with a default of 7 days.
If no value is specified, then the default value is used. This is valid only when PITR is enabled. Keeping more days of transaction logs requires a bigger storage size.
Before using any of the request data,
make the following replacements:
PROJECT_ID: the project ID.
INSTANCE_ID: the instance ID.
DAYS_TO_RETAIN: the number of days to retain transaction logs. For Cloud SQL Enterprise Plus edition, the valid range is between 1 and 35 days, with a default of 14 days. For Cloud SQL Enterprise edition, the valid range is between 1 and 7 days, with a default of 7 days.
If no value is specified, then the default value is used. This is valid only when PITR is enabled. Keeping more days of transaction logs requires a bigger storage size.
Check the storage location of transaction logs used for PITR
You can check where your Cloud SQL instance is storing the transaction
logs used for PITR.
gcloud
To determine whether your instance stores logs for PITR on
disk or Cloud Storage, use the following command:
gcloudsqlinstancesdescribeINSTANCE_NAME
ReplaceINSTANCE_NAMEwith the name of the instance.
For multiple instances in the same project, you can also check the storage
location of the transaction logs. To determine the location for multiple
instances, use the following command:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE
my_01 POSTGRES_12 us-central-1 DISK
my_02 POSTGRES_12 us-central-1 CLOUD_STORAGE
...
In the output of the command, thetransactionalLogStorageStatefield or theTRANSACTIONAL_LOG_STORAGE_STATEcolumn provides
information about where the transaction
logs for PITR are stored for the instance.
The possible transaction log
storage states are the following:
DISK: the instance stores the transaction logs
used for PITR on disk.
If you upgrade a Cloud SQL Enterprise edition instance to Cloud SQL Enterprise Plus edition, then the upgrade
process switches the log storage location to Cloud Storage automatically.
For more information, seeUpgrade an instance to Cloud SQL Enterprise Plus edition by using in-place upgrade. You
can also choose to switch the storage location by usinggcloud CLIor
the Cloud SQL Admin API without upgrading the edition of your instance and without
incurring any downtime. For more information, seeSwitch transaction log storage to Cloud Storage.
SWITCHING_TO_CLOUD_STORAGE: the instance is
switching the storage location for the PITR transaction logs to Cloud Storage.
SWITCHED_TO_CLOUD_STORAGE: the instance has
completed the
switching the storage location for PITR transaction logs from disk to Cloud Storage.
CLOUD_STORAGE: the instance stores the
transaction logs used for PITR in Cloud Storage.
Switch transaction log storage to Cloud Storage
If your instance stores its transaction logs used for PITR on
disk, then you can switch the storage location to
Cloud Storage without incurring any downtime. The overall process of switching
the storage location takes approximately the duration of the transaction log retention
period (days) to complete. As soon
as you start the switch, transaction logs start accruing in
Cloud Storage. During the operation, you can check the status of the overall
process by using the command inCheck the storage location of transaction logs used for PITR.
After the overall process of switching to Cloud Storage is complete,
Cloud SQL uses transaction logs from Cloud Storage for PITR.
gcloud
To switch the storage location to Cloud Storage, use the following command:
ReplaceINSTANCE_NAMEwith the name of the instance.
The instance must be a primary instance and not a replica instance.
The response is similar to the following:
The following message is used for the patch API method.
{"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"}
Patching Cloud SQL instance...done.
Updated
[https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
The following table lists possible errors that might return with theINVALID REQUESTcode when you switch the storage location of the
transaction logs from disk to Cloud Storage.
Issue
Troubleshooting
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
Make sure that you're running thegcloud CLIcommand or
making the API request on a Cloud SQL for MySQL or Cloud SQL for PostgreSQL instance.
Switching the storage location for transaction logs by using gcloud CLI or the
Cloud SQL Admin API is not supported for Cloud SQL for SQL Server.
PostgreSQL transactional logging is not enabled on this instance.
PostgreSQL uses write-ahead logging as the transaction logs for
point-in-time recovery (PITR). To support PITR, PostgreSQL requires
that you enable write-ahead logging on the instance.
For more information about how
to enable write-ahead logging,
seeEnable PITR.
This instance is already storing transaction logs used for PITR in
Cloud Storage
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-12-15 UTC."],[],[]]