Bigtable-Sicherungen – Übersicht

Diese Seite bietet einen Überblick über Bigtable-Sicherungen. Die hier vorgestellten Inhalte richten sich an Bigtable-Administratoren und -Entwickler.

Mit Sicherungen können Sie eine Kopie des Schemas und der Daten einer Tabelle speichern und später aus der Sicherung in einer neuen Tabelle wiederherstellen. Bigtable bietet die folgenden Arten von Sicherungen, die von Ihren Anforderungen an die Notfallwiederherstellung (Disaster Recovery, DR) und dem Speichertyp (HDD oder SSD) abhängen, den Ihr Bigtable-Cluster verwendet.

  • Standardsicherungen sind für die langfristige Aufbewahrung optimiert. Wenn Sie eine Standardsicherung in einem SSD-Cluster wiederherstellen, erfordert der Wiederherstellungsvorgang eine zusätzliche Optimierung durch Bigtable, um die Tabelle auf eine produktionsreife Leistung zu bringen. Weitere Informationen finden Sie unter Leistung bei der Wiederherstellung.
  • Hot Backups lassen sich am effizientesten zu einer produktionsreifen Leistung und Bereitstellung mit geringer Latenz wiederherstellen. Weitere Informationen finden Sie unter Hot Backups.

Sie können Sicherungen auf folgende Arten erstellen:

  • Aktivieren Sie die automatische Sicherung, damit Bigtable täglich Sicherungen für Sie erstellt.
  • Erstellen Sie ein On-Demand-Backup mithilfe der Google Cloud Console, der gcloud CLI oder einer Bigtable-Clientbibliothek.
  • Kopie einer Sicherung erstellen

Bevor Sie diese Seite lesen, sollten Sie sich die Bigtable-Übersicht und Tabellen verwalten ansehen.

Features

Bigtable-Sicherungen bieten die folgenden Funktionen und Vorteile:

  • Vollständig integriert: Bigtable verarbeitet Sicherungen, ohne dass Daten importiert oder exportiert werden müssen.
  • Inkrementell: Eine Sicherung nutzt den physischen Speicher mit der Quelltabelle und anderen Sicherungen der Tabelle gemeinsam.
  • Kosteneffizient: Mit Bigtable-Sicherungen können Sie die Kosten für das Exportieren, Speichern und Importieren von Daten mit anderen Diensten vermeiden.
  • Automatischer Ablauf: Jede Sicherung hat eine benutzerdefinierte Aufbewahrungsdauer. Weitere Informationen finden Sie im Abschnitt Aufbewahrung dieses Dokuments.
  • Flexible Wiederherstellungsoptionen: Sie können eine Sicherung in einer Tabelle einer anderen Instanz wiederherstellen, in der die Sicherung nicht erstellt wurde.
  • Automatische Sicherung: Aktivieren Sie automatische Sicherungen, damit Bigtable tägliche Sicherungen erstellen kann.
  • Hot Backups: Mit produktionsreifen Hot Backups können Sie die Notfallwiederherstellung planen.

Anwendungsfälle

Sicherungen sind in den folgenden Anwendungsfällen nützlich:

  • Geschäftskontinuität
  • Gesetzliche Vorschriften
  • Testen und entwickeln
  • Notfallwiederherstellung

Sehen Sie sich die folgenden Szenarien für die Notfallwiederherstellung an:

