Sicherungen

Diese Seite bietet einen Überblick über Sicherungen in Cloud Bigtable.

Mit Bigtable-Sicherungen können Sie eine Kopie des Schemas und der Daten einer Tabelle speichern und später aus der Sicherung in eine neue Tabelle wiederherstellen. Bevor Sie diese Seite lesen, sollten Sie mit den Informationen unter Übersicht über Bigtable und Tabellen verwalten vertraut sein.

Wozu Sicherungen dienen

Sicherungen unterstützen Sie bei der Wiederherstellung nach Datenbeschädigung auf Anwendungsebene oder durch Operatorfehler wie das Löschen einer Tabelle. Sie können eine Sicherung in einer neuen Tabelle wiederherstellen, entweder in der Instanz, in der die Sicherung erstellt wurde, oder in einer anderen Instanz.

Wozu Sicherungen nicht dienen

Sicherungen sind nicht zum Schutz vor regionalen oder zonalen Ausfällen vorgesehen. Verwenden Sie Replikation, wenn Sie ein Failover auf verschiedene Regionen oder Zonen vornehmen müssen.

Sicherungen sind nicht lesbar und eignen sich daher nicht für die Offlineanalyse.

Features

  • Vollständig integriert: Sicherungen werden vollständig vom Bigtable-Dienst verarbeitet, ohne dass ein Import oder Export erforderlich ist.
  • 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 ein benutzerdefiniertes Ablaufdatum, das bis zu 30 Tage nach dem Erstellen der Sicherung reichen kann.
  • Flexible Wiederherstellungsoptionen: Sie können eine Sicherung in einer Tabelle einer anderen Instanz wiederherstellen, in der die Sicherung nicht erstellt wurde.

Mögliche Gründe für die Wiederherstellung in einer anderen Instanz:

  • Sie möchten Abfragen oder Tests für eine Tabelle ausführen, die aus einer Sicherung wiederhergestellt wurde. Sie möchten jedoch nicht, dass sich die Tests auf die Instanz auswirken, in der die Sicherung erstellt wurde.

  • Sie möchten in einer anderen Instanz wiederherstellen, deren Zugriffseinstellungen sich von der Quellinstanz unterscheiden. Sie können z. B. Entwicklern Zugriff für Tests, Fehlerbehebung oder Entwicklung einer Tabelle gewähren, die aus der Sicherung einer Produktionstabelle erstellt wurde und gleichzeitig den eingeschränkten Zugriff auf die Produktionstabelle beibehalten.

  • Sie möchten Daten in eine andere Region verschieben, ohne die Replikationskonfiguration für die Instanz zu ändern, die die Sicherung enthält. Sie können die Sicherung in einer Instanz mit einem Cluster in der Region wiederherstellen, in der Sie Ihre Daten benötigen.

  • Sie möchten einige Daten aus einer Tabelle, die aus einer Sicherung wiederhergestellt wurde, kopieren und in die Quelltabelle schreiben. Sie können beispielsweise die Tabelle in einer anderen Instanz wiederherstellen und dann eine Anwendung mithilfe einer Bigtable-Clientbibliothek oder Dataflow schreiben, die aus der neuen Tabelle liest und die Daten wieder in die Quelltabelle zurück schreibt. Dies kann hilfreich sein, wenn nur einige Daten beschädigt wurden oder wenn Sie einen anderen Grund haben, nur einen Teil einer Tabelle wiederherzustellen.

  • Sie möchten eine Kopie Ihrer Daten auf einer kostengünstigeren Instanz haben, als die die Sie in der Produktion verwenden. Nehmen wir beispielsweise an, Sie haben eine Produktionstabelle mit 700 TB in einer Instanz, die drei SSD-Cluster mit 300 Knoten hat (300 Knoten x 2,5 TB Speicher pro Knoten). Wenn Sie für die Kopie keine Replikation oder niedrige Latenz benötigen, können Sie eine neue Tabelle aus der Sicherung auf einer HDD-Instanz mit einem einzelnen Cluster mit 88 Knoten wiederherstellen (700 TB ÷ 8 TB Speicher pro Knoten). Wenn Sie dagegen eine Kopie dieser 700 TB-Tabelle für dieselbe Instanz wiederherstellen, in der sich die Quelltabelle befindet, müssen Sie bis zu 1.800 Knoten hochskalieren, um die Kopie unterzubringen. Dadurch steigen die Kosten der Produktionsinstanz.

  • Sie möchten den Speichertyp ändern, in dem Ihre Daten gespeichert werden. Sie können Sicherungen verwenden, um Ihre Daten von SSD zu HDD-Speicher oder umgekehrt zu verschieben. Dazu erstellen Sie eine Sicherung der Tabelle, die Sie verschieben möchten, und stellen sie dann in einer Instanz wieder her, die den gewünschten Speichertyp verwendet.

