Szenarien der Notfallwiederherstellung für Daten

Last reviewed 2022-06-10 UTC

Dieser Artikel ist der dritte Teil einer Reihe, in der die Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloud behandelt wird. In diesem Teil werden Szenarien für die Sicherung und Wiederherstellung von Daten beschrieben.

Die Reihe besteht aus folgenden Teilen:

Einführung

In Plänen zur Notfallwiederherstellung legen Sie fest, wie Sie bei einem Notfall den Verlust von Daten vermeiden. Der Begriff Daten bezieht sich hier auf zwei Szenarien. Es geht um die Sicherung und Wiederherstellung von Datenbanken, Logdaten und anderen Datentypen in einem der folgenden Szenarien:

  • Datensicherungen: Bei der Sicherung von Daten wird eine bestimmte Menge an Daten von einem Ort an einen anderen kopiert. Sicherungen sind Bestandteil eines Wiederherstellungsplans. Damit können einerseits Daten in der Produktionsumgebung nach einer Beschädigung in einwandfreiem Zustand wiederhergestellt werden. Andererseits lassen sich mit einem solchen Plan Daten in der DR-Umgebung wiederherstellen, sollte die Produktionsumgebung ausfallen. In der Regel gelten für Datensicherungen niedrige bis mittlere RTO-Werte (Recovery Time Objective, Wiederherstellungsdauer) und niedrige RPO-Werte (Recovery Point Objective, Wiederherstellungszeitpunkt).
  • Datenbanksicherungen: Datenbanksicherungen sind etwas komplexer, da sie in der Regel bis zu einem bestimmten Zeitpunkt wiederhergestellt werden müssen. Neben der Sicherung und Wiederherstellung der Datenbanken sowie der exakten Spiegelung der Produktionskonfiguration durch das Wiederherstellungsdatenbanksystem (gleiche Version, gespiegelte Laufwerkskonfiguration) muss deshalb auch die Sicherung der Transaktionslogs berücksichtigt werden. Bei der Notfallwiederherstellung müssen Sie nach der Wiederherstellung der Datenbankfunktionalität die letzte Datenbanksicherung und dann die wiederhergestellten Transaktionslogs übernehmen, die nach der letzten Sicherung gesichert wurden. Aufgrund der komplexen Rahmenbedingungen von Datenbanksystemen, wie z. B. der notwendigen Abstimmung der Versionen zwischen Produktions- und Wiederherstellungssystemen, muss vorrangig eine hohe Verfügbarkeit gewährleistet werden. Damit lassen sich die Wiederherstellungsdauer in einer Situation, in der der Ausfall des Datenbankservers droht, minimieren und so niedrigere RTO- bzw. RPO-Werte realisieren.

Im weiteren Verlauf dieses Artikels werden Beispiele für das Entwerfen von Szenarien für Daten und Datenbanken beschrieben, mit denen Sie Ihre RTO- und RPO-Ziele erreichen können.

Lokale Produktionsumgebung

In diesem Szenario ist die Produktionsumgebung lokal angesiedelt. Der Plan zur Notfallwiederherstellung sieht Google Cloud als Medium zur Wiederherstellung vor.

Datensicherung und -wiederherstellung

Es gibt eine Reihe von Strategien, um einen Prozess für die regelmäßige Sicherung lokaler Daten in Google Cloud zu implementieren. In diesem Abschnitt werden zwei der am häufigsten verwendeten Lösungen behandelt.

Lösung 1: Sicherung auf Cloud Storage mithilfe einer geplanten Aufgabe

DR-Bausteine:

  • Cloud Storage

Eine Möglichkeit der Datensicherung ist das Erstellen einer geplanten Aufgabe, die ein Skript oder eine Anwendung zur Übertragung der Daten nach Cloud Storage ausführt. Sie können diesen Vorgang zur Sicherung der Daten in Cloud Storage mithilfe des gsutil-Befehlszeilentools oder mit einer der Clientbibliotheken von Cloud Storage automatisieren. Mit dem folgenden gsutil-Befehl werden beispielsweise alle Dateien aus einem Quellverzeichnis in einen bestimmten Bucket kopiert.

gsutil -m cp -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

