Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) verwenden
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite wird beschrieben, wie Sie einen Cluster in einen aktuellen früheren Zustand zurücksetzen. Das Wiederherstellen von Daten zu einem bestimmten Zeitpunkt in einem AlloyDB for PostgreSQL-Cluster wird für die schnelle Wiederherstellung nach einem großflächigen Datenverlust empfohlen.
Wenn Sie keine dieser Rollen haben, wenden Sie sich an den Organisationsadministrator, um Zugriff anzufordern.
Sie benötigen alle diese IAM-Rollen im Google Cloud -Projekt, das Sie verwenden:
compute.networks.list
compute.addresses.create
compute.addresses.list
compute.globalAddresses.create
compute.globalAddresses.list
servicenetworking.services.addPeering
Bitten Sie Ihren Administrator, Ihnen die vordefinierte IAM-Rolle roles/alloydb.admin (AlloyDB-Administrator) zuzuweisen, damit Sie diese Berechtigungen erhalten und dabei dem Prinzip der geringsten Berechtigung folgen.
Von einem aktuellen Zeitpunkt wiederherstellen
Mit AlloyDB können Sie die Daten eines aktiven Clusters vollständig von einem beliebigen Zeitpunkt innerhalb eines bestimmten, aktuellen Zeitraums wiederherstellen.
Verfügbare PITR-Zeiträume
Sie können eine Wiederherstellung ab jedem Zeitpunkt nach dem späteren der beiden folgenden Zeitpunkte durchführen:
Der Moment, der durch das Ende des Wiederherstellungszeitraums dargestellt wird. Wenn Sie beispielsweise ein 14-tägiges Wiederherstellungsfenster haben, liegt dieser Moment 14 Tage in der Vergangenheit.
Erstellungszeitpunkt der ältesten Sicherung, die seit der letzten Aktivierung der kontinuierlichen Sicherung erstellt wurde. Wenn Sie den Cluster mit aktivierter kontinuierlicher Sicherung erstellt und die kontinuierliche Sicherung seitdem nicht deaktiviert haben, ist dieser Zeitpunkt effektiv der Erstellungszeitpunkt der ältesten Sicherung Ihres Clusters.
Wenn Sie die kontinuierliche Sicherung deaktivieren und dann wieder aktivieren, können Sie keine Wiederherstellung zu einem bestimmten Zeitpunkt durchführen, bis entweder Sie oder AlloyDB die erste neue Sicherung des Clusters erstellt haben. Das kann eine On-Demand-Sicherung oder die erste der täglichen Sicherungen sein, die AlloyDB nach der Aktivierung der kontinuierlichen Sicherung erstellt. Weitere Informationen zu Sicherungstypen finden Sie unter Datensicherung und ‑wiederherstellung – Übersicht.
Wiederherstellung zu einem bestimmten Zeitpunkt ausführen
Verwenden Sie entweder die Google Cloud Console oder die Google Cloud CLI, um die Wiederherstellung durchzuführen.
Klicken Sie auf Erweiterte Verschlüsselungsoptionen.
Klicken Sie auf das Optionsfeld Vom Kunden verwalteter Verschlüsselungsschlüssel (CMEK).
Klicken Sie auf die Liste Vom Kunden verwalteten Schlüssel auswählen und wählen Sie einen Schlüssel aus.
Klicken Sie auf Wiederherstellen.
gcloud
Verwenden Sie den Befehl gcloud alloydb clusters
restore und geben Sie einen Cluster und einen Zeitstempel an. Im Gegensatz zur Wiederherstellung aus einer Sicherung ist für die Wiederherstellung zu einem bestimmten Zeitpunkt erforderlich, dass der ursprüngliche Cluster noch vorhanden ist. Sie können diese Art der Wiederherstellung nicht für einen gelöschten Cluster ausführen.
NEW_CLUSTER:
Die ID, die für den neuen Cluster verwendet werden soll.
SOURCE_CLUSTER: Die ID des Clusters, aus dem Daten wiederhergestellt werden sollen.
Wenn Sie die Wiederherstellung aus einem Cluster in einem anderen Projekt durchführen möchten, ersetzen Sie den Pfad durch den vollständigen Clusterpfad im folgenden Format: projects/SOURCE_PROJECT/locations/SOURCE_REGION/clusters/SOURCE_CLUSTER
TIMESTAMP: Eine Beschreibung des Zeitpunkts, zu dem Daten wiederhergestellt werden sollen, im RFC 3339-Format, z. B. 2012-11-15T16:19:00.094Z. Sie können eine Bruchteilsekunde bis hinunter zu einer Mikrosekunde angeben.
Dieser Zeitstempel muss innerhalb des Aufbewahrungszeitraums liegen, den Sie beim Erstellen des Clusters angegeben haben.
REGION: Die Region, die den Quellcluster enthält und in der AlloyDB den neuen Cluster erstellt.
Beispiel: us-central1
PROJECT_ID: Die ID des Projekts, in dem sich der neue Cluster befindet.
--kms-key=KEY_ID: Die ID des zu verwendenden CMEK-Schlüssels. * --kms-keyring=KEYRING_ID: Die ID des Schlüsselbunds des Schlüssels. *
--kms-location=LOCATION_ID: Die ID der Region dieses Schlüsselbunds. Sie muss mit der Region des Clusters übereinstimmen.
--kms-project=PROJECT_ID: Die ID des Projekts des Schlüsselbunds.
Wenn Sie eine Sicherung in einem Cluster mit aktiviertem Private Service Connect wiederherstellen möchten, müssen Sie das Flag --enable-private-service-connect hinzufügen.
Nachdem AlloyDB den Cluster erstellt hat, erstellen Sie eine primäre Instanz dafür. Über diese Instanz können Sie auf die wiederhergestellten Daten zugreifen. Die Konfiguration der neuen Instanz muss nicht genau mit der der ursprünglichen primären Instanz übereinstimmen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-25 (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)"]]