Ziel Sicherungsstrategie Wiederherstellungsstrategie
Schutz vor menschlichen Fehlern: Sie möchten immer eine aktuelle Sicherung Ihrer Daten parat haben, falls diese versehentlich gelöscht oder beschädigt werden. Legen Sie einen Zeitplan für die Erstellung von Sicherungen fest, der Ihren geschäftlichen Anforderungen entspricht, z. B. täglich. Optional können Sie regelmäßige Kopien der Sicherungen erstellen und sie in einem anderen Projekt oder einer anderen Region speichern, um die Isolation und den Schutz zu erhöhen. Für noch mehr Schutz können Sie die Sicherungskopien in einem Projekt oder einer Instanz mit eingeschränkten Zugriffsberechtigungen speichern. Stellen Sie die Sicherung oder Kopie in einer neuen Tabelle wieder her und leiten Sie dann Anfragen an die neue Tabelle weiter.
Nichtverfügbarkeit von Zonen: Sie müssen dafür sorgen, dass Ihre Daten im unwahrscheinlichen Fall, dass eine Google Cloud Zone nicht verfügbar ist, weiterhin verfügbar sind. Aktivieren Sie die automatische Sicherung, damit Bigtable täglich eine Sicherung für jeden Cluster in der Instanz erstellt. Alternativ können Sie regelmäßig Sicherungen erstellen und dann regelmäßig eine Kopie der neuesten Sicherung erstellen und in einem oder mehreren Clustern in verschiedenen Zonen (optional in einer anderen Instanz oder einem anderen Projekt) speichern. Wenn die Zone, in der sich Ihr Bereitstellungscluster befindet, nicht mehr verfügbar ist, stellen Sie die Remote-Sicherungskopie in einer neuen Tabelle wieder her und leiten Sie dann Anfragen an die neue Tabelle weiter.
Datenbeschädigung: Verwenden Sie eine Sicherung, um einen Teil der Daten einer Tabelle wiederherzustellen, z. B. wenn ein Teil der Quelltabelle beschädigt wurde. Aktivieren Sie die Replikation und die automatische Sicherung, um täglich Sicherungen in mehreren Regionen zu erstellen. Wenn eine Tabelle in einem Cluster beschädigt wird, haben Sie dann eine oder mehrere Sicherungen, die nicht auf dem beschädigten Cluster gespeichert sind. Stellen Sie aus der Sicherung eine neue Tabelle im neuen Cluster oder in der neuen Instanz wieder her. Dann schreiben Sie eine Anwendung mit einer Bigtable-Clientbibliothek oder Dataflow, die aus der neuen Tabelle liest und die Daten dann wieder in die Quelltabelle schreibt. Wenn die Daten in die ursprüngliche Tabelle kopiert wurden, löschen Sie die neue Tabelle.
Schnelle Wiederherstellung: Stellen Sie schnell die volle Produktionsleistung wieder her, um Ausfallzeiten zu minimieren. Konfigurieren Sie automatische Sicherungen, um täglich Hot Backups zu erstellen, oder erstellen Sie Hot Backups bei Bedarf, damit Sie immer ein aktuelles Hot Backup Ihrer Tabelle haben. Stellen Sie die Daten aus dem Hot Backup in einer neuen Tabelle wieder her und leiten Sie dann Anfragen an die neue Tabelle weiter.

Hot Backups

Ein Hot Backup ist eine produktionsreife Sicherung, die für eine schnelle Wiederherstellung optimiert ist. Sie bietet eine geringere Latenz, wenn kurz nach der Wiederherstellung aus der neuen Tabelle gelesen wird. Die Wiederherstellung der Produktionsleistung aus einem Hot Backup ist schneller als die Wiederherstellung aus einem Standardsicherung.

Sie können jederzeit eine On-Demand-Hot-Sicherung erstellen oder eine Richtlinie für automatische Sicherungen konfigurieren, um täglich Hot-Sicherungen zu erstellen:

  • On-Demand-Hot-Backups: Das Festlegen einer Übergangszeit von „Hot“ zu „Standard“ ist optional. Wenn Sie keine Übergangszeit festlegen, bleibt die Sicherung bis zum Ablauf aktiv. Wenn Sie die Sicherung automatisch in eine Standardsicherung umwandeln möchten, können Sie eine Umstellungszeit festlegen, die mindestens 24 Stunden nach dem Start der Sicherungserstellung liegt. Sie können diese Zeit auch später festlegen oder ändern. Weitere Informationen finden Sie unter Hot-Backup erstellen und Sicherung oder Sicherungskopie ändern.
  • Automatische Hot-Backups: Sie müssen eine Aufbewahrungsdauer für Hot-Backups festlegen. Wenn Sie automatische Hot-Backups auf einer SSD-Instanz aktivieren möchten, müssen Sie eine Dauer von 24 Stunden bis 10 Tagen angeben, die die Aufbewahrungsdauer der Richtlinie nicht überschreitet. Diese Einstellung bestimmt, wie lange jede tägliche Sicherung im Hot-Status bleibt, bevor sie für den Rest der Aufbewahrungsdauer automatisch in eine Standardsicherung übergeht. Weitere Informationen finden Sie unter Heiße automatische Sicherungen konfigurieren.

Letzte Sicherung als Hot Backup beibehalten