Mit den folgenden Schritten können Sie einen Sicherungs- und Wiederherstellungsvorgang mithilfe des gsutil-Tools implementieren.

  1. Installieren Sie gsutil auf dem lokalen Computer, von dem Sie die Datendateien hochladen.
  2. Erstellen Sie einen Bucket als Ziel für die Datensicherung.
  3. Generieren Sie einen Dienstkontoschlüssel für ein dediziertes Dienstkonto im JSON-Format. Mit dieser Datei werden im Rahmen eines automatisierten Skripts die Anmeldedaten an gsutil übergeben.

  4. Kopieren Sie den Dienstkontoschlüssel auf den lokalen Computer, auf dem Sie das Skript zum Hochladen der Sicherungen ausführen.

  5. Erstellen Sie eine IAM-Richtlinie zur Einschränkung des Zugriffs auf den Bucket und seine Objekte. Erteilen Sie dabei dem speziell für diesen Zweck erstellten Dienstkonto und einem lokalen Operatorkonto den Zugriff. Ausführliche Informationen zu Berechtigungen für den Zugriff auf Cloud Storage finden Sie unter IAM-Berechtigungen für gsutil-Befehle.

  6. Testen Sie, ob Sie Dateien in den Ziel-Bucket hochladen und von dort herunterladen können.

  7. Folgen Sie den Anleitungen unter Skript für Aufgaben zur Datenübertragung erstellen, um ein geplantes Skript einzurichten.

  8. Konfigurieren Sie einen Wiederherstellungsprozess, der gsutil verwendet, um Ihre Daten in Ihrer Wiederherstellungs-DR-Umgebung in Google Cloud wiederherzustellen.

Sie können auch den Befehl gsutil rsync verwenden, um inkrementelle Echtzeitsynchronisierungen zwischen Ihren Daten und einem Cloud Storage-Bucket durchzuführen.

Mit dem folgenden gsutil rsync-Befehl werden z. B. die Inhalte in einem Cloud Storage-Bucket mit dem Inhalt des Quellverzeichnisses identisch gemacht. Kopieren Sie dazu alle fehlenden Dateien oder Objekte oder diejenigen, deren Daten sich geändert haben. Wenn sich die Datenmenge, die zwischen den aufeinanderfolgenden Sicherungssitzungen geändert wurde, relativ klein im Verhältnis zum gesamten Umfang der Quelldaten ist, kann gsutil rsync effizienter sein als gsutil cp. Dies wiederum ermöglicht einen häufigeren Sicherungsplan und Sie können einen niedrigeren RPO-Wert erzielen.

gsutil -m rsync -r [SOURCE_DIRECTORY] gs://[BUCKET_NAME]

Weitere Informationen finden Sie unter Von einem Colocation- oder lokalen Speicher übertragen. Hier werden auch Möglichkeiten zur Optimierung des Übertragungsvorgangs erläutert.

Lösung 2: Sicherung auf Cloud Storage mit dem Transfer Service für lokale Daten

DR-Bausteine:

  • Cloud Storage
  • Transfer Service für lokale Daten

Die Übertragung großer Datenmengen über ein Netzwerk erfordert häufig eine sorgfältige Planung und robuste Ausführungsstrategien. Es ist keine triviale Aufgabe, benutzerdefinierte Skripts zu erstellen, die skalierbar, zuverlässig und verwaltbar sind. Benutzerdefinierte Skripts können häufig zu niedrigeren RPO-Werten und sogar zu erhöhten Risiken bei Datenverlust führen.

Eine Möglichkeit zur Implementierung einer umfangreichen Datenübertragung ist die Verwendung des Transfer Service für lokale Daten. Dieser Dienst ist ein skalierbarer, zuverlässiger und verwalteter Dienst, mit dem Sie große Datenmengen von Ihrem Rechenzentrum in einen Cloud Storage-Bucket übertragen können, ohne in Entwicklungsteams zu investieren oder Übertragungslösungen zu kaufen.

Lösung 3: Sicherung auf Cloud Storage mithilfe einer Partner-Gateway-Lösung

DR-Bausteine:

  • Cloud Interconnect
  • Mehrstufige Speicherung in Cloud Storage

Lokale Anwendungen sind häufig in Lösungen von Drittanbietern eingebunden, die im Rahmen der Datensicherungs- und Wiederherstellungsstrategie verwendet werden. Diese Lösungen nutzen häufig ein Muster für eine mehrstufige Speicherung, bei der die letzten Sicherungen auf einem schnelleren Speicher abgelegt werden und ältere Sicherungen zu einem kostengünstigeren, langsameren Speicher migriert werden. Wenn Sie Google Cloud als Ziel verwenden, stehen Ihnen mehrere Speicherklassenoptionen zur Verfügung, die Sie analog zur langsameren Stufe verwenden können.

Eine Möglichkeit, dieses Muster zu implementieren, ist die Verwendung eines Partner-Gateways zwischen dem lokalen Speicher und Google Cloud, um die Datenübertragung an Cloud Storage zu erleichtern. Im folgenden Diagramm ist diese Konstellation veranschaulicht, in der die Übertragung von der lokalen NAS-Appliance oder vom SAN über eine Partnerlösung ausgeführt wird.

Architekturdiagramm mit einem lokalen Rechenzentrum, das über eine dedizierte Verbindung mit Google Cloud verbunden ist

