Instanz wiederherstellen – Übersicht

MySQL   |  PostgreSQL   |  SQL Server

Mit Cloud SQL können Sie Ihre Instanzen aus einer Sicherung oder durch eine Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) wiederherstellen. So können Sie eine Instanz auf einen bestimmten Zeitraum oder Zeitpunkt wiederherstellen, indem Sie die Sicherung entweder in einer vorhandenen Instanz oder in einer neuen Instanz wiederherstellen. Für die Wiederherstellung können Sie die Sicherung einer aktiven oder gelöschten Instanz verwenden. Beim Wiederherstellungsvorgang werden die Einstellungen, Datenbanken und Nutzer der Quellinstanz übernommen und in der von Ihnen ausgewählten Zielinstanz festgelegt.

Wenn Sie eine neue Instanz wiederherstellen, kann sich die Zielinstanz in einer anderen Region oder einem anderen Projekt als die Quellinstanz befinden. Die Zielinstanz kann auch eine andere Anzahl von Kernen oder eine andere Menge an Arbeitsspeicher als die Quellinstanz verwenden.

Cloud SQL setzt die Speicherkapazität der Zielinstanz immer auf den Höchstwert der Größe des konfigurierten Laufwerks und des Sicherungslaufwerks. Das Sicherungslaufwerk ist die Größe des Laufwerks zum Zeitpunkt der Sicherung.

Beachten Sie beim Wiederherstellen einer Instanz Folgendes:

• Mit der Wiederherstellung werden alle Daten in der Zielinstanz überschrieben.
• Die Flags der Quellinstanz werden nicht wiederhergestellt. Alle Flags, die zuvor für die Zielinstanz festgelegt wurden, bleiben nach der Wiederherstellung erhalten.
• Während der Wiederherstellung ist die Zielinstanz nicht für Verbindungen verfügbar. Bestehende Verbindungen werden getrennt.
• Wenn Sie eine Wiederherstellung in einer Instanz mit Lesereplikaten durchführen, müssen Sie alle Replikate löschen und nach Abschluss des Wiederherstellungsvorgangs neu erstellen.
• Durch den Wiederherstellungsvorgang wird die Instanz neu gestartet.
• Nachdem Sie eine Sicherung wiederhergestellt haben, werden die Sicherungskonfigurationen der Zielinstanz auf die Standardwerte zurückgesetzt. Wenn Ihre Quellinstanz benutzerdefinierte Sicherungskonfigurationen hatte oder erweiterte Sicherungen verwendet hat, müssen Sie die Sicherungskonfigurationen nach Abschluss der Wiederherstellung aktualisieren.

Wichtig: Wenn Sie eine Sicherung auf einer vorhandenen Instanz wiederherstellen, muss die Zielinstanz mindestens so viele Rechen- und Arbeitsspeicherressourcen (vCPU und RAM) haben wie die Quellinstanz, aus der die Sicherung erstellt wurde. Wenn Sie eine Sicherung auf einer Instanz mit deutlich weniger Ressourcen wiederherstellen, kann der Wiederherstellungsvorgang aufgrund von Ressourcenbeschränkungen beim Starten und Wiederherstellen der Datenbank fehlschlagen. Möglicherweise werden Fehler wie database failed to start after multiple retries angezeigt.

Aus einer Sicherung wiederherstellen

Mit Cloud SQL können Sie eine Instanz aus einer Sicherung wiederherstellen. Sie können eine Sicherung einer aktiven oder gelöschten Instanz verwenden und sie in einer neuen oder vorhandenen Instanz wiederherstellen. Sie können jede verfügbare Sicherung verwenden, um die Instanz wiederherzustellen. Weitere Informationen zur Funktionsweise von Sicherungen in Cloud SQL finden Sie unter Sicherungen – Übersicht.

Wenn Sie eine Instanz mithilfe einer Sicherung wiederherstellen, können Sie Folgendes tun:

• In einer neuen Instanz wiederherstellen
• In einer vorhandenen Instanz wiederherstellen
• Instanz in einem anderen Projekt oder einer anderen Region wiederherstellen

Im Falle eines Ausfalls können Sie weiterhin eine Liste der Sicherungen in einem bestimmten Projekt abrufen, um sie wiederherzustellen.

Informationen zum Wiederherstellen einer Instanz mithilfe einer Sicherung finden Sie unter Instanz mithilfe einer Sicherung wiederherstellen.

