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 geschaltet. 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

Für Kubernetes-Bereitstellungen können Sie kontinuierliche Sicherungen mit einem Sicherungsplan (BackupPlan) konfigurieren, der vom AlloyDB Omni-Operator für jeden Datenbankcluster verwaltet wird. Weitere Informationen finden Sie unter Sichern und Wiederherstellen in Kubernetes.

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. Lokaler Speicher bietet keine Optionen zur Notfallwiederherstellung, wenn ein Datenbankhost ausfällt. Bei freigegebenem Speicher können Sie diesen Speicher auf einen anderen Server verlagern und für die Wiederherstellung verwenden. 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.

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 Kubernetes-Bereitstellungen unterstützt der AlloyDB Omni-Operator die Wiederherstellung einer Datenbank im selben Kubernetes-Cluster und ‑Namespace aus einer benannten Sicherung oder das Klonen ab einem bestimmten Zeitpunkt. Weitere Informationen finden Sie unter Sichern und Wiederherstellen in Kubernetes und Datenbankcluster manuell aus einer Kubernetes-Sicherung klonen – Übersicht.

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