Bei Auftreten eines Fehlers müssen die gesicherten Daten in der DR-Umgebung wiederhergestellt werden. Der Produktionstraffic wird dann über diese DR-Umgebung geleitet, bis die Produktionsumgebung wiederhergestellt ist. Die jeweils erforderliche Vorgehensweise hängt von Ihrer Anwendung, der Partnerlösung und deren Architektur ab. Im DR-Anwendungsdokument werden verschiedene End-to-End-Szenarien erläutert.

Weitere Informationen dazu, wie Sie lokale Daten an Google Cloud übertragen können, finden Sie unter Große Datasets in Google Cloud übertragen.

Weitere Informationen zu Partnerlösungen finden Sie unter Partner auf der Google Cloud-Website.

Datenbanksicherung und -wiederherstellung

Es gibt eine Reihe von Strategien, um einen Prozess zur Wiederherstellung eines lokalen Datenbanksystems in Google Cloud zu implementieren. In diesem Abschnitt werden zwei der am häufigsten verwendeten Lösungen behandelt.

Die verschiedenen integrierten Sicherungs- und Wiederherstellungsverfahren der Datenbanken von Drittanbietern werden in diesem Artikel nicht erläutert. Dieser Abschnitt bietet nur eine allgemeine Anleitung im Rahmen der vorgestellten Lösungen.

Lösung 1: Sicherung und Wiederherstellung mit einem Wiederherstellungsserver in Google Cloud

  1. Erstellen Sie mit den integrierten Sicherungsverfahren Ihres Datenbankverwaltungssystems eine Datenbanksicherung.
  2. Verbinden Sie dafür Ihr lokales Netzwerk mit Ihrem Netzwerk in Google Cloud.
  3. Erstellen Sie einen Cloud Storage-Bucket als Ziel für die Datensicherung.
  4. Kopieren Sie die Sicherungsdateien mithilfe von gsutil oder einer Partner-Gateway-Lösung nach Cloud Storage. Verwenden Sie dafür die oben im Abschnitt "Datensicherung und -wiederherstellung" beschriebenen Schritte. Weitere Informationen finden Sie unter Große Datensätze in Google Cloud übertragen.
  5. Kopieren Sie die Transaktionslogs an den Wiederherstellungsort in Google Cloud. Mit einer Sicherungskopie der Transaktionslogs erreichen Sie niedrige RPO-Werte.

Nach der Konfiguration dieser Sicherungstopologie prüfen Sie, ob eine Wiederherstellung in Google Cloud möglich ist. Bei diesem Schritt muss nicht nur die Sicherungsdatei in der Zieldatenbank wiederhergestellt werden. In der Regel müssen Sie auch die Transaktionslogs wiederverwenden, um einen möglichst niedrigen RTO-Wert zu erzielen. Im Folgenden wird ein typischer Wiederherstellungsablauf dargestellt:

  1. Erstellen Sie ein benutzerdefiniertes Image Ihres Datenbankservers in Google Cloud. Der Datenbankserver muss im Image dieselbe Konfiguration haben wie der lokale Datenbankserver.
  2. Implementieren Sie einen Vorgang zum Kopieren der lokalen Sicherungsdateien und Transaktionslogdateien nach Cloud Storage. Eine Beispielimplementierung finden Sie unter Lösung 1.
  3. Starten Sie aus dem benutzerdefinierten Image eine Instanz mit minimaler Größe und fügen Sie alle erforderlichen nichtflüchtigen Speicher hinzu.
  4. Setzen Sie das Flag zum automatischen Löschen für die nichtflüchtigen Speicher auf "falsch".
  5. Übernehmen Sie die letzte, zuvor nach Cloud Storage kopierte Sicherungsdatei. Folgen Sie dazu der Anleitung für Ihr Datenbanksystem zur Wiederherstellung von Sicherungsdateien.
  6. Übernehmen Sie die neuesten Transaktions-Log-Dateien, die nach Cloud Storage kopiert wurden.
  7. Ersetzen Sie die Minimalinstanz durch eine größere Instanz, die in der Lage ist, den Produktionstraffic zu verarbeiten.
  8. Wechseln Sie die Clients und verweisen Sie auf die wiederhergestellte Datenbank in Google Cloud.

Wenn die Produktionsumgebung ausgeführt wird und Produktionsarbeitslasten unterstützt, müssen Sie die Schritte umkehren, die Sie für das Failover auf die Wiederherstellungsumgebung in Google Cloud ausgeführt haben. Im Folgenden wird ein typischer Ablauf für die Rückkehr zur Produktionsumgebung dargestellt:

  1. Erstellen Sie eine Sicherung der in Google Cloud ausgeführten Datenbank.
  2. Kopieren Sie die Sicherungsdatei in Ihre Produktionsumgebung.
  3. Übernehmen Sie die Sicherungsdatei für Ihr Produktionsdatenbanksystem.
  4. Durch Stoppen des Datenbanksystem-Dienstes verhindern Sie nun, dass Clients eine Verbindung zum Datenbanksystem in Google Cloud herstellen können. Ab diesem Zeitpunkt ist die Anwendung bis zur Wiederherstellung der Produktionsumgebung nicht verfügbar.
  5. Kopieren Sie alle Transaktionslogdateien in die Produktionsumgebung und übernehmen Sie sie.
  6. Leiten Sie die Clientverbindungen zur Produktionsumgebung um.