CMEK-fähige Instanz mit erweiterten Sicherungen wiederherstellen

Wenn Sie CMEK-fähige Instanzen mit erweiterten Sicherungen verwenden, werden Ihre Sicherungen durch denselben CMEK wie die Instanz geschützt. Dies kann ein wichtiger Teil Ihres Sicherungsplans für Instanzen sein, die eine CMEK-Verschlüsselung erfordern, da Ihre CMEK-verschlüsselten Sicherungen in einem separaten Projekt aufbewahrt werden, in dem sie erfolgreich wiederhergestellt werden können, selbst wenn Ihr ursprüngliches Arbeitslastprojekt manipuliert oder gelöscht wird.

Wenn Sie eine erweiterte Sicherung einer CMEK-fähigen Instanz in einer neuen Instanz wiederherstellen, können Sie eine der folgenden Verschlüsselungsoptionen für die neue Instanz auswählen:

• Verwenden Sie denselben Cloud KMS-Schlüssel wie die ursprüngliche Instanz. Dies ist das Standardverhalten.
• Wählen Sie einen anderen Cloud KMS-Schlüssel für die Zielinstanz aus. Wenn Sie einen anderen Schlüssel auswählen möchten, legen Sie das Flag --disk-encryption-key im Wiederherstellungsbefehl fest.
• Setzen Sie die Zielinstanz auf Google-owned and Google-managed encryption keys zurück. Wenn Sie GMEK verwenden möchten, legen Sie im Wiederherstellungsbefehl das Flag --clear-disk-encryption fest.

Wiederherstellung zu einem bestimmten Zeitpunkt

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie Ihre Instanz auf einen bestimmten Stand der Datenbank zurücksetzen. Wenn beispielsweise ein Fehler zu einem Datenverlust führt, haben Sie die Möglichkeit, genau den Zustand der Datenbank wiederherzustellen, den sie zum Zeitpunkt vor Auftreten des Fehlers hatte. Im Gegensatz zur Wiederherstellung mithilfe einer Sicherung wird bei der PITR immer eine neue Instanz erstellt. Diese Art der Wiederherstellung kann nicht für eine vorhandene Instanz durchgeführt werden. Die neue Instanz übernimmt die Einstellungen der Quellinstanz, ähnlich wie beim Klonen von Instanzen.

Wenn Sie eine Cloud SQL Enterprise Plus-Instanz erstellen, ist die Wiederherstellung zu einem bestimmten Zeitpunkt standardmäßig aktiviert. Sie müssen die Funktion manuell deaktivieren, wenn Sie sie nicht aktivieren möchten.

Wenn Sie eine Cloud SQL Enterprise-Version-Instanz in der Google Cloud Console erstellen, ist PITR standardmäßig aktiviert. Wenn Sie die Instanz mit der gcloud CLI, Terraform oder der Cloud SQL Admin API erstellen, ist PITR standardmäßig deaktiviert. Wenn Sie die PITR für diese Instanzen aktivieren möchten, müssen Sie sie manuell aktivieren.

Eine detaillierte Anleitung zur Durchführung einer PITR finden Sie unter Wiederherstellung zu einem bestimmten Zeitpunkt verwenden.

Logspeicher für PITR

Bei der PITR werden Logs archiviert. Wenn Sie eine vorhandene Instanz mithilfe einer Sicherung wiederherstellen, werden diese Archivlogs gelöscht und sind für eine Wiederherstellung zu einem bestimmten Zeitpunkt nicht mehr verfügbar. Nur neue Logs, die nach Abschluss der Wiederherstellung generiert werden, können für die PITR verwendet werden.

Am 31. Mai 2024 wurde die Speicherung von Transaktionslogs für PITR in Cloud Storage eingeführt. Seit dieser Einführung gelten die folgenden Bedingungen:

• Alle Cloud SQL Enterprise Plus-Instanzen speichern ihre Transaktionslogs, die für PITR verwendet werden, in Cloud Storage. Nur Instanzen der Cloud SQL Enterprise Plus-Version, die Sie vor dem 1. April 2024 von der Cloud SQL Enterprise-Version aktualisiert und PITR vor dem 31. Mai 2024 aktiviert hatten, speichern ihre Logs weiterhin auf dem Laufwerk für PITR.

