Bigtable-Sicherungen – Übersicht
Diese Seite bietet eine Übersicht über Bigtable-Sicherungen. Der Inhalt richtet sich an Bigtable-Administratoren und -Entwickler.
Mit Bigtable-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. Sie können Sicherungen manuell erstellen oder die automatische Sicherung aktivieren, damit Bigtable tägliche Sicherungen erstellen kann. Sie können auch eine Kopie einer Sicherung erstellen.
Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen zu Bigtable und Tabellen verwalten vertraut machen.
Features
- Vollständig integriert: Sicherungen werden vollständig vom Bigtable-Dienst verarbeitet, ohne dass ein Import oder Export erforderlich ist.
- Inkrementell: Eine Sicherung teilt sich physischen Speicher mit der Quelltabelle und anderen Sicherungen der Tabelle.
- 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 90 Tage nach der Erstellung der Sicherung liegen kann. Sie können eine Kopie einer Sicherung bis zu 30 Tage lang speichern.
- 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 die automatische Sicherung, damit Bigtable tägliche Sicherungen erstellen kann.
Anwendungsfälle
Sicherungen sind für die folgenden Anwendungsfälle nützlich:
- Geschäftskontinuität
- Gesetzliche Vorschriften
- Tests und Entwicklung
- Notfallwiederherstellung
Betrachten Sie die folgenden Notfallwiederherstellungsszenarien:
| Ziel | Sicherungsstrategie | Wiederherstellungsstrategie |
|---|---|---|
| Schutz vor menschlichen Fehlern : Sie möchten immer eine aktuelle Sicherung Ihrer Daten parat haben, falls sie versehentlich gelöscht oder beschädigt wurden. | Legen Sie den Zeitplan für das Erstellen von Sicherungen fest, der für Ihre Geschäftsanforderungen geeignet ist, z. B. täglich. Optional können Sie regelmäßige Kopien der Sicherungen erstellen und diese in einem anderen Projekt oder einer anderen Region speichern, um die Isolation und den Schutz zu erhöhen. Für noch mehr Schutz sollten Sie die Sicherungskopien in einem Projekt oder einer Instanz mit eingeschränkten Zugriffsberechtigungen speichern. | Stellen Sie eine neue Tabelle aus der Sicherung oder Kopie wieder her und leiten Sie Anfragen dann an die neue Tabelle weiter. |
| Nichtverfügbarkeit von Zonen: Für den unwahrscheinlichen Fall, dass eine Google Cloud-Zone nicht mehr verfügbar ist, müssen Ihre Daten weiterhin verfügbar sein. | Erstellen Sie regelmäßig Sicherungen, z. B. täglich. Erstellen Sie dann regelmäßig eine Kopie der letzten Sicherung und speichern Sie diese in einem oder mehreren Clustern in verschiedenen Zonen (optional in einer anderen Instanz oder einem anderen Projekt). | Wenn die Zone, in der Ihr Bereitstellungscluster nicht mehr verfügbar ist, aus der Remote-Sicherungskopie in einer neuen Tabelle wiederherstellen und Anfragen dann an die neue Tabelle weiterleiten. |
| Datenbeschädigung: Verwenden Sie eine Sicherung, um einige Daten einer Tabelle wiederherzustellen, z. B. wenn ein Teil der Quelltabelle beschädigt wurde. | Erstellen Sie regelmäßig Sicherungen Ihrer Daten. | Stellen Sie die Sicherung in einer neuen Tabelle auf der neuen Instanz wieder her. Schreiben Sie dann 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. |
Mit Bigtable-Sicherungen arbeiten
Die folgenden Aktionen sind für Bigtable-Sicherungen verfügbar. In jedem Fall müssen das Zielprojekt, die Zielinstanz und der Zielcluster bereits vorhanden sein. Sie können diese Ressourcen nicht im Rahmen eines Sicherungsvorgangs erstellen. Sie können keine Kopie einer Sicherungskopie erstellen.
| Aktion | Zieloptionen |
|---|---|
| Sicherung erstellen |
|
| Wiederherstellung aus einer Sicherung in einer neuen Tabelle |
|
| Sicherung kopieren |
|
Unter Sicherungen verwalten finden Sie eine Schritt-für-Schritt-Anleitung zu diesen Aktionen sowie Vorgängen wie dem Aktualisieren und Löschen von Sicherungen.
So verwenden Sie Bigtable-Sicherungen:
- Die Google Cloud Console
- Google Cloud CLI
- Cloud Bigtable-Clientbibliotheken.
Sie können auch direkt auf die Cloud Bigtable Admin API zugreifen. Wir empfehlen dies jedoch nur dann, wenn Sie keine Cloud Bigtable-Clientbibliothek verwenden können, die Sicherungsaufrufe an die API durchführt.
Funktionsweise von Bigtable-Sicherungen
Um eine Sicherung zu erstellen, müssen Sie den Sicherungsspeicher und die Aufbewahrung in Bigtable verstehen.
Sicherungsspeicher
Eine Tabellensicherung kann manuell erstellt werden. Sie können aber auch die automatische Sicherung aktivieren, damit Bigtable tägliche Sicherungen erstellt. Eine Tabellensicherung wird in einem Cluster in einer Instanz gespeichert. Bei manuellen Sicherungen wird die Tabellensicherung in einem Cluster in der von Ihnen ausgewählten Instanz gespeichert. Wenn die automatische Sicherung aktiviert ist, wird in jedem Cluster der Instanz eine Tabellensicherung gespeichert.
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 sind inkrementell. Wie viel Speicher eine Sicherung belegt, hängt von der Größe der Tabelle und dem Umfang ab, in dem die Speicherung unveränderter Daten mit der ursprünglichen Tabelle oder anderen Sicherungen derselben Tabelle gemeinsam genutzt werden kann. Aus diesem Grund hängt die Größe einer Sicherung von der Menge der Datenabweichungen seit der vorherigen Sicherung 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 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 für ein Projekt angerechnet.
Die Daten in Sicherungen sind verschlüsselt.
Aufbewahrung
Sie können eine Aufbewahrungsdauer von bis zu 90 Tagen für eine Sicherung angeben. Wenn Sie eine Kopie einer Sicherung erstellen, beträgt die maximale Aufbewahrungsdauer für die Kopie 30 Tage ab Erstellung der Kopie.
Für Tabellen mit aktivierter automatischer Sicherung beträgt die standardmäßige Aufbewahrungsdauer 3 Tage. Sie können die Aufbewahrungsdauer für eine Sicherung auf bis zu 90 Tage ab dem Zeitpunkt der Sicherungserstellung ändern.
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 beansprucht möglicherweise nicht so viel Speicherplatz wie die ursprüngliche Tabelle und kann nach der Wiederherstellung ihre Größe verkleinern. 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 damit beginnen, neue Daten in die Tabelle zu schreiben. Weitere Informationen finden Sie unter Automatische Speicherbereinigung konfigurieren.
Kosten
Wenn Sie mit Sicherungen arbeiten, fallen Standardnetzwerkkosten an. Sicherungsvorgänge wie das Erstellen, Kopieren oder Wiederherstellen aus einer Sicherung werden Ihnen nicht in Rechnung gestellt.
Speicherkosten
Zum Speichern einer Sicherung oder Kopie einer Sicherung wird Ihnen die Standardrate für Sicherungsspeicher für die Region in Rechnung gestellt, in der sich der Cluster mit der Sicherungskopie befindet.
Eine Sicherung ist eine vollständige logische Kopie einer Tabelle. Im Hintergrund optimiert Bigtable die Speicherauslastung für Sicherungen. Bei dieser Optimierung erfolgt eine Sicherung inkrementell. Sie teilt sich den physischen Speicher mit der ursprünglichen Tabelle oder nach Möglichkeit mit anderen Sicherungen der Tabelle. Aufgrund der integrierten Speicheroptimierung in Bigtable können die Kosten zum Speichern einer Sicherung oder einer Kopie einer Sicherung manchmal unter den Kosten einer vollständigen physischen Kopie der Tabellensicherung liegen.
Bei replizierten Instanzen, bei denen die automatische Sicherung aktiviert ist, können die Speicherkosten höher sein, da täglich Sicherungen pro Cluster erstellt werden.
Kosten beim Kopieren einer Sicherung
Wenn Sie eine Kopie einer Sicherung in einer anderen Region als der Quellsicherung erstellen, werden Ihnen die Standardnetzwerkgebühren für das Kopieren der Daten in den Zielcluster in Rechnung gestellt. Wenn Sie eine Kopie in derselben Region wie die Quellsicherung erstellen, wird Ihnen kein Netzwerktraffic in Rechnung gestellt.
Kosten bei der 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 Wiederherstellung in einer anderen Instanz durchführen, als die, in der die Sicherung erstellt wurde, und die Instanz der Sicherung und die Zielinstanz nicht mindestens einen Cluster in derselben Region haben, werden Ihnen einmalig Kosten für die erste Datenkopie in den Zielcluster zu den Standard-Netzwerkpreisen 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 Schlüssel und Schlüsselversion nicht mehr geändert werden, auch nicht, 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 aus einer CMEK-geschützten Sicherung eine Wiederherstellung in einer anderen Instanz ausführen möchten, muss die Zielinstanz ebenfalls CMEK-geschützt sein; sie muss jedoch 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 Tabelle manuell in einer replizierten Instanz sichern, wählen Sie den Cluster aus, in dem Sie die Sicherung erstellen und speichern möchten. Bei Tabellen mit aktivierter automatischer Sicherung wird für jeden Cluster in der Instanz eine tägliche Sicherung erstellt.
Sie müssen das Schreiben in den Cluster, der die Sicherung enthält, nicht 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 wurde 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. Dies gilt auch für Sicherungen, die erstellt werden, wenn die automatische Sicherung aktiviert ist. Die Sicherungen einer Instanz sind keine exakten Kopien voneinander, da die Sicherungszeiten von Cluster zu Cluster variieren können.
Wenn diese Inkonsistenz für Ihre Geschäftsanforderungen nicht akzeptabel ist, können Sie für Ihre Schreibanfragen ein Konsistenztoken verwenden, um dafür zu sorgen, dass alle replizierten Schreibvorgänge in einer Sicherung enthalten sind.
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 Sicherung einer einzelnen Tabelle nicht öfter als einmal alle fünf Minuten erstellen. Wenn häufiger Sicherungen erstellt werden, kann dies zu einer steigenden Bereitstellungslatenz führen.
Leistung beim Wiederherstellen
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 (die 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 dem 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 | |
| Wiederherstellung aus einer Sicherung in einer neuen Tabelle | bigtable.tables.create, bigtable.backups.restore |
| Einen Vorgang abrufen | bigtable.instances.get |
| Vorgänge auflisten | bigtable.instances.get |
Best Practices
Beachten Sie die folgenden Best Practices, bevor Sie eine Sicherungsstrategie erstellen.
Sicherungen erstellen
- Sichern Sie Tabellen nicht öfter als einmal alle fünf Minuten.
- Wenn Sie eine Tabelle mit Replikation sichern, wählen Sie den Cluster zum Speichern der Sicherung aus. 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 Ihre Sicherungen zu speichern, während sie sich ansammeln. 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 beim Sichern einer Tabelle in einer Instanz mit Replikation sicherstellen müssen, dass alle replizierten Schreibvorgänge in einer Sicherung enthalten sind, verwenden Sie für Ihre Schreibanfragen ein Konsistenztoken.
Aus 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:
Allgemein
- Es ist nicht möglich, Daten direkt aus einer Sicherung zu lesen.
- 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.
- Bigtable-Sicherungen enthalten nur Bigtable-Daten und sind nicht in Sicherungen für andere Google-Dienste eingebunden oder stehen damit in Zusammenhang.
Wird wiederhergestellt
- Sie können keine Daten 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.
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 auch der Zielcluster CMEK-geschützt sein.