Daten mit Sicherungen schützen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird die Referenzarchitektur für die AlloyDB Omni-Standardverfügbarkeit beschrieben, die Datenschutz mithilfe von Sicherungen bietet.

Anwendungsfälle

Diese Referenzarchitektur unterstützt die folgenden Szenarien:

  • Sie haben Datenbanken, die eine gewisse Ausfallzeit und einen gewissen Datenverlust seit der letzten Sicherung tolerieren können.
  • Sie möchten Ihre AlloyDB Omni-Datenbank vor Benutzerfehlern, Beschädigungen oder physischen Fehlern auf Datenbankebene schützen (im Gegensatz zu Server- oder VM-Image-Snapshots).
  • Sie möchten Ihre Datenbank lokal oder remote wiederherstellen, möglicherweise bis zu einem bestimmten Zeitpunkt.

Funktionsweise der Referenzarchitektur

Die Referenzarchitektur für Standardverfügbarkeit deckt die Sicherung und Wiederherstellung Ihrer AlloyDB Omni-Datenbanken ab.

Die Standardverfügbarkeit ist eine einfache Implementierung, bei der weniger zusätzliche Hardware oder Dienste erforderlich sind. Das Recovery Time Objective (RTO) steigt jedoch mit der Größe der Datenbank. Je mehr Daten gesichert werden müssen, desto länger dauert es, die Datenbank wiederherzustellen. Der Datenverlust hängt vom Typ der Sicherung ab. Wenn nur Datendateien regelmäßig gesichert werden, kommt es bei der Wiederherstellung zu Datenverlusten seit der letzten Sicherung.

RPO reduzieren

Mit der Funktion kontinuierliche Archivierung von PostgreSQL können Sie ein niedriges Recovery Point Objective (RPO) erreichen und die Wiederherstellung zu einem bestimmten Zeitpunkt über Sicherungen ermöglichen. Dabei werden Write-Ahead-Logging-Dateien (WAL) archiviert und WAL-Daten gestreamt, möglicherweise an einen Remote-Speicherstandort.

Wenn die Archivierung von WAL-Dateien nur in bestimmten Intervallen vorgenommen wird oder wenn sie voll sind, beschränkt ein vollständiger Datenbankverlust (einschließlich der aktuellen WAL-Dateien) die Wiederherstellung auf die letzte archivierte WAL-Datei. Das bedeutet, dass Ihr RPO einen potenziellen Datenverlust berücksichtigen muss. Umgekehrt minimiert die kontinuierliche WAL-Datenübertragung den potenziellen Datenverlust.

Wenn Sie kontinuierliche Sicherungen konfigurieren, können Sie eine Wiederherstellung zu einem bestimmten Zeitpunkt ausführen. Durch die Wiederherstellung zu einem bestimmten Zeitpunkt können Sie den Zustand vor einem Fehler wiederherstellen, z. B. vor dem versehentlichen Löschen einer Tabelle oder vor falschen Batch-Updates. Diese Wiederherstellungsmethode wirkt sich jedoch sowohl auf das RPO als auch auf das RTO aus, sofern Sie keine temporäre Hilfsdatenbank verwenden. Wenn Sie eine gesamte Datenbank an Ort und Stelle wiederherstellen, werden nachfolgende Transaktionen für nicht betroffene Tabellen rückgängig gemacht und die Datenbank wird offline genommen. Wenn Sie die Datenbank in einer temporären Hilfsdatenbank wiederherstellen, können Sie nur die wiederhergestellten Daten kopieren.

Sicherungsstrategien

AlloyDB Omni unterstützt Datenschutzstrategien wie regelmäßige physische Sicherungen, Wiederherstellung zu einem bestimmten Zeitpunkt, WAL-Archivierung und -Streaming sowie das Speichern von Sicherungen an verschiedenen Standorten. Alternativ können Sie für kleine Datenbanken eine logische Sicherung mit pg_dump für eine einzelne Datenbank oder mit pg_dumpall für den gesamten Cluster durchführen und die Wiederherstellung mit pg_restore vornehmen.