Mit Sicherungen arbeiten

Unter Sicherungen verwalten finden Sie eine detaillierte Anleitung zum Sichern und Wiederherstellen einer Tabelle sowie Vorgänge wie das Aktualisieren und Löschen von Sicherungen.

So verwenden Sie Bigtable-Sicherungen:

Sie können auch direkt auf die API zugreifen. Dies wird aber nur empfohlen, wenn Sie keine Bigtable-Clientbibliothek verwenden können, die Sicherungsaufrufe an die API sendet.

Funktionsweise von Sicherungen

Storage

Eine Tabellensicherung ist eine Ressource auf Clusterebene. Auch wenn sich eine Tabelle in einer Instanz mit mehreren Clustern befindet (d. h., der Cluster verwendet die Replikation), wird eine Sicherung erstellt und nur in einem Cluster dieser Instanz gespeichert.

In einem einzelnen Cluster gespeicherte Sicherung

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. Sie können bis zu 50 Sicherungen pro Tabelle und Cluster erstellen.

Sie können eine Tabelle mit einer Sicherung löschen. Zum Schutz Ihrer Sicherungen können Sie keine Cluster löschen, die eine Sicherung enthalten. Außerdem können Sie keine Instanzen löschen, die in einem Cluster eine oder mehrere Sicherungen enthalten.

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 eines Projekts angerechnet.

Die Daten in Sicherungen sind verschlüsselt und werden in einem proprietären Format gespeichert.

Kosten

Für das Erstellen und Wiederherstellen einer Sicherung fallen keine Kosten an.

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

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

Wenn Sie eine Tabelle in einer Instanz wiederherstellen, in der Replikation verwendet wird, werden Ihnen Kosten für eine einmalige Replikation berechnet, um die Daten in alle Cluster der Instanz zu kopieren.

Wenn Sie eine Sicherung in einer anderen Instanz wiederherstellen, also nicht in der Instanz, in der die Sicherung erstellt wurde, dann sollten die Quellinstanz und die Zielinstanz der Sicherung mindestens einen Cluster in derselben Region haben. Andernfalls werden Ihnen die einmaligen Kosten für das erstmalige Kopieren der Daten in den Zielcluster zu den Standard-Netzwerkpreisen in Rechnung gestellt.

CMEK

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

Wenn Sie eine Tabelle 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 ist mit der neuesten primären Version des CMEK-Schlüssels der Zielinstanz geschützt. Wenn Sie also aus einer CMEK-geschützten Sicherung eine Wiederherstellung in einer anderen Instanz ausführen möchten, muss die Zielinstanz denselben CMEK-Schlüssel wie die Quellinstanz verwenden.

Ü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.

Back-ups machen

Wenn Sie eine Sicherung einer Tabelle in einer replizierten Instanz machen, wählen Sie den Cluster aus, in dem Sie die Sicherung erstellen und speichern möchten. Sie müssen die Arbeit in den Cluster, der die Sicherung enthält, nicht mehr anhalten. Sie sollten aber wissen, wie replizierte Schreibvorgänge in den Cluster verarbeitet werden.

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 ist möglicherweise nicht in den Cluster repliziert, der die Sicherung enthält.