• Cloud SQL Enterprise-Version-Instanzen, die vor dem 31. Mai 2024 mit aktivierter Wiederherstellung zu einem bestimmten Zeitpunkt erstellt wurden, speichern ihre Protokolle für Wiederherstellung zu einem bestimmten Zeitpunkt weiterhin auf dem Laufwerk.

  Hinweis: Bei Instanzen, die vor dem 31. Mai 2024 erstellt wurden, wechselt Cloud SQL den Speicherort der für PITR verwendeten Transaktionslogs automatisch. Sie können die gcloud CLI oder die Cloud SQL Admin API verwenden, um zu prüfen, wo Transaktionslogs für Ihre Instanz gespeichert werden.

• Wenn Sie nach dem 31. Mai 2024 eine Cloud SQL Enterprise-Instanz aktualisieren, in der Transaktionslogs für PITR auf dem Laufwerk auf Cloud SQL Enterprise Plus gespeichert werden, wechselt der Upgradeprozess den Speicherort der für PITR verwendeten Transaktionslogs auf Cloud Storage. Weitere Informationen finden Sie unter Instanz mithilfe eines direkten Upgrades auf Cloud SQL Enterprise Plus-Version aktualisieren.

• Alle Cloud SQL Enterprise-Instanzen, die Sie nach dem 31. Mai 2024 mit aktivierter PITR erstellen, speichern Logs, die für PITR in Cloud Storage verwendet werden.

Wenn Ihre Instanz Cloud Storage zum Speichern von Transaktionslogs verwendet, werden die Logs in derselben Region wie die primäre Instanz gespeichert. Diese Logs werden für die Cloud SQL Enterprise Plus-Version bis zu 35 Tage und für die Cloud SQL Enterprise-Version bis zu 7 Tage gespeichert. Pro Instanz fallen keine zusätzlichen Kosten an.

Weitere Informationen zum Prüfen des Speicherorts der für PITR verwendeten Transaktionslogs finden Sie unter Speicherort von Transaktionslogs für Ihre Instanz prüfen.

Bei Instanzen, die Transaktionslogs nur auf dem Laufwerk speichern, können Sie den Speicherort der für PITR verwendeten Transaktionslogs mit der gcloud CLI oder der Cloud SQL Admin API vom Laufwerk auf Cloud Storage umstellen. Weitere Informationen finden Sie unter Transaktionslogspeicher auf Cloud Storage umstellen.

Achtung: Das Verschieben von Transaktionslogs von einem Laufwerk zu Cloud Storage führt zu einer Ausfallzeit von mehreren Minuten und zum Verlust der vorherigen Logs für PITR. Die Ausfallzeit geschieht, weil die Instanzen neu gestartet werden müssen und die Logs gelöscht werden, wenn Sie PITR deaktivieren.

Führen Sie die folgenden Aktionen aus, damit Logs für Ihre Instanz in Cloud Storage statt auf dem Laufwerk gespeichert werden:

• Prüfen Sie die Netzwerkarchitektur der Instanz. Wenn die Instanz die alte Netzwerkarchitektur verwendet, führen Sie ein Upgrade auf die neue Netzwerkarchitektur durch.

• Wenn die Größe Ihrer Logs auf dem Laufwerk Leistungsprobleme für Ihre Instanz verursacht, deaktivieren Sie die Wiederherstellung zu einem bestimmten Zeitpunkt und aktivieren Sie sie noch einmal. Dadurch wird sichergestellt, dass neue Logs in Cloud Storage statt auf dem Laufwerk gespeichert werden.

  Achtung: Wenn Sie PITR deaktivieren und wieder aktivieren, werden alle vorhandenen Logs gelöscht und Sie können PITR vor der erneuten Aktivierung nicht ausführen. Wenn Sie die Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren oder deaktivieren möchten, müssen Sie die Datenbank neu starten.

Aufbewahrungsdauer für Logs

Cloud SQL bewahrt Transaktionslogs in Cloud Storage bis zu dem Wert auf, der in der PITR-Konfigurationseinstellung transactionLogRetentionDays festgelegt ist. Dieser kann zwischen 1 und 35 Tagen für Cloud SQL Enterprise Plus-Version und 1 bis 7 Tage für Cloud SQL Enterprise-Version liegen. Wenn für diesen Parameter kein Wert festgelegt ist, beträgt die Standardaufbewahrungsdauer für Transaktionslogs 14 Tage für Cloud SQL Enterprise Plus-Instanzen und 7 Tage für Cloud SQL Enterprise-Instanzen. Weitere Informationen zum Festlegen der Aufbewahrungsdauer für Transaktionslogs finden Sie unter Aufbewahrung von Transaktionslogs festlegen.

