Bigtable-Sicherungen – Übersicht
Auf dieser Seite erhalten Sie einen Überblick über Bigtable-Sicherungen. Inhalt ist für Bigtable-Administratoren gedacht zu entwickeln.
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 Back-ups
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.
- Automatisches Ablaufdatum: Jede Sicherung hat ein benutzerdefiniertes Ablaufdatum, kann bis zu 90 Tage nach dem Erstellen der Sicherung sein. 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: Wenn Sie die automatische Sicherung aktivieren, erstellt Bigtable täglich Sicherungen.
- Hot-Sicherungen: Planen Sie die Notfallwiederherstellung mit produktionsfertigen Hot-Sicherungen.
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 sollten immer eine aktuelle Sicherung Ihrer Daten haben, für den Fall, dass sie versehentlich gelöscht oder beschädigt werden. | Legen Sie einen geeigneten Zeitplan für die Erstellung von Sicherungen fest. Geschäftsanforderungen zu erfüllen, z. B. täglich. Optional können Sie regelmäßige Kopien von und in einem anderen Projekt oder einer anderen Region speichern, für mehr Isolation und Schutz. Für noch mehr Schutz solltest du die Kopien in einem Projekt oder einer Instanz mit eingeschränkten Zugriffsberechtigungen. | 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. |
| Nichtverfügbarkeit von Zonen : Sie müssen sicherstellen, dass den unwahrscheinlichen Fall, dass eine Google Cloud-Zone nicht mehr verfügbar ist, sind Ihre Daten weiterhin verfügbar. | Aktivieren Sie die automatische Sicherung, damit Bigtable jeden Tag eine Sicherung auf jedem 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 der Bereitstellungscluster nicht mehr verfügbar ist, wieder verfügbar ist, aus der Remote-Sicherungskopie in eine neue Tabelle an die neue Tabelle senden. |
| Datenbeschädigung: Verwenden Sie eine Sicherung zur Wiederherstellung. der Daten einer Tabelle, z. B. wenn ein Teil der Quelltabelle korrumpiert werden. | 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 eine oder mehrere Sicherungen, die nicht auf dem beschädigten Cluster gespeichert sind. | Stellen Sie die 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. Wenn der Parameter Daten in die ursprüngliche Tabelle kopiert, löschen Sie die neue . |
| Schnelle Wiederherstellung : Wiederherstellen in die Produktionsleistung schnell voll ausschöpfen und Ausfallzeiten minimieren. | Behalten Sie immer ein aktuelles Hot-Backup Ihrer Tabelle. | Stellen Sie aus dem Hot Backup eine neue Tabelle wieder her und leiten Sie dann die Daten um. an die neue Tabelle senden. |
Hot-Sicherungen
Eine Hot-Sicherung ist eine produktionsbereite 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 erfolgt schneller als aus einer Standardsicherung.
Sie können ein Hot Backup in eine Standardsicherung umwandeln, Standard-Back-up zu einem Hot Back-up.
Sie können keine Hot Backups mit der automatischen Sicherung erstellen und auch keinen Hot Backups auf einem HDD-Cluster.
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 Tabellensicherung, die Sie bei Bedarf erstellen, wird in einem einzelnen Cluster gespeichert, angeben. Wenn die automatische Sicherung aktiviert ist, wird eine Sicherung erstellt und gespeichert auf in der Instanz zu erstellen.
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 von der Größe der Datendivergenz ab. seit der vorherigen Sicherung.
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 Folgendes löschen: oder ablaufen zu lassen, wenn Sie sie nicht mehr benötigen. Der Sicherungsspeicher wird nicht berücksichtigt In Höhe des Knotenspeicherlimits für ein Projekt.
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 Kopie einer Sicherung erstellen, ist die maximale Aufbewahrungsdauer für Kopie 30 Tage nach ihrer Erstellung.
Für Tabellen mit aktivierter automatischer Sicherung beträgt die standardmäßige Aufbewahrungsdauer drei Tage. Sie können die Aufbewahrungsdauer für eine Sicherung ändern, um sie zu behalten für bis zu 90 Tage nach der Erstellung der Sicherung.
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 so viel Speicherplatz wie und die Größe der Tabelle kann sich nach der Wiederherstellung verringern. 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 bevor Sie neue Daten in die Tabelle schreiben. Weitere Informationen finden Sie unter Automatische Speicherbereinigung konfigurieren.
Kosten
Bei der Arbeit mit Sicherungen fallen die Standard-Netzwerkkosten an. Ihnen werden keine Kosten in Rechnung gestellt. für Sicherungsvorgänge wie das Erstellen, Kopieren oder Wiederherstellen aus einer Sicherung.
Speicherkosten
Die Speicherkosten für Standardsicherungen und Hot-Sicherungen unterscheiden sich.
Kosten für Standardsicherungsspeicher
Für das Speichern einer Standardsicherung oder einer Kopie einer Sicherung wird Ihnen der Standard-Back-up Sicherungsspeicherpreis für die Region, in der sich der in der sich die Sicherungskopie befindet.
Eine Standardsicherung ist eine vollständige logische Kopie einer Tabelle. Im Hintergrund optimiert Bigtable die Speicherauslastung für Standardsicherungen. 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. Dank des integrierten Speichers von Bigtable Optimierungen können die Kosten für das Speichern einer Standardsicherung oder einer Kopie einer Sicherung sind 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-Backups
Um ein Hot Backup zu speichern, wird der Speicherrate für Hot-Backups für die Region, in der sich der Cluster befindet in dem sich das Hot Backup 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 den Standardnetzwerkpreisen in Rechnung gestellt. Wenn Sie eine Kopie in derselben Region wie die Quellsicherung erstellen, werden Ihnen keine Netzwerkgebühren berechnet.
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 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 Tabelle manuell in einer replizierten Instanz sichern, wählen Sie den Cluster, in dem Sie die Sicherung erstellen und speichern möchten. Für Tabellen mit automatische Sicherung aktiviert ist, wird für jeden Cluster im Instanz.
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 Schreibvorgänge mit Zeitstempeln Zeitpunkt der Sicherung ist möglicherweise nicht in der Sicherung enthalten.
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 der automatischen Sicherung erstellt werden, keine exakten Kopien einander, da die Sicherungszeiten von Cluster zu Cluster variieren können Cluster.
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 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 Sicherung einer einzelnen Tabelle nicht öfter als einmal alle fünf Minuten. 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, das Sie zum Kopieren einer Sicherung verwenden, muss zum Lesen der und eine Sicherung in der Zielinstanz zu erstellen. Projekt arbeiten.
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, 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üssen, dass alle replizierten Schreibvorgänge in einer Sicherung enthalten sind, sichern Sie eine Tabelle in einer Instanz mit Replikation, verwenden Sie Konsistenztoken mit Ihren 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 nicht in andere Google-Dienste integriert oder damit in Verbindung stehen.
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 CMEK-geschützten Sicherung erstellen, muss der Zielcluster ebenfalls CMEK-geschützt sein.