Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) – Übersicht
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-time Recovery, PITR) in Spanner bietet Schutz vor versehentlichem Löschen oder Schreiben. Wenn ein Operator beispielsweise versehentlich Daten schreibt oder eine Anwendungseinführung eine beschädigte Datenbank verursacht, können Sie mit PITR die Daten eines früheren Zeitpunkts nahtlos wiederherstellen, der maximal sieben Tage zurückliegt. Wenn Sie Daten längerfristig aufbewahren müssen, können Sie entweder Sicherung und Wiederherstellung oder Export und Import verwenden.
Standardmäßig werden alle Versionen der Daten und des Schemas Ihrer Datenbank eine Stunde lang beibehalten. Sie können dieses Zeitlimit über die Option version_retention_period auf bis zu sieben Tage verlängern. Eine Anleitung finden Sie unter Aufbewahrungszeitraum festlegen.
Spanner speichert frühere Versionen von Daten mit einem Mikrosekundendetaillierungsgrad, und die Datenbank verwaltet ein earliest_version_time, das die früheste Zeit in der Vergangenheit darstellt, in der Sie frühere Versionen der Daten wiederherstellen können.
Möglichkeiten zur Datenwiederherstellung
Es gibt zwei Möglichkeiten, Daten wiederherzustellen:
Zum Wiederherstellen eines Teils der Datenbank führen Sie einen veralteten Lesevorgang aus, in dem eine Abfragebedingung und ein Zeitstempel in der Vergangenheit angegeben sind, und schreiben die Ergebnisse dann wieder in die Live-Datenbank. Dies wird in der Regel für operative Vorgänge in einer Livedatenbank verwendet. Wenn Sie beispielsweise eine bestimmte Zeile versehentlich löschen oder eine Teilmenge der Daten falsch aktualisieren, können Sie diese mit dieser Methode wiederherstellen. Eine Anleitung finden Sie unter Teil einer Datenbank wiederherstellen.
Wenn Sie die gesamte Datenbank wiederherstellen möchten, sichern oder exportieren Sie die Datenbank, indem Sie einen Zeitstempel in der Vergangenheit angeben und dann wiederherstellen oder in eine neue Datenbank importieren. Dies wird in der Regel zur Wiederherstellung nach Datenbeschädigungsproblemen verwendet, wenn Sie die Datenbank auf einen Zeitpunkt vor dem Auftreten der Beschädigung zurücksetzen müssen. Beachten Sie, dass das Sichern oder Exportieren einer Datenbank mehrere Stunden dauern kann und Sie nicht in eine vorhandene Datenbank hinein wiederherstellen oder importieren können. Eine Anleitung finden Sie unter Gesamte Datenbank wiederherstellen.
Hinweise zur Leistung
Datenbanken mit längeren Aufbewahrungszeiträumen und insbesondere solche, die Daten häufig überschreiben, benötigen mehr Systemressourcen. Dies kann sich auf die Leistung Ihrer Datenbank auswirken, insbesondere wenn die Instanz nicht mit genügend Rechenkapazität bereitgestellt wird.´ Wenn Ihre Datenbank eine sehr hohe Überschreibungsrate hat (z. B. wenn Ihre Datenbank mehrmals am Tag überschrieben wird), können Sie die Aufbewahrungsdauer schrittweise erhöhen und das System überwachen.
Beachten Sie Folgendes:
Erhöhte Speicherauslastung Wir empfehlen, Speicherbenachrichtigungen einzurichten, um sicherzustellen, dass die Speichergrenze nicht überschritten wird. Beachten Sie bei der Erhöhung der Aufbewahrungsdauer, dass die Speichernutzung allmählich zunimmt, wenn die Datenbank ältere Datenversionen sammelt. Dies liegt daran, dass die alten Daten, die unter der vorherigen Aufbewahrungsdauer abgelaufen sind, nicht mehr abgelaufen sind. Wenn Sie beispielsweise die Aufbewahrungsdauer von drei Tagen auf sieben Tage erhöhen, müssen Sie vier Tage warten, bis die Speichernutzung der Datenbank stabilisiert wurde. Außerdem erhalten Sie eine Anleitung zum Schätzen der Speichererweiterung.
Erhöhte CPU-Auslastung und -Latenz. Spanner verwendet zusätzliche Rechenressourcen, um frühere Datenversionen zu komprimieren und zu verwalten.
Überwachen Sie Ihre Instanz und Datenbank, um sicherzustellen, dass die Latenz und die CPU-Auslastung akzeptabel sind.
Erhöhte Zeit für die Durchführung von Schemaaktualisierungen. Eine längere Aufbewahrungsdauer bedeutet, dass Schemaversionen für längere Zeit beibehalten werden müssen. Dies kann dazu führen, dass Schemaaktualisierungen während der Wartezeit für Serverressourcen throttled werden. Achten Sie darauf, dass Sie die Best Practices für Schemaaktualisierungen einhalten und die Limits für Schemaaktualisierungen einhalten.
Preise
Für die Verwendung von PITR fallen keine zusätzlichen Kosten an. Wenn Sie den Aufbewahrungszeitraum für Versionen Ihrer Datenbank jedoch über die Standardeinstellung von einer Stunde hinaus verlängern, können sich die Kosten für den Speicher und die Rechenkapazität Ihrer Datenbank erhöhen. Die Kosten für Ihre On‑Demand-Sicherung sind davon nicht betroffen, da nur eine einzelne Version Ihrer Datenbank gespeichert wird. Weitere Informationen finden Sie im Abschnitt Überlegungen zur Leistung. Bevor Sie die Versionsaufbewahrungsdauer einer Datenbank erhöhen, können Sie die erwartete Zunahme des Datenbankspeichers schätzen.
Allgemeine Informationen zur Abrechnung von Spanner finden Sie unter Spanner-Preise.
[[["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-11 (UTC)."],[],[],null,["# Point-in-time recovery (PITR) overview\n\nSpanner point-in-time recovery (PITR) provides protection against\naccidental deletion or writes. For example, if an operator inadvertently writes\ndata or an application rollout corrupts the database, with PITR you can recover\nthe data from a point-in-time in the past (up to a maximum of seven days)\nseamlessly. If you need longer-term retention of data, you can use either\n[Backup and Restore](/spanner/docs/backup) or [Export and Import](/spanner/docs/export).\n\nBy default, your database retains all versions of its data and schema for one\nhour. You can increase this time limit to as long as seven days through the\n[`version_retention_period`](/spanner/docs/reference/rest/v1/projects.instances.databases#Database.FIELDS.version_retention_period)\noption. For instructions, see [Set the retention period](/spanner/docs/use-pitr#set-period).\nSpanner stores earlier versions of data at microsecond granularity and the\ndatabase maintains an [`earliest_version_time`](/spanner/docs/reference/rest/v1/projects.instances.databases#Database.FIELDS.earliest_version_time),\nwhich represents the earliest time in the past that you can recover earlier versions\nof the data.\n| **Note:** PITR provides additional insurance against logical data corruption, but does not protect you in case a user accidentally deletes the database. Make sure that you have other recovery options in place and that access to roles that include the [`spanner.databases.drop`](/spanner/docs/iam#databases) permission are set appropriately. For more information, see [Using IAM securely](/iam/docs/using-iam-securely). You can also enable [database deletion protection](/spanner/docs/prevent-database-deletion) to prevent the accidental deletions of databases.\n\nWays to recover data\n--------------------\n\nThere are two ways to recover data:\n\n- To **recover a portion of the database** , perform a [stale read](/spanner/docs/reads#perform-stale-read)\n specifying a query-condition and timestamp in the past, and then write the\n results back into the live database. This is typically used for surgical\n operations on a live database. For example, if you accidentally delete a\n particular row or incorrectly update a subset of data, you can recover it\n with this method. For instructions, see [recovering a portion of your database](/spanner/docs/use-pitr#recover-portion).\n\n- To **recover the entire database** , [backup](/spanner/docs/backup) or\n [export](/spanner/docs/export) the database specifying a timestamp in the\n past and then restore or import it to a new database. This is typically used\n to recover from data corruption issues when you have to revert the\n database to a point-in-time before the corruption occurred. Note that\n backing up or exporting a database could take several hours and that you\n cannot restore or import to an existing database. For instructions, see\n [recovering the entire database](/spanner/docs/use-pitr#recover-entire).\n\nPerformance considerations\n--------------------------\n\nDatabases with longer retention periods and, in particular, those that\nfrequently overwrite data, use more system resources. This can affect how your\ndatabase performs, especially if your instance is not provisioned with enough\n[compute capacity](/spanner/docs/compute-capacity). If your database has a very high overwrite rate\n(for example, if your database is overwritten multiple times per day), you might\nconsider increasing the retention period gradually and\n[monitoring the system](/spanner/docs/monitoring-cloud#storage).\nHere are some things to be aware of:\n\n- **Increased storage utilization** . We recommend setting up\n [storage alerts](/spanner/docs/storage-utilization#alerts) to ensure that you\n don't exceed the [storage limit](/spanner/quotas#database_limits). When you\n increase the retention period, keep in mind that storage usage will increase\n gradually as the database accumulates earlier versions of data. This is because\n the old data that would have expired under the previous retention period, is no\n longer expired. So, for example, if you increase the retention period from 3\n days to 7 days, you need to wait for 4 days for database storage usage to\n stabilize. We also provide instructions for\n [estimating the storage increase](/spanner/docs/use-pitr#estimate-storage).\n\n- **Increased CPU usage and latency** . Spanner uses additional computing\n resources to compact and maintain earlier versions of data.\n [Monitor your instance and database](/spanner/docs/monitoring-console#view-current-status)\n to ensure that latency and CPU utilization remain at acceptable levels.\n\n- **Increased time to perform schema updates** . An increased retention period\n means that [schema versions](/spanner/docs/schema-updates#schema_versions_created_during_schema_updates)\n must be retained for longer durations potentially causing schema updates to be\n [`throttled`](/spanner/docs/reference/rest/v1/UpdateDatabaseDdlMetadata#FIELDS.throttled) while\n waiting for server resources. Make sure that you are following\n [best practices for schema updates](/spanner/docs/schema-updates#best-practices)\n and staying within the [limits for schema updates](/spanner/docs/schema-updates#frequency).\n\nPricing\n-------\n\nThere is no additional charge for using PITR. However, if you\nincrease the version retention period of your database from the default one hour,\nyour database storage and compute capacity costs might increase. Your on-demand\n[backup](/spanner/docs/backup) cost is unaffected because only a single version\nof your database is stored. For more information, see the [Performance\nconsiderations](#performance) section. Before increasing a database's version\nretention period, you can [estimate the expected increase in database storage](/spanner/docs/use-pitr#estimate-storage).\n\nFor general information about how Spanner is charged, see\n[Spanner pricing](/spanner/pricing).\n\nWhat's next\n-----------\n\n- Learn more about how to [recover data with PITR](/spanner/docs/use-pitr)."]]