Lösung 2: Replikation auf einen Standby-Server in Google Cloud

Eine Möglichkeit zum Erzielen sehr niedriger RTO- und RPO-Werte besteht darin, Daten sowie in einigen Fällen den Datenbankstatus nicht einfach nur zu sichern, sondern in Echtzeit auf ein Hot-Standby des Datenbankservers zu replizieren.

  1. Verbinden Sie dafür Ihr lokales Netzwerk mit Ihrem Netzwerk in Google Cloud.
  2. Erstellen Sie ein benutzerdefiniertes Image Ihres Datenbankservers in Google Cloud. Die Konfiguration des Datenbankserver im Image muss mit der Konfiguration des lokalen Datenbankservers identisch sein.
  3. Starten Sie über das benutzerdefinierte Image eine Instanz und fügen Sie alle erforderlichen nichtflüchtigen Speicher hinzu.
  4. Setzen Sie das Flag zum automatischen Löschen für die nichtflüchtigen Speicher auf "falsch".
  5. Konfigurieren Sie die Replikation zwischen dem lokalen Datenbankserver und dem Zieldatenbankserver in Google Cloud anhand der Anleitung für die Datenbanksoftware.
  6. Clients werden im Normalbetrieb so konfiguriert, dass sie auf den lokalen Datenbankserver verweisen.

Stellen Sie nach der Konfiguration dieser Replikationstopologie die Clients so um, dass sie auf den Standby-Server im Google Cloud-Netzwerk verweisen.

Sobald die Produktionsumgebung gesichert und in der Lage ist, Produktionsarbeitslasten zu unterstützen, müssen Sie den Produktions-Datenbankserver mit dem Google Cloud-Datenbankserver neu synchronisieren und dann die Clients so umstellen, dass sie wieder auf die Produktionsumgebung verweisen.

Google Cloud als Produktionsumgebung

In diesem Szenario werden sowohl Ihre Produktionsumgebung als auch Ihre Notfallwiederherstellungsumgebung in Google Cloud ausgeführt.

Datensicherung und -wiederherstellung

Eine gängige Variante für Datensicherungen ist die Verwendung eines Musters für einen mehrstufigen Speicher. Wenn sich die Produktionsarbeitslast in Google Cloud befindet, sieht das mehrstufige Speichersystem wie im folgenden Diagramm aus. Sie migrieren dabei Daten auf eine Stufe mit geringeren Speicherkosten, da die Notwendigkeit des Zugriffs auf diese gesicherten Daten weniger wahrscheinlich ist.

DR-Bausteine:

Konzeptdiagramm mit Image und Darstellung der sinkenden Kosten, wenn Daten von nichtflüchtigen Speichern zu Nearline und Coldline migriert werden

Da die Speicherklassen Nearline, Coldline und Archive für die Speicherung von Daten gedacht sind, auf die nur selten zugegriffen wird, fallen zusätzliche Kosten für den Abruf von Daten oder Metadaten an, die in diesen Klassen gespeichert sind, sowie für die Mindestspeicherdauer, die Ihnen in Rechnung gestellt wird.

Datenbanksicherung und -wiederherstellung

Wenn Sie eine selbstverwaltete Datenbank verwenden, wenn also z. B. auf einer Instanz von Compute Engine MySQL, PostgreSQL oder SQL Server installiert ist, gelten die gleichen Anforderungen wie für die Verwaltung von lokalen Produktionsdatenbanken. Sie müssen dabei aber nicht mehr die zugrunde liegende Infrastruktur verwalten.

Sie können mit den entsprechenden DR-Bausteinfunktionen HV-Konfigurationen einrichten, die niedrige RTO-Werte gewährleisten. Mit der entsprechenden Datenbankkonfiguration lässt sich auf einfache Weise ein Status wiederherstellen, der dem Zustand vor dem Notfall so nahe wie möglich kommt. Dies ermöglicht niedrige RPO-Werte. Google Cloud bietet bei diesem Szenario eine Vielzahl von Optionen.

In diesem Abschnitt werden zwei gängige Ansätze erläutert, wie Sie die Architektur zur Datenbankwiederherstellung für selbstverwaltete Datenbanken in Google Cloud entwerfen können.

Datenbankserver ohne Statussynchronisierung wiederherstellen

Ein gängiges Muster ist die Wiederherstellung eines Datenbankservers, bei dem der Systemstatus nicht mit einem Hot-Standby-Modus synchronisiert werden muss.