Obwohl eine Instanz die für PITR verwendeten Transaktionslogs in Cloud Storage speichert, behält die Instanz auch eine kleinere Anzahl von doppelten Transaktionslogs auf dem Laufwerk, um die Replikation der Logs in Cloud Storage zu ermöglichen. Wenn Sie eine Instanz mit aktivierter PITR erstellen, speichert die Instanz ihre Transaktionslogs für PITR standardmäßig in Cloud Storage. Cloud SQL setzt den Wert der Flags expire_logs_days und binlog_expire_logs_seconds automatisch auf den Wert, der einem Tag entspricht. Das entspricht einem Tag an Logs auf dem Laufwerk.

Für PITR-Transaktionslogs, die auf dem Laufwerk gespeichert sind, die zu Cloud Storage gewechselt werden oder die bereits zu Cloud Storage gewechselt wurden, speichert Cloud SQL die Logs für den Mindestwert, der für eine der folgenden Konfigurationen festgelegt ist:

• Die Sicherungskonfigurationseinstellung transactionLogRetentionDays
• Das Flag expire_logs_days oder das Flag binlog_expire_logs_seconds

Cloud SQL legt keine Werte für diese Flags fest, wenn die Transaktionslogs auf dem Laufwerk gespeichert sind, zu Cloud Storage gewechselt werden oder bereits zu Cloud Storage gewechselt wurden. Wenn Logs auf dem Laufwerk gespeichert werden, kann sich das Ändern der Werte dieser Flags auf das Verhalten der Wiederherstellung zu einem bestimmten Zeitpunkt und auf die Anzahl der Tage auswirken, für die Logs auf dem Laufwerk gespeichert werden. Während der Speicherort des Logs auf Cloud Storage umgestellt wird, können Sie die Flag-Werte nicht ändern. Wir empfehlen außerdem, keinen der Flag-Werte auf 0 zu konfigurieren. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Hinweis: Wenn Ihre Instanz eine große Anzahl von Transaktionslogs auf dem Laufwerk enthält und Sie Speicherplatz sparen möchten, sollten Sie den Wert der folgenden Flags langsam senken:

• transactionLogRetentionDays-Konfigurationseinstellung
• Datenbank-Flag expire_logs_days
• Datenbank-Flag binlog_expire_logs_seconds

Um Leistungsprobleme zu vermeiden, können Sie beispielsweise den Wert der Flags über mehrere Tage hinweg jeden Tag um einen Tag reduzieren. Daher werden in Cloud SQL nicht alle Transaktionslogs gleichzeitig gelöscht.

Bei Instanzen mit kundenverwaltetem Verschlüsselungsschlüssel (CMEK) werden Transaktionslogs mit der aktuellen Version des CMEK verschlüsselt. Für eine Wiederherstellung ist die neueste Schlüsselversion für alle Tage erforderlich, die im Rahmen des Parameters retained-transaction-log-days aufbewahrt werden.

Einschränkungen der Wiederherstellung zu einem bestimmten Zeitpunkt

Die folgenden Einschränkungen gelten, wenn für Ihre Instanz die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert ist und die Größe Ihrer Transaktionslogs auf dem Laufwerk ein Problem für die Instanz verursacht:

• Sie können die Wiederherstellung zu einem bestimmten Zeitpunkt deaktivieren und wieder aktivieren, damit Cloud SQL Logs in Cloud Storage in derselben Region wie die Instanz speichert. Cloud SQL löscht jedoch alle vorhandenen Logs, sodass Sie einen PITR-Vorgang erst ab dem Zeitpunkt ausführen können, zu dem Sie PITR wieder aktiviert haben.
• Sie können die Speichergröße der Instanz erhöhen, die erhöhte Speichernutzung der Größe des Transaktionslogs könnte jedoch nur temporär sein.
• Damit unerwartete Speicherprobleme vermieden werden, empfehlen wir die Aktivierung von automatischen Speichererweiterungen. Diese Empfehlung gilt nur, wenn für Ihre Instanz PITR aktiviert ist und Ihre Logs auf dem Laufwerk gespeichert sind.