Es besteht also die Möglichkeit, dass einige Schreibvorgänge mit einem Zeitstempel vor der Sicherung in der Sicherung nicht enthalten sind. Wenn dies 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.

Wird wiederhergestellt

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 Cluster abgeschlossen ist, in dem die Sicherung gespeichert wurde.

Leistung

Back-ups machen

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 Sicherung einer einzelnen Tabelle nicht mehr als einmal alle fünf Minuten erstellen. Wenn häufiger Sicherungen erstellt werden, kann dies zu einer steigenden Bereitstellungslatenz führen.

Wird wiederhergestellt

Die Wiederherstellung einer Sicherung in einer Tabelle in einer Instanz mit einem einzelnen Cluster dauert einige Minuten. Bei Multi-Cluster-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 auf eine andere Instanz wiederherstellen als die, auf der die Sicherung erstellt wurde, dauert der Wiederherstellungsvorgang länger, als wenn Sie auf dieselbe Instanz wiederherstellen. 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 Ihre Tabellen in SSD-Clustern speichern, 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 (die Quellinstanz).

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 in einer Tabelle wiederherstellen bigtable.tables.create, bigtable.backups.restore
Einen Vorgang abrufen bigtable.instances.get
Vorgänge auflisten bigtable.instances.get

Best Practices

Sicherungen

  • Sichern Sie Tabellen nicht öfter als einmal alle fünf Minuten.
  • Wenn Sie eine Tabelle mit Replikation sichern, wählen Sie den Cluster aus, um die Sicherung zu speichern. Berücksichtigen Sie dabei die folgenden Faktoren:
    • 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.
    • Speicherauslastung Sie benötigen genügend Speicherplatz, um die Sicherung zu sichern, wenn sie größer wird. Je nach Arbeitslast können Cluster mit verschiedenen Größen oder mit unterschiedlicher Laufwerknutzung vorhanden sein. Dies kann den Cluster beeinflussen, den Sie auswählen.
  • 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.

Sicherungen wiederherstellen

  • Planen Sie im Voraus, wie Sie die neue Tabelle benennen wollen, wenn Sie eine Sicherung wiederherstellen müssen. Der entscheidende Punkt ist, dass Sie vorab vorbereitet sein müssen, damit Sie sich nicht entscheiden müssen, sobald ein Problem auftritt.
  • Wenn Sie eine Tabelle aus einem anderen Grund als einem versehentlichen Löschen wiederherstellen, achten Sie darauf, dass alle Lese- und Schreibvorgänge an die neue Tabelle gehen, bevor Sie die ursprüngliche Tabelle löschen.
  • Wenn Sie den Zugriff auf eine andere Instanz wiederherstellen möchten, erstellen Sie die Zielinstanz, bevor Sie die Sicherung wiederherstellen.

Kontingente und Limits

Sicherungs- und Wiederherstellungsanfragen und der Sicherungsspeicher unterliegen den Kontingenten und Limits für Bigtable.

Beschränkungen

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

  • Sie können nicht direkt aus einer Sicherung lesen.
  • Sie können Daten nicht aus einer Sicherung 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.
  • Sicherungen sind zonal und haben die gleichen Verfügbarkeitsgarantien wie der Cluster, in dem die Sicherung erstellt wird. Sicherungen schützen nicht vor regionalen Ausfällen.
  • Eine Sicherung ist eine Version einer Tabelle in einem einzelnen Cluster zu einem bestimmten Zeitpunkt. Sicherungen stellen keinen konsistenten Status dar. Dasselbe gilt auch für Sicherungen derselben Tabelle in verschiedenen Clustern.
  • Sie können in einem Vorgang nicht mehr als eine Tabelle sichern.
  • Bigtable-Sicherungen können nicht exportiert, kopiert oder in einen anderen Dienst wie Cloud Storage verschoben werden.

Nächste Schritte