DR-Bausteine:

  • Compute Engine
  • Verwaltete Instanzgruppen
  • Cloud Load Balancing (internes Load-Balancing)

Im folgenden Diagramm ist eine Beispielarchitektur für dieses Szenario veranschaulicht. Mit Implementierung dieser Architektur erhalten Sie einen DR-Plan, der automatisch auf einen Fehlerstatus reagiert, sodass keine manuelle Wiederherstellung erforderlich ist.

Architekturdiagramm mit dem Image eines nichtflüchtigen Speichers, das von einem nichtflüchtigen Speicher in einer Zone erstellt wurde

Mit den folgenden Schritten können Sie ein solches Szenario konfigurieren:

  1. Erstellen Sie ein VPC-Netzwerk.

  2. Erstellen Sie ein benutzerdefiniertes Image, das mit dem Datenbankserver konfiguriert ist. Führen Sie dazu folgende Schritte aus:

    1. Konfigurieren Sie den Server so, dass die Datenbankdateien und Logdateien in einen hinzugefügten nichtflüchtigen Standardspeicher geschrieben werden.
    2. Erstellen Sie einen Snapshot vom hinzugefügten nichtflüchtigen Speicher.
    3. Konfigurieren Sie ein Startskript, das einen nichtflüchtigen Speicher aus dem Snapshot erstellt und das Laufwerk bereitstellt.
    4. Erstellen Sie ein benutzerdefiniertes Image des Startlaufwerks.

  3. Erstellen Sie eine Instanzvorlage, die das Image verwendet.

  4. Konfigurieren Sie mithilfe der Instanzvorlage eine verwaltete Instanzgruppe mit einer Zielgröße von 1.

  5. Konfigurieren Sie die Systemdiagnose mithilfe von Cloud Monitoring-Messwerten.

  6. Konfigurieren Sie das interne Load-Balancing mithilfe der verwalteten Instanzgruppe.

  7. Konfigurieren Sie eine geplante Aufgabe zum Erstellen von regelmäßigen Snapshots des nichtflüchtigen Speichers.

Wenn eine Ersatzdatenbankinstanz erforderlich ist, hat diese Konfiguration folgende Auswirkungen:

  • Ein weiterer Datenbankserver der richtigen Version wird in derselben Zone aufgerufen.
  • Der neu erstellten Datenbankserverinstanz wird ein nichtflüchtiger Speicher mit den neuesten Sicherungs- und Transaktionslogdateien hinzugefügt.
  • Die Notwendigkeit einer Neukonfiguration von Clients, die als Reaktion auf ein Ereignis mit Ihrem Datenbankserver kommunizieren, wird minimiert.
  • Die Sicherheitskontrollen in Google Cloud (IAM-Richtlinien, Firewalleinstellungen), die für den Produktions-Datenbankserver gelten, werden auf den wiederhergestellten Datenbankserver angewendet.

Da die Ersatzinstanz aus einer Instanzvorlage erstellt wird, gelten die Kontrollen für das Original auch für die Ersatzinstanz.

In diesem Szenario werden einige der in Google Cloud verfügbaren Funktionen für Hochverfügbarkeit genutzt. Sie müssen keine Failover-Schritte initiieren, da sie im Notfall automatisch ausgeführt werden. Der interne Load-Balancer sorgt dafür, dass bei einer erforderlichen Ersatzinstanz dieselbe IP-Adresse für den Datenbankserver verwendet wird. Die Instanzvorlage und das benutzerdefinierte Image garantieren, dass die Ersatzinstanz wie die Instanz konfiguriert ist, die sie ersetzt. Erstellen Sie regelmäßig Snapshots der nichtflüchtigen Speicher. Dies stellt sicher, dass die Ersatzinstanz, wenn Laufwerke aus den Snapshots neu erstellt und der Ersatzinstanz hinzugefügt wurden, Daten verwendet, die gemäß einem durch Häufigkeit der Snapshots bestimmten RPO-Wert wiederhergestellt wurden. In dieser Architektur werden auch die neuesten Transaktions-Logdateien, die auf den nichtflüchtigen Speicher geschrieben wurden, automatisch wiederhergestellt.

Die verwaltete Instanzgruppe ermöglicht eine umfassende Hochverfügbarkeit. Sie bietet auf Anwendungs- oder Instanzebene automatisierte Verfahren zur Reaktion auf Fehler. Sie müssen also nicht manuell eingreifen, wenn eines dieser Szenarien eintritt. Wenn Sie eine Zielgröße von eins festlegen, haben Sie immer nur eine aktive Instanz, die in der verwalteten Instanzgruppe ausgeführt wird und Traffic bereitstellt.