• Die Wiederherstellung zu einem bestimmten Zeitpunkt kann für Ihre Cloud SQL-Zielinstanz nicht aktiviert werden, wenn sie mehrere Datenbanken mit demselben physischen Namen hat.

Datenbank-Snapshots

Sie können SQL Server-Datenbank-Snapshots nicht für Datenbanken in einer Instanz verwenden, für die die Wiederherstellung zu einem bestimmten Zeitpunkt aktiviert ist.

Datenbank-Snapshots können die vollständige Datenbanksicherung und die Transaktionslog-Sicherung beeinträchtigen, auf die PITR angewiesen ist. Diese Störung kann erfolgreiche PITR-Vorgänge für alle Datenbanken auf der Instanz verhindern.

Datenbankwiederherstellungsmodell für die Wiederherstellung zu einem bestimmten Zeitpunkt

Wenn Sie die Wiederherstellung zu einem bestimmten Zeitpunkt für eine Instanz aktivieren, legt Cloud SQL das Wiederherstellungsmodell der vorhandenen und nachfolgenden Datenbanken automatisch auf das vollständige Wiederherstellungsmodell fest.

Achtung: Nachdem Sie die Wiederherstellung zu einem bestimmten Zeitpunkt für Ihre Instanz aktiviert haben, ändern Sie das Datenbankwiederherstellungsmodell nicht in das einfache Wiederherstellungsmodell. Dies könnte die Sicherungskette des Transaktionslogs beeinträchtigen und Sie können die Instanzdaten möglicherweise nicht bis zu dem Zeitpunkt wiederherstellen, an dem das Wiederherstellungsmodell auf „Einfach“ gesetzt wurde.

Weitere Informationen zu SQL Server-Wiederherstellungsmodellen finden Sie in der Microsoft-Dokumentation.

Eine detaillierte Anleitung zur Durchführung einer PITR finden Sie unter [Wiederherstellung zu einem bestimmten Zeitpunkt verwenden][perform-pitr].

Gelöschte Instanz mit PITR wiederherstellen

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt können Sie eine Cloud SQL-Instanz nach dem Löschen wiederherstellen. Wenn Sie diese Funktion verwenden möchten, müssen für Ihre Instanz PITR und aufbewahrte Sicherungen aktiviert sein, bevor die Instanz gelöscht wird. Wenn diese Option aktiviert ist, werden PITR-Logs nach dem Löschen der Instanz beibehalten.

Nachdem eine Instanz gelöscht wurde, folgen die PITR-Logs weiterhin den Aufbewahrungseinstellungen, die von der Instanz definiert wurden, als sie aktiv war. Die PITR-Logs laufen nach dem Löschen der Instanz gemäß den Aufbewahrungseinstellungen rollierend ab. Der rollierende Zeitraum wird basierend auf der PITR-Aufbewahrungsdauer definiert, die vor dem Löschen für die Instanz festgelegt wurde. Wenn für Ihre Cloud SQL Enterprise Plus-Instanz beispielsweise die PITR-Aufbewahrung auf 14 Tage festgelegt ist, wird das neueste PITR-Log 14 Tage nach dem Löschen der Instanz gelöscht. Wenn ein PITR-Log abläuft, kann es nicht wiederhergestellt werden.

Da Instanznamen nach dem Löschen einer Instanz in Cloud SQL wiederverwendet werden können, können beibehaltene PITR-Logs in Google Cloud mit den folgenden Feldern identifiziert werden:

• instance_deletion_time
• log_retention_days

Anhand dieser Felder können Sie feststellen, ob ein PITR-Log zu einer gelöschten Instanz gehört.

Das PITR-Wiederherstellungsfenster ist definiert als die frühesten und spätesten Wiederherstellungszeiten, die für die Wiederherstellung Ihrer Instanz mit PITR verfügbar sind. Informationen zum Ermitteln des frühesten und spätesten Wiederherstellungszeitpunkts Ihrer gelöschten Instanz finden Sie unter Frühesten und spätesten Wiederherstellungszeitpunkt abrufen.

Informationen zum Wiederherstellen einer Instanz mithilfe von PITR nach dem Löschen der Instanz finden Sie unter PITR für eine gelöschte Instanz ausführen.