Um eine schnelle Notfallwiederherstellung mit den Speicherkosten in Einklang zu bringen, können Sie nur die letzte Sicherung als Hot Back‑up aufbewahren und ältere Sicherungen als Standardsicherungen speichern:

  • Tägliche automatische Sicherungen: Konfigurieren Sie eine automatische Sicherungsrichtlinie mit einer Keep-Hot-Dauer von 24 Stunden oder 1 Tag in der Google Cloud Console. Da Bigtable alle 24 Stunden eine automatische Sicherung erstellt, bleibt jede tägliche Sicherung so lange „Hot“, bis die nächste tägliche Sicherung erstellt wird. Anschließend wird sie für den Rest ihrer Aufbewahrungsdauer automatisch in eine Standardsicherung umgewandelt. Eine Anleitung finden Sie unter Automatische Hot-Backups konfigurieren.
  • On-Demand-Sicherungen: Wenn Sie Hot Backups nach einem wiederkehrenden Zeitplan erstellen, legen Sie die Übergangszeit von „Hot“ zu „Standard“ für jede Sicherung auf den Zeitpunkt fest, zu dem das nächste Hot Backup geplant ist (mindestens 24 Stunden nach dem Startzeitpunkt der Sicherungserstellung). Wenn diese Zeit erreicht ist, wird die ältere Sicherung automatisch in eine Standardsicherung umgewandelt, während die neueste Sicherung „hot“ bleibt. Eine Anleitung finden Sie unter Hot-Backup erstellen.

Einschränkungen für Hot Backups

Für Hot-Back-ups gelten die folgenden Einschränkungen:

  • Sie können ein Hot Backup in ein Standard-Backup umwandeln, aber kein Standard-Backup in ein Hot Backup.
  • Sie können On-Demand-Hot-Backups nur für Tabellen in SSD-Instanzen erstellen und automatische Hot-Backups nur für Tabellen in SSD-Instanzen konfigurieren. In HDD-Instanzen können keine Hot Backups erstellt werden.
  • Bigtable unterstützt keine Hot Backups für Tabellen mit aktiviertem mehrstufigem Speicher. Weitere Informationen finden Sie unter Übersicht über gestaffelten Speicher.
  • Eine Kopie eines Hot Backups ist immer eine Standardsicherung. Die Sicherungskopie bietet nicht dieselbe schnelle Wiederherstellung der Produktionsleistung und Bereitstellung mit geringer Latenz wie das ursprüngliche Hot Backup.

Mit Bigtable-Sicherungen arbeiten

Die folgenden Aktionen sind für Bigtable-Sicherungen verfügbar. In allen Fällen müssen das Zielprojekt, die Zielinstanz und der Zielcluster bereits vorhanden sein. Sie können diese Ressourcen nicht im Rahmen eines Sicherungsvorgangs erstellen.

  1. Sie können keine Kopie einer Sicherungskopie erstellen.
  2. Eine Kopie einer Sicherung ist immer eine Standardsicherung, auch wenn die Quelle ein Hot Backup ist.
Aktion Zieloptionen
Standardsicherung erstellen
  • Beliebiger Cluster in derselben Instanz wie die Quelltabelle
Hot Backup erstellen
  • Beliebiger Cluster in derselben Instanz wie die Quelltabelle. Die Instanz muss SSD-Speicher verwenden.
Aus einer Standard- oder Hot-Sicherung in einer neuen Tabelle wiederherstellen
  • Beliebige Instanz
  • Beliebige Bigtable-Region
  • Beliebiges Projekt
Sicherung kopieren1, 2
  • Beliebige Instanz
  • Beliebige Bigtable-Region
  • Beliebiges Projekt

Unter Sicherungen verwalten finden Sie eine detaillierte Anleitung zu diesen Aktionen sowie zu Vorgängen wie dem Aktualisieren und Löschen von Sicherungen.

So verwenden Sie Bigtable-Sicherungen:

Sicherungsspeicher

Eine Tabellensicherung, die Sie manuell oder programmatisch erstellen, wird in einem einzelnen Cluster gespeichert, den Sie angeben. Wenn die automatische Sicherung aktiviert ist, speichert Bigtable eine Sicherung auf jedem Cluster in der Instanz. In der Enterprise Plus-Version können Sie Clusterstandorte auswählen, an denen die automatische Sicherung aktiviert ist.

Wenn Ihr Cluster beim Erstellen einer Sicherung die empfohlenen Limits für die CPU- oder Speicherauslastung überschreitet, kann sich die Erstellung der Sicherung verzögern. Weitere Informationen finden Sie unter CPU- und Laufwerksnutzung.