Nichtflüchtige Standardspeicher sind zonale Ressourcen. Wenn ein Zonenfehler auftritt, sind Snapshots für die Neuerstellung von Laufwerken erforderlich. Snapshots stehen auch für die verschiedenen Regionen zur Verfügung. Dadurch können Sie ein Laufwerk in einer anderen Region genauso einfach wiederherstellen wie in derselben Region.

Eine Variante dieser Konfiguration besteht darin, regionale nichtflüchtige Speicher anstelle von nichtflüchtigen Standardspeichern zu verwenden. In diesem Fall müssen Sie den Snapshot im Rahmen des Wiederherstellungsschritts nicht wiederherstellen.

Die jeweils geeignete Variante hängt von Ihrem Budget sowie von den RTO- und RPO-Werten ab.

Weitere Informationen zu Datenbankkonfigurationen für Hochverfügbarkeits- und DR-Szenarien in Google Cloud finden Sie hier:

Nach teilweiser Beschädigung in sehr großen Datenbanken wiederherstellen

In Datenbanken mit einer Speicherkapazität im Petabyte-Bereich können Ausfälle auftreten, die sich nur auf einen Teil der Daten auswirken. In diesem Fall können Sie die Menge der wiederherzustellenden Daten minimieren. Sie müssen also nicht die gesamte Datenbank wiederherstellen, nur um einige Daten daraus wiederherzustellen.

Dabei sind mehrere Strategien zur Reduzierung möglich:

  • Speichern der Daten in unterschiedlichen Tabellen für bestimmte Zeiträume. Dadurch wird gewährleistet, dass nur eine Teilmenge von Daten in einer neuen Tabelle wiederhergestellt werden muss und nicht das gesamte Dataset.

  • Speichern der Originaldaten in Cloud Storage. So können Sie eine neue Tabelle erstellen und die unbeschädigten Daten noch einmal laden. Daraufhin können Sie die Anwendungen so anpassen, dass sie auf die neue Tabelle verweisen.

Wenn Ihr RTO-Wert es zulässt, können Sie außerdem den Zugriff auf die Tabelle mit den beschädigten Daten verhindern. Dazu belassen Sie die Anwendungen im Offline-Modus, bis die unbeschädigten Daten in einer neuen Tabelle wiederhergestellt sind.

Verwaltete Datenbankdienste in Google Cloud

Dieser Abschnitt erläutert einige Methoden, mit denen Sie geeignete Sicherungs- und Wiederherstellungsverfahren für die verwalteten Datenbankdienste in Google Cloud implementieren können.

Verwaltete Datenbanken sind auf Skalierbarkeit ausgelegt. Daher sind die herkömmlichen Sicherungs- und Wiederherstellungsverfahren traditioneller RDMBS-Systeme dafür in der Regel nicht verfügbar. Wie bei selbstverwalteten Datenbanken soll bei einer Datenbank, in der sich Petabyte von Daten speichern lassen, grundsätzlich die Datenmenge minimiert werden, die in einem DR-Szenario wiederhergestellt werden muss. Für jede verwaltete Datenbank gibt es eine Reihe von Strategien zur Erreichung dieses Ziels.

Bigtable bietet Bigtable-Replikation. Eine replizierte Bigtable-Datenbank bietet bei zonalen oder regionalen Ausfällen eine höhere Verfügbarkeit als ein einzelner Cluster, zusätzlichen Lesedurchsatz und eine höhere Langlebigkeit und Ausfallsicherheit.

Bigtable-Sicherungen bieten einen vollständig verwalteten Dienst, mit dem Sie eine Kopie des Schemas und der Daten einer Tabelle speichern und später von der Sicherung in einer neuen Tabelle wiederherstellen können.

Außerdem können Sie Tabellen als eine Reihe von Hadoop-Sequenzdateien aus Bigtable exportieren. Diese Dateien lassen sich dann in Cloud Storage speichern oder Sie verwenden sie, um die Daten wieder in eine andere Bigtable-Instanz zu importieren. In einer Google Cloud-Region haben Sie die Möglichkeit, ein Bigtable-Dataset asynchron zwischen Zonen zu replizieren.

BigQuery: Für die Archivierung von Daten bietet BigQuery einen langfristigen Speicher. Wenn eine Tabelle innerhalb von 90 aufeinanderfolgenden Tagen nicht bearbeitet wird, reduziert sich der Preis für die Speicherung dieser Tabelle automatisch um 50 %. Wenn eine Tabelle in die Langzeitspeicherung übergeht, kommt es zu keiner Beeinträchtigung von Leistung, Langlebigkeit, Verfügbarkeit oder anderer Funktionen. Wird die Tabelle jedoch wieder bearbeitet, gelten wieder die regulären Speicherpreise und der 90-Tage-Zeitraum tritt von Neuem in Kraft.

