Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, descrevemos como restaurar um cluster para um estado recente
anterior. Recomendamos restaurar dados para um ponto específico no tempo em um cluster do AlloyDB para PostgreSQL para uma recuperação rápida de perda de dados em grande escala.
Você precisa ter um destes papéis do IAM no projeto Google Cloud que está usando:
roles/alloydb.admin (o papel predefinido do IAM de administrador do AlloyDB)
roles/owner (o papel básico Proprietário do IAM)
roles/editor (o papel básico de editor do IAM)
Se você não tiver nenhum desses papéis, entre em contato com o administrador da organização para solicitar
acesso.
Você precisa ter todos esses papéis do IAM no projeto Google Cloud que está usando:
compute.networks.list
compute.addresses.create
compute.addresses.list
compute.globalAddresses.create
compute.globalAddresses.list
servicenetworking.services.addPeering
Para receber essas permissões seguindo o princípio de privilégio mínimo, peça ao administrador para conceder a você o papel roles/alloydb.admin (IAM predefinido de administrador do AlloyDB).
Restaurar de um momento recente
O AlloyDB permite restaurar totalmente os dados de um cluster ativo de qualquer
ponto no tempo dentro de um intervalo específico e recente.
Períodos de PITR disponíveis
É possível restaurar de qualquer momento após o mais recente dos dois momentos a seguir:
O momento representado pelo limite da sua janela de recuperação. Por exemplo, se você tiver um período de recuperação de 14 dias, esse momento será 14 dias no passado.
O horário de criação do backup mais antigo feito desde a última vez que você ativou
o backup contínuo. Se você criou o cluster com o backup contínuo
ativado e não o desativou desde então, esse
momento se torna efetivamente a hora de criação do backup mais antigo do cluster.
Se você desativar e reativar o backup contínuo, não será possível
fazer uma recuperação pontual até que você ou o AlloyDB
criem o primeiro backup novo do cluster. Pode ser um backup sob demanda ou o primeiro dos backups diários que o AlloyDB faz depois que você ativa o backup contínuo. Para mais informações sobre os tipos de backup, consulte Visão geral do backup e da
recuperação de dados.
Fazer uma restauração pontual
Use o Google Cloud console ou a Google Cloud CLI para realizar a
restauração.
Em Restaurar de um momento específico, clique em Restaurar.
No campo Horário de destino, insira a data e a hora para restauração.
No campo ID do cluster, insira um nome para o novo cluster.
No campo Rede, selecione uma rede de nuvem privada virtual para o novo cluster usar.
Se você quiser criptografar os backups contínuos e os registros de
mudanças de dados deste cluster usando uma chave de criptografia gerenciada pelo cliente
(CMEK) em vez da criptografia padrão gerenciada pelo
Google, siga estas etapas adicionais:
Clique em Opções avançadas de criptografia.
Clique no botão de opção Chave de criptografia gerenciada pelo cliente (CMEK).
Clique na lista Selecionar uma chave gerenciada pelo cliente e escolha uma chave.
Clique em Restaurar.
gcloud
Use o comando gcloud alloydb clusters
restore, especificando um cluster e um carimbo de data/hora. Ao contrário da restauração de um
backup, a recuperação pontual exige que o cluster original ainda
exista. Não é possível realizar esse tipo de restauração em um cluster excluído.
SOURCE_CLUSTER: o ID do cluster
de onde os dados serão recuperados.
Para restaurar de um cluster em um projeto diferente, substitua pelo caminho completo
do cluster neste formato: projects/SOURCE_PROJECT/locations/SOURCE_REGION/clusters/SOURCE_CLUSTER
TIMESTAMP: uma descrição do ponto no tempo para recuperar dados, expressa no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z. É possível especificar uma fração de segundo tão pequena quanto um microssegundo.
Esse carimbo de data/hora precisa estar dentro do período de armazenamento especificado ao criar o cluster.
REGION: a região que contém o cluster de origem e onde o AlloyDB cria o novo cluster.
Por exemplo, us-central1.
PROJECT_ID: o ID do projeto em que o novo cluster está.
--kms-key=KEY_ID: o ID da chave CMEK a ser usada. * --kms-keyring=KEYRING_ID: o ID do keyring da chave. *
--kms-location=LOCATION_ID: o ID da região do
keyring. Ela precisa corresponder à região do cluster.
--kms-project=PROJECT_ID: o ID do projeto do
keyring.
Para restaurar um cluster com o Private Service Connect ativado, adicione a flag --enable-private-service-connect.
Depois que o AlloyDB terminar de criar o cluster, crie uma instância principal para ele. Essa
instância permite acessar os dados restaurados. A configuração da nova instância não precisa corresponder exatamente à da instância principal original.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-02 UTC."],[[["\u003cp\u003eThis guide outlines the process of restoring an AlloyDB for PostgreSQL cluster to a specific point in time for rapid data recovery.\u003c/p\u003e\n"],["\u003cp\u003ePoint-in-time recovery (PITR) allows restoring data from any moment within a defined recovery window, determined by the recovery window's limit or the creation time of the oldest backup.\u003c/p\u003e\n"],["\u003cp\u003eRestoring from a point in time requires the original cluster to be active and is accessible through the Google Cloud console or the \u003ccode\u003egcloud\u003c/code\u003e CLI.\u003c/p\u003e\n"],["\u003cp\u003eWhen performing a point-in-time restore, users must specify a target timestamp within the retention period and configure settings for the new cluster, such as network and encryption options.\u003c/p\u003e\n"],["\u003cp\u003eAfter the restore, a new primary instance needs to be created to access the restored data, and optionally, read-pool instances can be added.\u003c/p\u003e\n"]]],[],null,["# Use point-in-time recovery (PITR)\n\nThis page describes how to restore a cluster to a recent\npast state. Restoring data to a point in time into\nan AlloyDB for PostgreSQL cluster is recommended for rapid recovery\nfrom large-scale data loss.\n\n\nBefore you begin\n----------------\n\n- The Google Cloud project you are using must have been [enabled to access AlloyDB](/alloydb/docs/project-enable-access).\n- You must have one of these IAM roles in the Google Cloud project you are using:\n - `roles/alloydb.admin` (the AlloyDB Admin predefined IAM role)\n - `roles/owner` (the Owner basic IAM role)\n - `roles/editor` (the Editor basic IAM role)\n\n If you don't have any of these roles, contact your Organization Administrator to request\n access.\n\n- You must have all of these IAM roles in the Google Cloud project you are using:\n - `compute.networks.list`\n - `compute.addresses.create`\n - `compute.addresses.list`\n - `compute.globalAddresses.create`\n - `compute.globalAddresses.list`\n - `servicenetworking.services.addPeering`\n\n \u003cbr /\u003e\n\n To gain these permissions while following the principle of least privilege, ask\n your administrator to grant you the `roles/alloydb.admin` (\n AlloyDB Admin predefined IAM) role.\n\n\u003cbr /\u003e\n\nRestore from a recent point in time\n-----------------------------------\n\nAlloyDB lets you fully restore an active cluster's data from any\npoint in time within a specific, recent range.\n\n### Available PITR windows\n\nYou can restore from any point in time after the more recent of the following\ntwo moments:\n\n- **The moment represented by the limit of your recovery window.** For\n example, if you have a 14-day recovery window, then this moment is 14 days\n in the past.\n\n- **The creation time of the oldest backup taken since you last enabled\n continuous backup.** If you created the cluster with continuous backup\n enabled, and you have not disabled continuous backup since then, then this\n moment effectively becomes the creation time of your cluster's oldest backup.\n\nIf you disable and subsequently re-enable continuous backup, then you cannot\nperform a point-in-time recovery until either you or AlloyDB\ncreates the cluster's first new backup. This can be an on-demand backup, or the\nfirst of the daily backups that AlloyDB takes after you enable\ncontinuous backup. For more information about backup types, see [Data backup and\nrecovery overview](/alloydb/docs/backup/overview).\n\n### Perform a point-in-time restore\n\n1. Use either the Google Cloud console or the Google Cloud CLI to perform the\n restore.\n\n ### Console\n\n 1. Go to the **Clusters** page.\n\n [Go to Clusters](https://console.cloud.google.com/alloydb/clusters)\n 2. Click a cluster in the **Resource Name**\n column.\n\n 3. Click **Data protection**.\n\n 4. Under **Restore from a point in time** , click **Restore**.\n\n 5. In the **Target time** field, enter the date and time to restore from.\n\n 6. In the **Cluster ID** field, enter a name for the new cluster.\n\n 7. In the **Network** field, select a Virtual Private Cloud network for the new\n cluster to use.\n\n 8. If you want to encrypt this cluster's continuous backups and\n data-change logs using a [customer-managed encryption key\n (CMEK)](/alloydb/docs/cmek) instead of the default Google-managed\n encryption, follow these additional steps:\n\n 1. Click **Advanced encryption options**.\n\n 2. Click the **Customer-managed encryption key (CMEK)** radio\n button.\n\n 3. Click the **Select a customer-managed key** list, and select a\n key.\n\n 9. Click **Restore**.\n\n ### gcloud\n\n Use the [`gcloud alloydb clusters\n restore`](/sdk/gcloud/reference/alloydb/clusters/restore) command,\n specifying a cluster and a timestamp. Note that, unlike [restoring from a\n backup](/alloydb/docs/backup/restore), a point-in-time recovery requires the original cluster to\n still exist. You cannot perform this kind of restore on a deleted cluster. \n\n gcloud alloydb clusters restore \u003cvar translate=\"no\"\u003eNEW_CLUSTER\u003c/var\u003e \\\n --source-cluster=\u003cvar translate=\"no\"\u003eSOURCE_CLUSTER\u003c/var\u003e \\\n --point-in-time=\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e \\\n --region=\u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e\n\n This command returns an operation, whose status you can query using the\n [`gcloud alloydb operations describe`](/sdk/gcloud/reference/alloydb/operations/describe) command. \n\n gcloud alloydb operations describe \u003cvar translate=\"no\"\u003eOPERATION_ID\u003c/var\u003e \\\n --region=\u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eNEW_CLUSTER\u003c/var\u003e:\n The ID to use with the new cluster.\n\n - \u003cvar translate=\"no\"\u003eSOURCE_CLUSTER\u003c/var\u003e: The ID of the cluster\n to recover data from. \n\n To restore from a cluster in a different project, replace with the full\n cluster path in the following format: \n\n `projects/`\u003cvar translate=\"no\"\u003eSOURCE_PROJECT\u003c/var\u003e`/locations/`\u003cvar translate=\"no\"\u003eSOURCE_REGION\u003c/var\u003e`/clusters/`\u003cvar translate=\"no\"\u003eSOURCE_CLUSTER\u003c/var\u003e\n\n - \u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e: A description\n of the point in time to recover data from, expressed in [RFC 3339\n format](https://datatracker.ietf.org/doc/html/rfc3339)---for\n example, `2012-11-15T16:19:00.094Z`. You can specify a fractional\n second as small as a microsecond.\n\n Note that this timestamp must exist within the retention period you\n specified when you created the cluster.\n - \u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e: The region that contains the source\n cluster, and where AlloyDB creates the new cluster.\n For example: `us-central1`.\n\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: The ID of the project where the new cluster is.\n\n If you want to encrypt the\n new cluster's data with a [customer-managed encryption key\n (CMEK)](/alloydb/docs/cmek) instead of Google-managed encryption,\n then you must provide these additional arguments:\n - `--kms-key=`\u003cvar translate=\"no\"\u003eKEY_ID\u003c/var\u003e: The ID of the CMEK key to use. \\* `--kms-keyring=`\u003cvar translate=\"no\"\u003eKEYRING_ID\u003c/var\u003e: The ID of the key's key ring. \\* `--kms-location=`\u003cvar translate=\"no\"\u003eLOCATION_ID\u003c/var\u003e: The ID of that keyring's region. Note that it must match the cluster's region.\n - `--kms-project=`\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: The ID of the keyring's project.\n\n To restore to a cluster with Private Service Connect enabled, make sure that you add the `--enable-private-service-connect` flag.\n2. After AlloyDB finishes creating the cluster, [create a\n primary instance for it](/alloydb/docs/instance-primary-create). That\n instance lets you access the restored data. Note that the new instance's\n configuration need not exactly match that of the original primary instance.\n\n3. Optional: [Create read-pool instances.](/alloydb/docs/instance-read-pool-create)\n\nYou can start using the cluster after the restore operation completes.\n\nWhat's next\n-----------\n\n- [Restore a cluster from a stored backup.](/alloydb/docs/backup/restore)\n- [Create a read pool instance.](/alloydb/docs/instance-read-pool-create)\n- [Create a secondary cluster and instance.](/alloydb/docs/cross-region-replication/work-with-cross-region-replication)"]]