Eine Sicherung einer Tabelle umfasst alle Daten, die zum Zeitpunkt der Erstellung der Sicherung in der Tabelle enthalten waren, und zwar in dem Cluster, in dem die Sicherung erstellt wird. Eine Sicherung ist nie größer als die Quelltabelle zum Zeitpunkt der Sicherung.

Bigtable-Sicherungen erfolgen inkrementell. Wie viel Speicher eine Sicherung belegt, hängt von der Größe der Tabelle und dem Umfang ab, in dem sie Speicher mit unveränderten Daten für die ursprüngliche Tabelle oder andere Sicherungen derselben Tabelle freigeben kann. Aus diesem Grund hängt die Größe einer Sicherung seit der vorherigen Sicherung von der Datenabweichung ab.

Sie können bis zu 150 Sicherungen pro Tabelle und Cluster erstellen.

Sie können eine Tabelle mit einer Sicherung löschen. Zum Schutz Ihrer Sicherungen können Sie Folgendes nicht löschen:

  • Ein Cluster, der eine oder mehrere Sicherungen enthält. Wenn Sie den Cluster löschen möchten, müssen Sie diese Sicherungen löschen oder warten, bis sie ablaufen.
  • Ein Cluster, der in der Richtlinie für die automatische Sicherung einer Tabelle als Speicherort konfiguriert ist. Wenn Sie den Cluster löschen möchten, müssen Sie zuerst die Richtlinie für automatische Sicherungen aktualisieren, um den Clusterstandort zu entfernen, oder die automatische Sicherung für die Tabelle deaktivieren.
  • Eine Instanz, die in einem Cluster eine oder mehrere Sicherungen enthält.

Eine Sicherung ist nach dem Wiederherstellen in einer neuen Tabelle noch vorhanden. Sie können sie löschen oder ablaufen lassen, wenn Sie sie nicht mehr benötigen. Der Sicherungsspeicher wird nicht auf das Knotenspeicherlimit für ein Projekt angerechnet.

Die Daten in Sicherungen sind verschlüsselt.

Kundenbindung

Mit Bigtable-Sicherungen können Sie Ihre Daten für einen bestimmten Zeitraum aufbewahren. Sie können die Aufbewahrungsdauer für einzelne Sicherungen oder als Teil einer Richtlinie für automatische Sicherungen konfigurieren:

  • Die Aufbewahrungsdauer beginnt mit dem Erstellen der Sicherung.
  • Die Standardaufbewahrungsdauer für Tabellen mit aktivierter automatischer Sicherung beträgt sieben Tage.
  • Sie können eine benutzerdefinierte Aufbewahrungsdauer für eine Richtlinie für automatische Sicherungen von bis zu 90 Tagen sowohl in der Enterprise- als auch in der Enterprise Plus-Version konfigurieren. Für einzelne On-Demand-Sicherungen oder wenn Sie die Aufbewahrungsdauer einer vorhandenen Sicherung aktualisieren, können Sie in der Enterprise-Version bis zu 90 Tage oder in der Enterprise Plus-Version bis zu 365 Tage angeben.
  • Wenn Sie eine Kopie einer Sicherung erstellen, beträgt die maximale Aufbewahrungsdauer für die Kopie 30 Tage ab dem Zeitpunkt, an dem die Kopie erstellt wurde.
  • Beim Erstellen einer Sicherung können Sie anstelle einer Aufbewahrungsdauer ein Ablaufdatum angeben. Ein Ablaufdatum ist ein absolutes Datum und eine absolute Uhrzeit, während eine Aufbewahrungsdauer eine Dauer angibt. Beide Methoden führen zu einer Ablaufzeit, die denselben Regeln und Einschränkungen unterliegt.
  • Wenn Sie ein Hot Backup in eine Standardsicherung umwandeln, ändern sich weder die Aufbewahrungsdauer noch die Ablaufzeit. Bei On-Demand-Hot-Backups ist die Festlegung einer Übergangszeit von „Hot“ zu „Standard“ optional, während für automatische Hot-Backups eine Aufbewahrungsdauer für „Hot“ erforderlich ist.

Sie können die Aufbewahrungsdauer für eine Sicherung oder für eine Richtlinie für automatische Sicherungen ändern. Weitere Informationen finden Sie unter Sicherung oder Sicherungskopie ändern und Richtlinie für automatische Sicherungen aktualisieren.

Nach der Wiederherstellung

Die Speicherkosten für eine neue Tabelle, die aus einer Sicherung wiederhergestellt wurde, entsprechen denen anderer beliebiger Tabellen.