Sicherungstools

Bei Container- und Linux-Bereitstellungen können Sie Sicherungen mit den folgenden PostgreSQL-Tools planen und verwalten:

Je nach Bereitstellungsoption können Sie AlloyDB Omni so konfigurieren, dass Sicherungen entweder im lokalen oder im Remote-Speicher gespeichert werden, z. B. in Cloud Storage oder in Speicheroptionen, die von einem beliebigen Cloud-Anbieter bereitgestellt werden. Lokaler Speicher ist zwar möglicherweise schneller zu sichern und wiederherzustellen, aber Remote-Speicher ist in der Regel robuster, wenn ein ganzer Host oder eine ganze VM ausfällt. Weitere Informationen finden Sie in Abbildung 1, in der potenzielle Sicherungsziele dargestellt sind.

AlloyDB Omni mit Sicherungsoptionen

Abbildung 1. AlloyDB Omni mit Sicherungsoptionen

Sie können Sicherungen entweder auf lokalen oder Remote-Speicheroptionen erstellen. Lokale Sicherungen sind normalerweise schneller, da sie nur auf dem E/A-Durchsatz basieren, während Remote-Sicherungen in der Regel eine höhere Latenz und eine geringere Netzwerkbandbreite haben. Remote-Sicherungen bieten jedoch einen besseren Schutz vor Host- und zonalen Ausfällen als lokale Sicherungen.

Sie können lokale Sicherungen auch auf lokalen oder freigegebenen Speicher aufteilen. Lokale Speicheroptionen sind von fehlenden Optionen zur Notfallwiederherstellung betroffen, wenn ein Datenbankhost ausfällt. Bei freigegebenem Speicher kann dieser Speicher auf einen anderen Server verlagert und dann für die Wiederherstellung verwendet werden. Das bedeutet, dass das RTO bei freigegebenem Speicher möglicherweise kürzer ist.

Bei Bereitstellungen mit lokalem, freigegebenem und Remote-Speicher können Sie die folgenden Arten von Sicherungen planen oder manuell on demand erstellen:

  • Vollsicherungen: vollständige Sicherungen aller Datenbankdateien, die für die Datenwiederherstellung erforderlich sind.
  • Differenzielle Sicherungen: Sicherungen nur der Dateiänderungen seit der letzten Vollsicherung.
  • Inkrementelle Sicherungen: Sicherungen nur der Dateiänderungen seit der letzten Sicherung jeglicher Art.

Wiederherstellung zu einem bestimmten Zeitpunkt

Kontinuierliche Sicherungen der PostgreSQL-WAL-Dateien unterstützen die Wiederherstellung zu einem bestimmten Zeitpunkt. Wenn die WAL-Dateien nach einem Fehlerereignis intakt und verwendbar sind, können Sie sie zur Wiederherstellung zu einem bestimmten Zeitpunkt verwenden und so den Datenverlust minimieren.

WAL-Daten an einen Remote-Standort streamen

Je nach Sicherungstool (z. B. Barman) können Sie WAL-Daten so konfigurieren, dass sie in Echtzeit an einen Remote-Standort gestreamt werden, um den Datenverlust bei der Wiederherstellung zu minimieren. Auch beim Echtzeit-Streaming besteht eine geringe Wahrscheinlichkeit, dass Transaktionen, für die ein Commit durchgeführt wurde, verloren gehen, da Streaming-Schreibvorgänge am Remote-Standort standardmäßig asynchron sind. Sie können WAL-Streaming jedoch so konfigurieren, dass der synchrone Modus verwendet wird. Dabei werden die WAL-Daten gespeichert und eine Statusantwort an die Quelldatenbank zurückgesendet. Beachten Sie, dass dieser Ansatz Transaktionen verlangsamen kann, sofern sie warten müssen, bis dieser Schreibvorgang abgeschlossen ist, bevor sie fortgesetzt werden können.

