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 zwei Arten von Sicherungen. Die Art der Sicherung, die Sie erstellen, hängt von Ihren Anforderungen an die Notfallwiederherstellung und der Art des Speichers (HDD oder SSD) ab, die in Ihrem Bigtable-Cluster verwendet wird.
- Standardsicherungen sind für die langfristige Aufbewahrung optimiert. Wenn Sie die Wiederherstellung aus einer Standardsicherung in einem SSD-Cluster ausführen, ist eine zusätzliche Optimierung durch Bigtable erforderlich, damit die Tabelle die Leistung auf Produktionsebene erreicht. Weitere Informationen finden Sie unter Leistung bei der Wiederherstellung.
- Hot-Sicherungen ermöglichen die effizienteste Wiederherstellung der Leistung auf Produktionsebene und die Bereitstellung mit geringer Latenz. Weitere Informationen finden Sie unter Hot-Sicherungen.
Sie haben folgende Möglichkeiten, Sicherungen zu erstellen:
- Automatische Sicherung aktivieren, damit Bigtable täglich Sicherungen für Sie erstellt
- Sicherungen auf Abruf mit der Google Cloud Console, der gcloud CLI oder einer Bigtable-Clientbibliothek erstellen
- Sicherungskopie 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 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 ein benutzerdefiniertes Ablaufdatum, das bis zu 90 Tage nach dem Erstellen der Sicherung reichen kann. Sie können eine Sicherungskopie 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äglich Sicherungen erstellt.
- Hot-Sicherungen: Planen Sie die Notfallwiederherstellung mit produktionsfertigen Hot-Sicherungen.
Anwendungsfälle
Sicherungen eignen sich für die folgenden Anwendungsfälle:
- 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 sollten immer eine aktuelle Sicherung Ihrer Daten haben, für den Fall, dass sie versehentlich gelöscht oder beschädigt werden. | Legen Sie den 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 in einem anderen Projekt oder einer anderen Region speichern, um für eine bessere Isolation und Sicherheit zu sorgen. Für einen noch besseren Schutz können Sie die Sicherungskopien in einem Projekt oder einer Instanz mit eingeschränkten Zugriffsberechtigungen speichern. | Stellen Sie die Daten aus der Sicherung oder Kopie in einer neuen Tabelle wieder her und leiten Sie die Anfragen dann an die neue Tabelle weiter. |
| Nicht verfügbare Zone: Sie müssen dafür sorgen, dass Ihre Daten auch dann verfügbar sind, wenn eine Google Cloud-Zone ausfällt. | 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 in regelmäßigen Abständen eine Kopie der neuesten Sicherung 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 Daten aus der Sicherungskopie auf einem Remote-Speicherort in einer neuen Tabelle wieder her und leiten Sie die Anfragen dann an die neue Tabelle weiter. |
| Datenbeschädigung: Mit einer Sicherung können Sie einen Teil der Daten einer Tabelle wiederherstellen, z. B. wenn ein Teil der Quelltabelle beschädigt wurde. | Aktivieren Sie die Replikation und die automatische Sicherung, um tägliche Sicherungen in mehreren Regionen zu erstellen. Wenn eine Tabelle in einem Cluster beschädigt wird, haben Sie dann ein oder mehrere Back-ups, die nicht auf dem beschädigten Cluster gespeichert sind. | Stellen Sie die Sicherung aus einer Sicherung in einer neuen Tabelle im neuen Cluster oder in der neuen Instanz wieder her. Schreiben Sie dann eine Anwendung mit einer Bigtable-Clientbibliothek oder einem Dataflow, die aus der neuen Tabelle liest und die Daten dann wieder in die Quelltabelle schreibt. Nachdem die Daten in die ursprüngliche Tabelle kopiert wurden, löschen Sie die neue Tabelle. |
| Schnelle Wiederherstellung: Die vollständige Produktionsleistung wird schnell wiederhergestellt, um Ausfallzeiten zu minimieren. | Behalten Sie immer eine aktuelle Hot-Dateisicherung Ihrer Tabelle. | Stellen Sie die Daten aus der Hot-Sicherung in einer neuen Tabelle wieder her und leiten Sie die Anfragen dann an die neue Tabelle weiter. |
Hot-Sicherungen
Ein Hot-Backup ist eine produktionsreife Sicherung, die für eine schnelle Wiederherstellung optimiert ist. Beim Lesen aus der neuen Tabelle kurz nach der Wiederherstellung ist die Latenz geringer. Die Wiederherstellung der Produktionsleistung aus einem Hot-Backup ist schneller als die Wiederherstellung aus einer Standardsicherung.
Sie können ein Hot-Backup in ein Standard-Backup konvertieren, aber kein Standard-Backup in ein Hot-Backup.
Sie können keine Hot-Sicherungen mithilfe einer automatischen Sicherung erstellen und auch keine Hot-Sicherung auf einem Festplattencluster.
Mit Bigtable-Sicherungen arbeiten
Für Bigtable-Sicherungen sind die folgenden Aktionen 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.
|
||
| Aktion | Zieloptionen | |
|---|---|---|
| Standardsicherung erstellen |
|
|
| Hot-Backup erstellen |
|
|
| Aus einer Standard- oder Hot-Sicherung in einer neuen Tabelle wiederherstellen |
|
|
| Sicherung kopieren1, 2 |
|
|
Unter Sicherungen verwalten finden Sie eine detaillierte Anleitung zu diesen Aktionen sowie zu Vorgängen wie dem Aktualisieren und Löschen von Sicherungen.
Sicherungsspeicher
Eine On-Demand-Tabellensicherung wird in einem von Ihnen angegebenen Cluster gespeichert. Wenn die automatische Sicherung aktiviert ist, wird eine Sicherung erstellt und 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.
Standardsicherungen sind inkrementell. Wie viel Speicherplatz eine Standardsicherung 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.
Ein Hot-Backup ist dagegen eine vollständige Kopie, die zum Zeitpunkt der Sicherung dieselbe Speichermenge belegt, unabhängig davon, wie stark sich die Quelltabelle ändert. Die Sicherung wird aufgrund des optimierten Speichers als Hot-Speicher eingestuft. So können Sie die Produktionsleistung effizient wiederherstellen.
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 ein Back-up eine Aufbewahrungsdauer von bis zu 90 Tagen festlegen. Wenn Sie eine Sicherungskopie erstellen, beträgt die maximale Aufbewahrungsdauer für die Kopie 30 Tage ab dem Zeitpunkt der Erstellung.
Bei Tabellen mit aktivierter automatischer Sicherung beträgt die Standardaufbewahrungsdauer drei Tage. Sie können die Aufbewahrungsdauer für ein Back-up ändern, sodass es bis zu 90 Tage nach der Erstellung aufbewahrt wird.
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 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 Garbage Collection der Quelltabelle. Konfigurieren Sie die Richtlinien für die automatische Speicherbereinigung in der neuen Tabelle, bevor Sie neue Daten in die Tabelle schreiben. Weitere Informationen finden Sie unter Garbage Collection konfigurieren.
Kosten
Bei der Arbeit mit Sicherungen fallen die standardmäßigen Netzwerkkosten an. Für Sicherungsvorgänge wie das Erstellen, Kopieren oder Wiederherstellen aus einer Sicherung werden Ihnen keine Kosten in Rechnung gestellt.
Speicherkosten
Die Speicherkosten für Standardsicherungen und Hot-Sicherungen unterscheiden sich.
Kosten für Standardspeicherplatz für Sicherungen
Für das Speichern einer Standardsicherung oder einer Sicherungskopie 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 standardmäßige Sicherungen. Diese Optimierung bedeutet, dass eine Standardsicherung inkrementell ist. Sie nutzt nach Möglichkeit den physischen Speicher mit der ursprünglichen Tabelle oder anderen Sicherungen der Tabelle gemeinsam. Aufgrund der integrierten Speicheroptimierungen von Bigtable sind die Kosten für die Speicherung einer Standardsicherung oder einer Sicherungskopie manchmal geringer als die Kosten für eine vollständige physische Kopie der Tabellensicherung.
Bei replizierten Instanzen, bei denen die automatische Sicherung aktiviert ist, sind die Speicherkosten möglicherweise höher, da täglich eine Sicherung für jeden Cluster erstellt wird.
Speicherkosten für Hot-Sicherungen
Für das Speichern einer Hot-Sicherung wird Ihnen der Speichertarif für Hot-Sicherungen für die Region berechnet, in der sich der Cluster mit der Hot-Sicherung befindet.
Da ein Hot-Backup in einem betriebsbereiten Zustand gespeichert wird, der für eine schnelle Wiederherstellung optimiert ist, werden Ihnen die Speicherkosten für die gesamte logische Kopie der Tabelle in Rechnung gestellt, nicht für inkrementelle Teile wie bei einer Standardsicherung.
Kosten beim Kopieren einer Sicherung
Wenn Sie eine Sicherungskopie in einer anderen Region als der Quellsicherung erstellen, werden Ihnen die Kosten für das Kopieren der Daten in den Zielcluster zu Standardnetzwerkpreisen in Rechnung gestellt. Wenn Sie eine Kopie in derselben Region wie die Quellsicherung erstellen, werden Ihnen keine Netzwerkgebühren berechnet.
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 Datenkopie in den Zielcluster zu den Standardnetzwerkpreisen 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 Sicherung einer Tabelle manuell in einer replizierten Instanz 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.
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 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 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 von replizierten 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, damit die Leistung optimal bleibt.
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 mehr als einmal alle fünf Minuten erstellen. 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 (die Quellinstanz).
Das Konto, mit dem Sie eine Sicherung kopieren, 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 | 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
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 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 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ö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.
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 Sicherungen für andere Google-Dienste eingebunden oder mit diesen verknüpft.
Wiederherstellen
- 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.
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.