Eine aus einer Sicherung wiederhergestellte Tabelle belegt möglicherweise nicht denselben Speicherplatz wie die Originaltabelle und kann nach der Wiederherstellung kleiner sein. Der Größenunterschied hängt davon ab, wie lange die Verdichtung kürzlich im Quell- und Zielcluster aufgetreten ist.

Da die Verdichtung rollierend erfolgt, kann es vorkommen, dass die Verdichtung erfolgt, sobald die Tabelle erstellt wurde. Die Verdichtung kann jedoch bis zu eine Woche dauern.

Eine neue Tabelle, die aus einer Sicherung wiederhergestellt wurde, übernimmt nicht die Richtlinien für die automatische Speicherbereinigung der Quelltabelle. Konfigurieren Sie Richtlinien für die automatische Speicherbereinigung in der neuen Tabelle, bevor Sie neue Daten in die Tabelle schreiben. Weitere Informationen finden Sie unter automatische Speicherbereinigung konfigurieren.

Kosten

Beim Arbeiten mit Sicherungen fallen die Standardnetzwerkkosten an. Sicherungsvorgänge, einschließlich Erstellen, Kopieren oder Wiederherstellen aus einer Sicherung, werden Ihnen nicht in Rechnung gestellt.

Speicherkosten

Die Speicherkosten für Standardsicherungen und Hot Backups unterscheiden sich.

Kosten für Standardsicherungsspeicher

Für das Speichern einer Standardsicherung oder einer Kopie einer Sicherung wird Ihnen der Standardtarif für den Sicherungsspeicher für die Region berechnet, in der sich der Cluster mit der Sicherung oder Sicherungskopie befindet.

Eine Standardsicherung ist eine vollständige logische Kopie einer Tabelle. Im Hintergrund optimiert Bigtable die Speicherauslastung für Standardsicherungen. Dies bedeutet, dass eine Standardsicherung inkrementell ist. Sie nutzt den physischen Speicher mit der ursprünglichen Tabelle oder andere Sicherungen der Tabelle gemeinsam, sofern dies möglich ist. Aufgrund der integrierten Speicheroptimierungen von Bigtable sind die Kosten für das Speichern einer Standardsicherung oder einer Kopie einer Sicherung manchmal geringer als die Kosten für eine vollständige physische Kopie der Tabellensicherung.

In replizierten Instanzen mit aktivierter automatischer Sicherung können die Speicherkosten höher sein, da täglich Sicherungen für jeden Cluster erstellt werden. In der Enterprise Plus-Version können Sie diese Kosten senken, indem Sie automatische Sicherungen nur für Cluster an bestimmten Standorten aktivieren.

Kosten für Hot-Backup-Speicher

Für das Speichern eines Hot Backups wird Ihnen der Speichertarif für Hot Backups für die Region berechnet, in der sich der Cluster mit dem Hot Backup befindet.

Da ein Hot Backup in einem bereiten Zustand gespeichert wird, der für eine schnelle Wiederherstellung optimiert ist, werden Ihnen die Kosten für die Speicherung der gesamten logischen Kopie der Tabelle in Rechnung gestellt, nicht für inkrementelle Teile, wie es bei einer Standardsicherung der Fall ist.

Wenn ein Hot Backup in eine Standardsicherung übergeht, einschließlich wenn die Aufbewahrungsdauer eines automatischen Hot Backups abläuft, wird Ihnen der Speicherpreis für das Hot Backup berechnet, solange das Backup heiß ist, und der Speicherpreis für die Standardsicherung nach dem Übergang. Für die Umstellung selbst fallen keine zusätzlichen Gebühren an. Informationen zum Prüfen der konfigurierten Aufbewahrungsdauer für eine Tabelle finden Sie unter Richtlinie für automatische Sicherungen ansehen. Weitere Informationen zu den Preisen für Sicherungsspeicher finden Sie unter Preise.

Kosten beim Kopieren einer Sicherung

Wenn Sie eine Kopie einer Sicherung in einer anderen Region als der Quellsicherung erstellen, werden Ihnen die Standardnetzwerktarife für die Kosten des Kopierens der Daten in den Zielcluster in Rechnung gestellt. Wenn Sie eine Kopie in derselben Region wie die Quellsicherung erstellen, fallen keine Gebühren für den Netzwerkverkehr an.

Kosten für die Wiederherstellung

