This page describes how to restore a cluster to a recent past state. Restoring data to a point in time into an AlloyDB for PostgreSQL cluster is recommended for rapid recovery from large-scale data loss.
roles/alloydb.admin (the AlloyDB Admin predefined IAM role)roles/owner (the Owner basic IAM role)roles/editor (the Editor basic IAM role)If you don't have any of these roles, contact your Organization Administrator to request access.
compute.networks.listcompute.addresses.createcompute.addresses.listcompute.globalAddresses.createcompute.globalAddresses.listservicenetworking.services.addPeeringTo gain these permissions while following the principle of least privilege, ask
your administrator to grant you the roles/alloydb.admin (
AlloyDB Admin predefined IAM) role.
AlloyDB lets you fully restore an active cluster's data from any point in time within a specific, recent range.
You can restore from any point in time after the more recent of the following two moments:
The moment represented by the limit of your recovery window. For example, if you have a 14-day recovery window, then this moment is 14 days in the past.
The creation time of the oldest backup taken since you last enabled continuous backup. If you created the cluster with continuous backup enabled, and you have not disabled continuous backup since then, then this moment effectively becomes the creation time of your cluster's oldest backup.
If you disable and subsequently re-enable continuous backup, then you cannot perform a point-in-time recovery until either you or AlloyDB creates the cluster's first new backup. This can be an on-demand backup, or the first of the daily backups that AlloyDB takes after you enable continuous backup. For more information about backup types, see Data backup and recovery overview.
You can only perform a point-in-time recovery if the original cluster exists. You can't perform this type of restore on a deleted cluster.
You can perform a point-in-time recovery on a cluster in a ready state, even if its primary instance is deleted. However, the recovery can only restore the cluster to a point in time before the instance was deleted.
Use either the Google Cloud console or the Google Cloud CLI to perform the restore.
Go to the Clusters page.
Click a cluster in the Resource Name column.
Click Data protection.
Under Restore from a point in time, click Restore.
In the Target time field, enter the date and time to restore from.
In the Cluster ID field, enter a name for the new cluster.
In the Network field, select a Virtual Private Cloud network for the new cluster to use.
If you want to encrypt this cluster's continuous backups and data-change logs using a customer-managed encryption key (CMEK) instead of the default Google-managed encryption, follow these additional steps:
Click Advanced encryption options.
Click the Customer-managed encryption key (CMEK) radio button.
Click the Select a customer-managed key list, and select a key.
Click Restore.
Use the gcloud alloydb clusters
restore command,
specifying a cluster and a timestamp.
gcloud alloydb clusters restore NEW_CLUSTER \
--source-cluster=SOURCE_CLUSTER \
--point-in-time=TIMESTAMP \
--region=REGIONThis command returns an operation, whose status you can query using the
gcloud alloydb operations describe command.
gcloud alloydb operations describe OPERATION_ID \
--region=REGIONReplace the following:
NEW_CLUSTER:
The ID to use with the new cluster.
SOURCE_CLUSTER: The ID of the cluster
to recover data from.
To restore from a cluster in a different project, replace with the full
cluster path in the following format:
projects/SOURCE_PROJECT/locations/SOURCE_REGION/clusters/SOURCE_CLUSTER
TIMESTAMP: A description
of the point in time to recover data from, expressed in RFC 3339
format—for
example, 2012-11-15T16:19:00.094Z. You can specify a fractional
second as small as a microsecond.
Note that this timestamp must exist within the retention period you specified when you created the cluster.
REGION: The region that contains the source
cluster, and where AlloyDB creates the new cluster.
For example: us-central1.
PROJECT_ID: The ID of the project where the new cluster is.
If you want to encrypt the new cluster's data with a customer-managed encryption key (CMEK) instead of Google-managed encryption, then you must provide these additional arguments:
--kms-key=KEY_ID: The ID of the CMEK key to
use.--kms-keyring=KEYRING_ID: The ID
of the key's key ring.--kms-location=LOCATION_ID: The ID of that
keyring's region. Note that it must match the cluster's region.--kms-project=PROJECT_ID: The ID of the
keyring's project.To restore to a cluster with Private Service Connect enabled, make sure that you add the --enable-private-service-connect flag.
After AlloyDB finishes creating the cluster, create a primary instance for it. That instance lets you access the restored data. Note that the new instance's configuration need not exactly match that of the original primary instance.
Optional: Create read-pool instances.
You can start using the cluster after the restore operation completes.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-06-10 UTC.