BigQuery wird in zwei Zonen in einer einzelnen Region repliziert, was aber bei der Beschädigung von Tabellen wenig nützt. Sie benötigen daher einen Plan zur Wiederherstellung bei einem solchen Szenario. Sie haben zum Beispiel folgende Möglichkeiten:

  • Wenn die Beschädigung innerhalb von sieben Tagen festgestellt wird, fragen Sie die Tabelle für einen früheren Zeitpunkt ab, um sie in einem Zustand vor der Beschädigung mithilfe von Snapshot-Decorators wiederherzustellen
  • Sie exportieren die Daten aus BigQuery und erstellen eine neue Tabelle mit den exportierten Daten, in der die beschädigten Daten nicht enthalten sind
  • Speichern der Daten in unterschiedlichen Tabellen für bestimmte Zeiträume. Dies stellt sicher, dass Sie nur eine Teilmenge der Daten in einer neuen Tabelle wiederherstellen müssen und nicht das gesamte Dataset
  • Erstellen Sie Kopien eines Datasets in bestimmten Zeiträumen. Sie können diese Kopien verwenden, wenn eine Datenkorruption auftritt, die jenseits eines Zeitpunkts stattfindet, der von einer zeitnahen Abfrage erfasst werden kann (z. B. vor mehr als 7 Tagen). Sie können ein Dataset auch von einer Region in eine andere kopieren, um die Verfügbarkeit der Daten bei regionalen Ausfällen zu gewährleisten.
  • Speichern der Originaldaten in Cloud Storage. So können Sie eine neue Tabelle erstellen und die unbeschädigten Daten noch einmal laden. Daraufhin können Sie die Anwendungen so anpassen, dass sie auf die neue Tabelle verweisen.

Firestore. Mit dem verwalteten Export- und Importdienst können Sie Firestore-Entitäten mit einem Cloud Storage-Bucket importieren und exportieren. Auf diese Weise lässt sich ein Vorgang implementieren, mit dem sich Daten nach einem versehentlichen Löschen wiederherstellen lassen.

Cloud SQL Wenn Sie Cloud SQL, die vollständig verwaltete Google Cloud-MySQL-Datenbank, verwenden, sollten Sie automatische Sicherungen und binäres Logging für Cloud SQL-Instanzen aktivieren. So können Sie eine Wiederherstellung zu einem bestimmten Zeitpunkt ausführen. Dabei wird die Datenbank aus einer Sicherung in einer neuen Cloud SQL-Instanz wiederhergestellt. Weitere Details finden Sie in Cloud SQL-Sicherungen und -Wiederherstellung.

Cloud SQL lässt sich auch in einer HA-Konfiguration und regionenübergreifenden Replikaten konfigurieren, um bei einem zonalen oder regionalen Ausfall die Betriebszeit hoch zu halten.

Spanner Mit Dataflow-Vorlagen haben Sie die Möglichkeit, Ihre Datenbank vollständig in Avro-Dateien in einen Cloud Storage-Bucket zu exportieren. Mit einer anderen Vorlage können Sie die exportierten Dateien dann wieder in eine neue Spanner-Datenbank importieren.

Der Dataflow-Connector bietet Ihnen die Möglichkeit, den entsprechenden Code zu schreiben, um Daten in Spanner in einer Dataflow-Pipeline zu lesen bzw. in diese zu schreiben. Dadurch können Sie Sicherungen besser steuern. Mit dem Connector lassen sich beispielsweise Daten aus Spanner in Cloud Storage als Sicherungsziel kopieren. Die Geschwindigkeit, mit der Daten aus Spanner gelesen oder zurückgeschrieben werden können, hängt dabei von der Anzahl der konfigurierten Knoten ab. Dies hat direkten Einfluss auf Ihre RTO-Werte.

Das Commit-Zeitstempelfeature von Spanner kann für inkrementelle Sicherungen hilfreich sein. Es bietet die Möglichkeit, nur die Zeilen auszuwählen, die seit der letzten kompletten Sicherung hinzugefügt oder geändert wurden.

Für verwaltete Sicherungen können Sie mit Cloud Spanner Backup and Restore einheitliche Sicherungen erstellen, die bis zu 1 Jahr lang aufbewahrt werden können. Der RTO-Wert ist im Vergleich zu export niedriger, da durch die Wiederherstellung die Sicherung direkt bereitgestellt wird, ohne die Daten zu kopieren.

Bei kleinen RTO-Werten können Sie eine Warm-Stand-by-Spanner-Instanz einrichten und bei dieser die mindestens erforderlichen Knoten konfigurieren, um Ihrem Speicher-, Lese- und Schreibdurchsatz Rechnung zu tragen.

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time-Recovery, PITR) von Spanner können Sie Daten von einem bestimmten Zeitpunkt in der Vergangenheit wiederherstellen. Wenn ein Operator beispielsweise versehentlich Daten schreibt oder eine Anwendungseinführung eine beschädigte Datenbank verursacht, können Sie mit PITR die Daten eines früheren Zeitpunkts wiederherstellen, der maximal sieben Tage zurückliegt.