Wenn Sie eine neue Tabelle aus einer Sicherung wiederherstellen, werden Ihnen die Netzwerkkosten für die Replikation in Rechnung gestellt. Wenn sich die neue Tabelle in einer Instanz mit Replikation befindet, werden Ihnen einmalige Replikationskosten in Rechnung gestellt, damit die Daten in alle Cluster in der Instanz kopiert werden.

Wenn Sie die Instanz in einer anderen Instanz wiederherstellen, als die Sicherung erstellt wurde, und die Instanz der Sicherung und die Zielinstanz nicht mindestens einen Cluster in derselben Region haben, werden Ihnen einmalig die Kosten für die erste Kopie der Daten in den Zielcluster zu den Standardnetzwerktarifen in Rechnung gestellt.

CMEK

Wenn Sie eine Sicherung in einem Cluster erstellen, der durch einen vom Kunden verwalteten Verschlüsselungsschlüssel (Customer-Managed Encryption Key, CMEK) geschützt ist, wird die Sicherung an die primäre Version des CMEK-Schlüssels des Clusters angepinnt zum Zeitpunkt an dem sie vorgenommen wird. Nachdem die Sicherung erstellt wurde, können der Schlüssel und die Schlüsselversion nicht mehr geändert werden, auch wenn der KMS-Schlüssel rotiert wird.

Wenn Sie aus einer Sicherung wiederherstellen, muss die Schlüsselversion, an die die Sicherung angepinnt ist, aktiviert sein, damit die Sicherung entschlüsselt werden kann. Die neue Tabelle wird mit der neuesten primären Version des CMEK-Schlüssels für jeden Cluster in der Zielinstanz geschützt. Wenn Sie von einer CMEK-geschützten Sicherung in einer anderen Instanz wiederherstellen möchten, muss die Zielinstanz ebenfalls CMEK-geschützt sein, aber nicht dieselbe CMEK-Konfiguration wie die Quellinstanz haben.

Überlegungen zur Replikation

In diesem Abschnitt werden zusätzliche Konzepte beschrieben, mit denen Sie verstehen, wann eine Tabelle in einer Instanz, die Replikation verwendet, gesichert und wiederhergestellt wird.

Replikation und Sicherung

Wenn Sie eine Sicherung einer Tabelle in einer replizierten Instanz manuell erstellen, wählen Sie den Cluster aus, in dem Sie die Sicherung erstellen und speichern möchten. Bei Tabellen mit aktivierten automatischen Sicherungen wird täglich eine Sicherung für jeden Cluster in der Instanz erstellt. In der Enterprise Plus-Version können Sie die automatische Sicherung auf Cluster an bestimmten Standorten beschränken.

Sie müssen das Schreiben in den Cluster, der die Sicherung enthält, nicht anhalten. Sie sollten aber wissen, wie Bigtable replizierte Schreibvorgänge in den Cluster verarbeitet.

Eine Sicherung ist eine Kopie der Tabelle in ihrem Zustand auf dem Cluster, in dem die Sicherung zum Zeitpunkt der Sicherung erstellt wird. Tabellendaten, die noch nicht von einem anderen Cluster in der Instanz repliziert wurden, sind nicht in der Sicherung enthalten.

Jede Sicherung hat eine Start- und Endzeit. Schreibvorgänge, die kurzzeitig vor oder während des Sicherungsvorgangs an den Cluster gesendet werden, sind nicht in der Sicherung enthalten. Zwei Faktoren beeinflussen diese Unsicherheit:

  • Es kann sein, dass ein Schreibvorgang an einen Abschnitt der Tabelle gesendet wird, den die Sicherung bereits kopiert hat.
  • Ein Schreibvorgang in einen anderen Cluster wurde möglicherweise nicht in den Cluster repliziert, der die Sicherung enthält.

Mit anderen Worten: Es besteht die Möglichkeit, dass einige Schreibvorgänge mit Zeitstempeln vor dem Zeitpunkt der Sicherung nicht in der Sicherung enthalten sind.

Wenn diese Inkonsistenz für Ihre geschäftlichen Anforderungen nicht akzeptabel ist, können Sie ein Konsistenztoken für Ihre Schreibanfragen verwenden, um sicherzustellen, dass alle replizierten Schreibvorgänge in einer Sicherung enthalten sind.

Sicherungen replizierter Tabellen, die im Rahmen einer automatischen Sicherung erstellt werden, sind keine exakten Kopien voneinander, da die Sicherungszeiten von Cluster zu Cluster variieren können.

Replikation und Wiederherstellung