Anforderungen für die Wiederherstellung in einer neuen Instanz

Wenn Sie Ihre Instanz in einer neuen Instanz wiederherstellen, beachten Sie die folgenden Anforderungen:

• Die Zielinstanz muss eine Datenbank der gleichen Version haben wie die Instanz, von der die Sicherung erstellt wurde.

• Beim Erstellen einer neuen Instanz ist das Feature storageAutoResize standardmäßig aktiviert. Alle nachfolgend erstellten Sicherungen übernehmen dieselbe storageAutoResize-Einstellung. Das bedeutet, dass die Speicherkapazität der Instanz bei Bedarf automatisch angepasst wird, unabhängig davon, ob eine Sicherung in einer neuen oder vorhandenen Instanz wiederhergestellt wird. Bei Legacy-Instanzen ist diese Funktion nicht aktiviert. Informationen zum Prüfen Ihrer Instanzeinstellungen finden Sie unter Instanzeinstellungen aufrufen. Diese Anforderung gilt unabhängig davon, ob Sie die PITR einer einzelnen Datenbank machen.

• Die Zielinstanz muss den Status RUNNABLE aufweisen.

Einschränkungen der Wiederherstellungsrate

Es sind maximal drei Wiederherstellungsvorgänge alle 30 Minuten pro Instanz, Region und Projekt möglich. Wenn ein Wiederherstellungsvorgang fehlschlägt, wird er nicht auf dieses Kontingent angerechnet. Wenn Sie das Limit erreichen, schlägt der Vorgang mit einer Fehlermeldung fehl, die angibt, wann Sie den Vorgang wieder ausführen können.

Cloud SQL verwendet Tokens aus einem Bucket, um zu ermitteln, wie viele Wiederherstellungsvorgänge gleichzeitig verfügbar sind. Für jede Sicherung gibt es für jedes Zielprojekt und jede Zielregion eine Bucket. Die Zielinstanzen aus demselben Projekt nutzen einen Bucket gemeinsam, wenn sie sich in derselben Region befinden. In jedem Bucket können maximal drei Tokens für Wiederherstellungsvorgänge verwendet werden. Alle 10 Minuten wird dem Bucket ein neues Token hinzugefügt. Wenn der Bucket voll ist, läuft das Token über.

Jedes Mal, wenn Sie einen Wiederherstellungsvorgang ausführen, wird ein Token aus dem Bucket gewährt. Wenn der Vorgang erfolgreich ist, wird das Token aus dem Bucket entfernt. Wenn der Vorgang fehlschlägt, wird das Token an den Bucket zurückgegeben. Dies wird im folgenden Diagramm veranschaulicht:

In der folgenden Abbildung sind beispielsweise Backup1, Backup2 und Backup3 die Sicherungen derselben Quellinstanz.

• Jede Sicherung (Backup1, Backup2 und Backup3) hat einen eigenen Bucket mit Tokens für Wiederherstellungsvorgänge, die auf verschiedene Instanzen in Projekt 1 in Region A (Bucket11A, Bucket21A und Bucket31A) ausgerichtet sind. Da jede Sicherung einen eigenen Bucket hat, können Sie jede Sicherung dreimal alle 30 Minuten wiederherstellen.
• Jede Sicherung hat einen Bucket für ein separates Projekt und für eine separate Region. Wenn es beispielsweise fünf Projekte in einer Region gibt, gibt es fünf Buckets für diese Sicherung in dieser Region, einer in jedem Projekt. In der vorherigen Abbildung haben wir zwei Projekte in Region A: Projekt 1 und Projekt n.
  • Backup1 hat zwei Buckets mit Tokens für Wiederherstellungsvorgänge in Region A. Einen Bucket für Projekt 1 (Bucket11A) und einen Bucket für Projekt n (Bucket1nA).
  • In ähnlicher Weise hat Backup3 zwei Buckets für Wiederherstellungsvorgänge in Region A. Eine für Projekt 1 (Bucket31A) und eine für Projekt n (Bucket3nA).
• Backup3 hat einen Bucket in Region B für Projekt1, da alle Instanzen im selben Zielprojekt und in derselben Zielregion einen Bucket gemeinsam nutzen.

Nächste Schritte

• Daten aus einer Sicherung wiederherstellen
• Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) verwenden