Sicherungszeitpläne

In den meisten Umgebungen werden Sicherungen in der Regel wöchentlich geplant. Im Folgenden finden Sie einen typischen wöchentlichen Plan für Sicherungen:

  • Sonntag: Vollsicherung
  • Montag, Dienstag: inkrementelle Sicherung
  • Mittwoch: differenzielle Sicherung
  • Donnerstag, Freitag: inkrementelle Sicherung
  • Samstag: differenzielles Backup

Bei der Verwendung dieses typischen Zeitplans ist für ein fortlaufendes Wiederherstellungsfenster von einer Woche Speicherplatz für bis zu drei Vollsicherungen sowie die erforderlichen inkrementellen oder differenziellen Sicherungen erforderlich. Dieser Ansatz unterstützt die Wiederherstellung nach einem Fehler, der während der Vollsicherung am Sonntag auftritt, wenn die Datenbankwiederherstellung bis zum vorherigen Sonntag vor dem Start der Sicherung erfolgen muss.

Um das RTO bei einem potenziell höheren RPO zu minimieren, können zusätzliche Datenbanken im kontinuierlichen Wiederherstellungsmodus betrieben werden. In diesem Modus werden Sicherungen wiederholt und die sekundäre Umgebung kontinuierlich aktualisiert, indem neue WAL-Dateien archiviert und wiederholt werden. Das tatsächliche RPO, das den potenziellen Datenverlust widerspiegelt, hängt von der Transaktionshäufigkeit, der WAL-Dateigröße und der Verwendung von WAL-Streaming ab.

Sicherungswiederherstellung

Sie können eine AlloyDB Omni-Datenbank aus einer gespeicherten Sicherung wiederherstellen oder zu einem bestimmten Zeitpunkt innerhalb Ihres Aufbewahrungszeitraums wiederherstellen. Je nach Bereitstellungsumgebung und Wiederherstellungsanforderungen können Sie Daten entweder direkt wiederherstellen oder die Sicherung in einer neuen Datenbankinstanz oder einem neuen Cluster wiederherstellen.

Bei Container- und Linux-Bereitstellungen müssen Sie zum Wiederherstellen einer AlloyDB Omni-Datenbank in der Regel den Datenbankdienst oder Container beenden und Daten im vorhandenen Datenverzeichnis wiederherstellen oder Daten an einem neuen Speicherort wiederherstellen und eine neue Datenbankinstanz mit diesen wiederhergestellten Daten starten. Weitere Informationen finden Sie unter AlloyDB Omni-Cluster mit pgBackRest wiederherstellen oder AlloyDB Omni-Cluster mit Barman wiederherstellen.

Implementierung

Wenn Sie eine Referenzarchitektur für die Verfügbarkeit auswählen, sollten Sie die folgenden Vorteile, Einschränkungen und Alternativen berücksichtigen.

Vorteile

  • Einfach zu verwenden und zu verwalten und für nicht kritische Datenbanken mit tolerantem RTO und RPO geeignet
  • Es ist nur minimale zusätzliche Hardware erforderlich.
  • Bietet die grundlegenden Sicherungen, die für einen Notfallwiederherstellungsplan erforderlich sind.
  • Unterstützt die Wiederherstellung zu einem beliebigen Zeitpunkt innerhalb des Wiederherstellungszeitraums.

Beschränkungen

  • Kann je nach Aufbewahrungsanforderungen mehr Speicherplatz als die Datenbank selbst erfordern.
  • Wiederherstellung kann lange dauern und zu einem höheren RTO führen
  • Kann je nach Verfügbarkeit der aktuellen WAL-Daten nach einem Datenbankfehler zu einem gewissen Datenverlust führen, was sich negativ auf den RPO auswirken kann.

Alternativen

Erwägen Sie die Referenzarchitektur für erweiterte Verfügbarkeit oder Premium-Verfügbarkeit, um die Verfügbarkeit und die Optionen zur Notfallwiederherstellung zu verbessern.

Nächste Schritte