Wenn Sie eine Sicherung in einer neuen Tabelle wiederherstellen, beginnt die Replikation zu und von den anderen Clustern in der Instanz sofort, nachdem der Wiederherstellungsvorgang auf dem Zielcluster abgeschlossen ist.

Leistung

Beachten Sie beim Erstellen von Sicherungen die folgenden Best Practices, um eine optimale Leistung zu gewährleisten.

Leistung beim Sichern

Das Erstellen einer Sicherung dauert in der Regel weniger als eine Minute, kann aber bis zu einer Stunde dauern. Unter normalen Umständen wirkt sich die Sicherungserstellung nicht auf die Bereitstellungsleistung aus.

Für eine optimale Leistung sollten Sie eine einzelne Tabelle nicht öfter als einmal alle fünf Minuten sichern. Wenn häufiger Sicherungen erstellt werden, kann dies zu einer steigenden Bereitstellungslatenz führen.

Leistung bei der Wiederherstellung

Die Wiederherstellung aus einer Sicherung in eine Tabelle in einer Instanz mit einem einzelnen Cluster dauert einige Minuten. Bei replizierten Instanzen dauert die Wiederherstellung länger, da die Daten in alle Cluster kopiert werden müssen. Bigtable wählt immer die effizienteste Route zum Kopieren von Daten aus.

Wenn Sie die Instanz in einer anderen Instanz wiederherstellen, als die Sicherung erstellt wurde, dauert die Wiederherstellung länger als bei einer Wiederherstellung in derselben Instanz. Dies gilt insbesondere, wenn die Zielinstanz keinen Cluster in derselben Zone wie der Cluster hat, in dem die Sicherung erstellt wurde.

Bei größeren Tabellen dauert die Wiederherstellung länger als bei kleineren Tabellen.

Wenn Sie eine SSD-Instanz haben, kann es nach dem Abschluss einer Wiederherstellung zu einer höheren Leselatenz kommen, während die Tabelle optimiert wird. Sie können während der Wiederherstellung jederzeit den Status prüfen, um festzustellen, ob die Optimierung noch läuft.

Wenn Sie die Instanz in einer anderen Instanz wiederherstellen, als die Sicherung erstellt wurde, kann es sein, dass die Zielinstanz HDD oder SSD-Speicher verwendet. Sie muss nicht den gleichen Speichertyp wie die Quellinstanz verwenden.

Zugriffssteuerung

IAM-Berechtigungen steuern den Zugriff auf Sicherungs- und Wiederherstellungsvorgänge. Sicherungsberechtigungen werden auf Instanzebene vorgenommen und auf alle Sicherungen in der Instanz angewendet.

Das Konto, das Sie zum Erstellen einer Sicherung einer Tabelle verwenden, muss die Berechtigung zum Lesen der Tabelle und zum Erstellen von Sicherungen in der Instanz haben, in der sich die Tabelle befindet (der Quellinstanz).

Das Konto, das Sie zum Kopieren einer Sicherung verwenden, muss die Berechtigung zum Lesen der Quellsicherung und zum Erstellen einer Sicherung in der Zielinstanz und im Zielprojekt haben.

Das Konto, das Sie zum Wiederherstellen einer neuen Tabelle aus einer Sicherung verwenden, muss die Berechtigung zum Erstellen einer Tabelle in der Instanz haben, in der Sie die Wiederherstellung ausführen.

Aktion Erforderliche IAM-Berechtigung
Sicherung erstellen bigtable.tables.readRows, bigtable.backups.create
Eine Sicherung abrufen bigtable.backups.get
Sicherungen auflisten bigtable.backups.list
Sicherung löschen bigtable.backups.delete
Sicherung aktualisieren bigtable.backups.update
Sicherung kopieren bigtable.backups.read, bigtable.backups.create
Aus einer Sicherung in einer neuen Tabelle wiederherstellen bigtable.tables.create, bigtable.backups.restore
Einen Vorgang abrufen bigtable.instances.get
Vorgänge auflisten bigtable.instances.get

Best Practices

Bevor Sie eine Sicherungsstrategie erstellen, sollten Sie die folgenden Best Practices beachten. Weitere Informationen zur Planung der Notfallwiederherstellung finden Sie im Bigtable-Abschnitt von Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur.

