Bigtable-Sicherungen – Übersicht
Diese Seite bietet einen Überblick über Bigtable-Sicherungen. Der hier dargestellte 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 diese später 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 unter Bigtable-Übersicht und Tabellen verwalten vertraut gemacht haben.
Features
- Vollständig integriert: Sicherungen werden vollständig vom Bigtable-Dienst verarbeitet, ohne dass ein Import oder Export erforderlich ist.
- Inkrementell: Eine Sicherung teilt den 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 Erstellung der Sicherung betragen 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 Szenarien für die Notfallwiederherstellung:
| Ziel | Sicherungsstrategie | Wiederherstellungsstrategie |
|---|---|---|
| Schutz vor menschlichen Fehlern: Sie möchten für den Fall eines versehentlichen Löschens oder einer Beschädigung immer eine aktuelle Sicherung Ihrer Daten parat haben. | Legen Sie einen Zeitplan für die Erstellung von Sicherungen fest, der für Ihre Geschäftsanforderungen geeignet ist (z. B. täglich). Optional können Sie regelmäßig Kopien der Sicherungen erstellen und in einem anderen Projekt oder einer anderen Region speichern, um die Isolation und den Schutz zu verbessern. Für noch mehr Schutz sollten Sie die Sicherungskopien in einem Projekt oder einer Instanz mit eingeschränkten Zugriffsberechtigungen speichern. | Stellen Sie aus der Sicherung oder Kopie eine neue Tabelle wieder her und leiten Sie die Anfragen dann an die neue Tabelle weiter. |
| Nichtverfügbarkeit der Zone : Sie müssen dafür sorgen, dass Ihre Daten im unwahrscheinlichen Fall, dass eine Google Cloud-Zone nicht mehr verfügbar ist, weiterhin verfügbar sind. | Erstellen Sie regelmäßig, z. B. täglich, Sicherungen. Erstellen Sie dann regelmäßig eine Kopie der letzten Sicherung und speichern Sie sie in einem oder mehreren Clustern in verschiedenen Zonen (optional in einer anderen Instanz oder einem anderen Projekt). | Wenn die Zone, in der der Bereitstellungscluster nicht mehr verfügbar ist, aus der Remotesicherungskopie in einer neuen Tabelle wiederhergestellt wird und Anfragen dann an die neue Tabelle weitergeleitet werden. |
| Datenbeschädigung: Verwenden Sie eine Sicherung, um einige Daten einer Tabelle wiederherzustellen, z. B. wenn ein Teil der Quelltabelle beschädigt ist. | 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 mit Dataflow, die aus der neuen Tabelle liest und die Daten dann zurück 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 Instanz und der Cluster bereits vorhanden sein. Sie können diese Ressourcen nicht im Rahmen eines Sicherungsvorgangs erstellen. Sie können keine Sicherungskopien erstellen.
| Aktion | Zieloptionen |
|---|---|
| Sicherung erstellen |
|
| Aus einer Sicherung in einer neuen Tabelle wiederherstellen |
|
| Sicherung kopieren |
|
Unter Sicherungen verwalten finden Sie detaillierte Anleitungen zu diesen Aktionen sowie zu 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 sendet.
So funktionieren Bigtable-Sicherungen
Um eine Sicherung zu erstellen, müssen Sie sich mit dem Sicherungsspeicher und der Aufbewahrung in Bigtable vertraut machen.
Sicherungsspeicher
Sie können eine Tabellensicherung manuell erstellen oder die automatische Sicherung aktivieren, damit Bigtable tägliche Sicherungen erstellen kann. Eine Tabellensicherung wird in einem Cluster in einer Instanz gespeichert. Bei manuellen Sicherungen wird die Tabellensicherung in einem Cluster in der ausgewählten Instanz gespeichert. Wenn die automatische Sicherung aktiviert ist, wird eine Tabellensicherung in jedem Cluster in der Instanz 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 Speicherplatz eine Sicherung belegt, hängt von der Größe der Tabelle und dem Ausmaß ab, in dem sie den Speicher unveränderter Daten mit der Originaltabelle oder anderen Sicherungen derselben Tabelle teilen kann. Aus diesem Grund hängt die Größe einer Sicherung von der Größe der Datendivergenz 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 für eine Sicherung eine Aufbewahrungsdauer von bis zu 90 Tagen festlegen. 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 Erstellungszeitpunkt der Sicherung ä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 verbraucht möglicherweise nicht den gleichen Speicherplatz wie die ursprüngliche Tabelle. Außerdem kann sie nach der Wiederherstellung kleiner werden. 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 die 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
Bei der Arbeit mit Sicherungen fallen die Standard-Netzwerkkosten an. Für Sicherungsvorgänge wie das Erstellen, Kopieren oder Wiederherstellen aus einer Sicherung fallen keine Kosten an.
Speicherkosten
Zum Speichern einer Sicherung oder einer Kopie einer Sicherung wird Ihnen der Standardpreis für den Sicherungsspeicher für die Region in Rechnung gestellt, in der sich der Cluster mit der Sicherungs- oder Sicherungskopie befindet.
Eine Sicherung ist eine vollständige logische Kopie einer Tabelle. Im Hintergrund optimiert Bigtable die Speicherauslastung für Sicherungen. Diese Optimierung bedeutet, dass eine Sicherung inkrementell ist. Sie teilt den physischen Speicher mit der ursprünglichen Tabelle oder nach Möglichkeit mit anderen Sicherungen der Tabelle. Aufgrund der integrierten Speicheroptimierungen von Bigtable können die Kosten für das Speichern einer Sicherung oder einer Kopie einer Sicherung manchmal geringer sein als die Kosten für eine vollständige physische Kopie der Tabellensicherung.
In replizierten Instanzen, in denen die automatische Sicherung aktiviert ist, können die Speicherkosten höher sein, da Sicherungen täglich in jedem Cluster erstellt werden.
Kosten beim Kopieren einer Sicherung
Wenn Sie eine Kopie einer Sicherung in einer anderen Region als der Quellsicherung erstellen, werden Ihnen Standardnetzwerkpreise für das Kopieren der Daten in den Zielcluster berechnet. Wenn Sie eine Kopie in derselben Region wie die Quellsicherung erstellen, fallen für den Netzwerktraffic keine Kosten an.
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 Daten in einer anderen Instanz wiederherstellen 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 einmalige Kosten für die erste Kopie in den Zielcluster zu den Standard-Netzwerkpreisen berechnet.
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 inakzeptabel ist, können Sie ein Konsistenztoken mit Ihren Schreibanfragen 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 für eine optimale Leistung zu sorgen.
Leistung bei der Sicherung
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 beim Wiederherstellen
Die Wiederherstellung aus einer Sicherung in eine Tabelle in einer Instanz mit einem einzelnen Cluster dauert einige Minuten. In 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 im Projekt 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
Die folgenden Best Practices müssen beachtet werden, 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 aus, in dem die Sicherung gespeichert werden soll. 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 sicherstellen müssen, dass beim Sichern einer Tabelle in einer Instanz mit Replikation alle replizierten Schreibvorgänge in eine Sicherung aufgenommen werden, verwenden Sie für Ihre Schreibanfragen ein Konsistenztoken.
Daten 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
- Sie können 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 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 andere Google-Dienste integriert oder sind damit verbunden.
Wird wiederhergestellt
- Sie können aus einer Sicherung keine Wiederherstellung in einer vorhandenen Tabelle vornehmen.
- 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, deren Ablauf in den nächsten 24 Stunden liegt.
- 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 Sicherung erstellen, die CMEK-geschützt ist, muss auch der Zielcluster CMEK-geschützt sein.