Cloud Composer: Mit Cloud Composer, eine verwaltete Version von Apache Airflow, lassen sich regelmäßige Sicherungen mehrerer Google Cloud-Datenbanken planen. Sie können einen gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) erstellen, der nach einem bestimmten Zeitplan (z. B. täglich) ausgeführt wird, um die Daten entweder in ein anderes Projekt, ein anderes Dataset oder in eine andere Tabelle (je nach verwendeter Lösung) zu kopieren oder nach Cloud Storage zu exportieren.

Das Exportieren oder Kopieren von Daten kann mit den verschiedenen Cloud Platform-Operatoren ausgeführt werden.

Sie können einen DAG beispielsweise für einen der folgenden Schritte erstellen:

Andere Cloud als Produktionsumgebung

In diesem Szenario verwendet Ihre Produktionsumgebung einen anderen Cloud-Anbieter. In Ihrem Plan für die Notfallwiederherstellung wird Google Cloud als Wiederherstellungsort genutzt.

Datensicherung und -wiederherstellung

Die Übertragung von Daten zwischen Objektspeichern ist ein häufiger Anwendungsfall für DR-Szenarien. Der Storage Transfer Service ist mit Amazon S3 kompatibel und wird für die Übertragung von Objekten von Amazon S3 nach Cloud Storage empfohlen.

Sie können einen Übertragungsjob für die Planung einer regelmäßigen Synchronisierung von der Datenquelle zur Datensenke konfigurieren. Dabei stehen erweiterte Filter basierend auf dem Datum der Dateierstellung, den Dateinamen und den bevorzugten Tageszeiten zur Verfügung. Um den gewünschten RPO-Wert zu erreichen, müssen Sie die folgenden Faktoren berücksichtigen:

  • Änderungsrate. Die Datenmenge, die für einen bestimmten Zeitraum generiert oder aktualisiert wird. Je höher die Änderungsrate, desto mehr Ressourcen sind für die Übertragung der Änderungen an das Ziel bei jedem inkrementellen Übertragungszeitraum erforderlich.

  • Übertragungsleistung Die für das Übertragen von Dateien benötigte Zeit. Bei großen Dateiübertragungen wird dieser Wert normalerweise durch die verfügbare Bandbreite zwischen Quelle und Ziel bestimmt. Wenn ein Übertragungsjob jedoch aus einer großen Anzahl kleiner Dateien besteht, können die Abfragen pro Sekunde zu einem einschränkenden Faktor werden. In diesem Fall können Sie mehrere gleichzeitige Jobs planen, um die Leistung zu skalieren, solange die Bandbreite ausreicht. Wir empfehlen Ihnen, die Übertragungsleistung mithilfe einer repräsentativen Teilmenge Ihrer realen Daten zu messen.

  • Häufigkeit. Das zeitliche Intervall zwischen Sicherungsjobs. Die Aktualität der Daten am Ziel entspricht dem Zeitpunkt, zu dem ein Übertragungsjob das letzte Mal geplant wurde. Daher ist es wichtig, dass die Intervalle zwischen aufeinanderfolgenden Übertragungsjobs nicht länger als das RPO-Ziel sind. Wenn das RPO-Ziel beispielsweise 1 Tag beträgt, muss der Übertragungsjob mindestens einmal am Tag geplant werden.

  • Monitoring und Warnungen. Storage Transfer Service bietet Pub/Sub-Benachrichtigungen für verschiedene Ereignisse. Wir empfehlen, diese Benachrichtigungen zu abonnieren, um unerwartete Fehler oder Änderungen bei den Abschlusszeiten des Jobs zu bewältigen.

Eine weitere Option zum Verschieben von Daten von AWS in Google Cloud ist boto. Das Python-Tool ist mit Amazon S3 und Cloud Storage kompatibel. Es kann im gsutil-Befehlszeilentool als Plug-in installiert werden.

Datenbanksicherung und -wiederherstellung

In diesem Artikel werden weder die verschiedenen integrierten Sicherungs- und Wiederherstellungsverfahren der Datenbanken von Drittanbietern noch die Sicherungs- und Wiederherstellungstechniken anderer Cloudanbieter im Detail behandelt. Wenn Sie nicht verwaltete Datenbanken für die Compute-Dienste verwenden, stehen Ihnen Hochverfügbarkeitsfunktionen Ihres Produktionscloudanbieters zur Verfügung. Sie können diese erweitern, um eine Hochverfügbarkeitsbereitstellung in Google Cloud einzubinden. Alternativ bietet sich Cloud Storage als kalter Datenspeicher für Ihre Sicherungsdateien von Datenbanken an.

Nächste Schritte