Sicherungen erstellen

  • Sichern Sie Tabellen nicht öfter als einmal alle fünf Minuten.
  • Wenn Sie eine Tabelle sichern, die Replikation verwendet, wählen Sie den Cluster zum Speichern der Sicherung aus, nachdem Sie die folgenden Faktoren berücksichtigt haben:
    • Kosten: Ein Cluster in Ihrer Instanz befindet sich möglicherweise in einer kostengünstigeren Region als die anderen.
    • In der Nähe Ihres Anwendungsservers. Sie sollten die Sicherung möglichst in der Nähe Ihrer Bereitstellungsanwendung speichern.
  • Wenn Sie sicherstellen möchten, dass alle replizierten Schreibvorgänge in einer Sicherung enthalten sind, wenn Sie eine Tabelle in einer Instanz mit Replikation sichern, verwenden Sie ein Konsistenztoken für Ihre Schreibanfragen.

Daten aus Sicherungen wiederherstellen

  • Planen Sie im Voraus, wie Sie die neue Tabelle benennen wollen, wenn Sie eine Sicherung wiederherstellen müssen. Der wichtigste Punkt ist, dass Sie sich im Voraus vorbereiten, damit Sie nicht entscheiden müssen, wenn Sie mit einem Problem konfrontiert sind.
  • Wenn Sie eine Tabelle aus einem anderen Grund als versehentlichem Löschen wiederherstellen, achten Sie darauf, dass alle Lese- und Schreibvorgänge an die neue Tabelle gesendet werden, bevor Sie die ursprüngliche Tabelle löschen.
  • Wenn Sie die Wiederherstellung in einer anderen Instanz planen, erstellen Sie die Zielinstanz, bevor Sie die Wiederherstellung der Sicherung starten.
  • Um eine langsame Tabellenwiederherstellung zu vermeiden, warten Sie, bis ein Wiederherstellungsvorgang abgeschlossen ist, bevor Sie eine weitere Wiederherstellung für dieselbe Quelltabelle in derselben Zone initiieren.
  • Warten Sie nach der Erstellung mindestens eine Stunde, bevor Sie eine Wiederherstellung aus einer Standardsicherung durchführen. Wenn Sie eine schnellere Wiederherstellung benötigen, verwenden Sie stattdessen ein Hot Backup.

Kontingente und Limits

Sicherungs- und Wiederherstellungsanfragen sowie Sicherungsspeicher unterliegen den Bigtable-Kontingenten und -Limits.

Beschränkungen

Die folgenden Einschränkungen gelten für Bigtable-Sicherungen:

Allgemein

  • Sie können Daten nicht direkt aus einer Sicherung lesen.
  • Eine Sicherung ist eine Version einer Tabelle in einem einzelnen Cluster zu einem bestimmten Zeitpunkt. Sicherungen stellen keinen konsistenten Zustand dar. Dasselbe gilt auch für Sicherungen derselben Tabelle in verschiedenen Clustern.
  • Sie können nicht mehr als eine Tabelle in einem einzelnen Vorgang sichern.
  • Bigtable-Sicherungen können nicht exportiert, kopiert oder in einen anderen Dienst wie Cloud Storage verschoben werden.
  • Bigtable-Sicherungen enthalten nur Bigtable-Daten und sind nicht in Sicherungen für andere Google-Dienste eingebunden oder mit diesen verknüpft.
  • Sie können keine Sicherung einer Ansicht erstellen.

Wiederherstellen

  • Sie können eine Sicherung nicht in einer vorhandenen Tabelle wiederherstellen.
  • Sie können nur Instanzen wiederherstellen, die bereits vorhanden sind. Bigtable erstellt bei der Wiederherstellung aus einer Sicherung keine neue Instanz. Wenn die in einer Wiederherstellungsanfrage angegebene Zielinstanz nicht vorhanden ist, schlägt der Wiederherstellungsvorgang fehl.
  • Wenn Sie die Sicherung einer Tabelle in einem SSD-Cluster wiederherstellen und dann die neu wiederhergestellte Tabelle löschen, kann das Löschen der Tabelle eine Weile dauern, da Bigtable auf das Beenden der Tabellenoptimierung wartet.

Kopieren

  • Sie können keine Kopie einer Sicherung erstellen, die innerhalb von 24 Stunden abläuft.
  • Sie können keine Kopie einer Sicherungskopie erstellen.

CMEK

  • Eine durch CMEK geschützte Sicherung muss in einer neuen Tabelle in einer CMEK-geschützten Instanz wiederhergestellt werden.
  • Wenn Sie eine Kopie einer CMEK-geschützten Sicherung erstellen, muss der Zielcluster ebenfalls CMEK-geschützt sein.

Nächste Schritte