Der aktuelle Stand der Open-Source-Sicherungsverwaltung für PostgreSQL

Es gibt viele Möglichkeiten, Backups eines PostgreSQL-Clusters zu erstellen. Es gibt mehrere Artikel und Blogs, die die verschiedenen Technologien vorstellen, mit denen wir unsere wertvollen Daten in PostgreSQL speichern können. Es gibt logische Backup-Lösungen, physische Backups auf Betriebssystemebene, auf Dateisystemebene und so weiter. Hier in diesem Blog werden wir den theoretischen Teil nicht abdecken, der durch verschiedene Blogs und Artikel sowie die offizielle Dokumentation ausreichend abgedeckt wird.

Dieser Blog konzentriert sich auf den Stand der verschiedenen verfügbaren Tools und Lösungen und bemüht sich, einen gründlichen Vergleich basierend auf realen Erfahrungen zu präsentieren. Dieser Artikel versucht in keiner Weise, ein bestimmtes Produkt zu bewerben, ich mag wirklich alle Tools, Lösungen und Technologien, die in diesem Blog beschrieben werden. Das Ziel hier ist es, ihre Stärken und Schwächen aufzuzeichnen und den Endbenutzer dahingehend zu führen, welches Tool am besten zu seiner Umgebung, Infrastruktur und seinen spezifischen Anforderungen passt. Hier ist ein netter Artikel, der Backup-Tools für PostgreSQL auf verschiedenen Ebenen beschreibt.

Ich werde in diesem Blog nicht beschreiben, wie die verschiedenen Tools verwendet werden, da diese Informationen im obigen Blog und auch in den offiziellen Dokumenten sowie anderen Ressourcen im Internet dokumentiert sind. Aber ich werde die Vor- und Nachteile beschreiben, wie ich sie in der Praxis erlebt habe. In diesem Blog beschäftigen wir uns ausschließlich mit klassischen PITR-basierten physischen PostgreSQL-Backups abhängig von:

• pg_basebackup oder pg_start_backup()/pg_stop_backup
• physische Kopie
• Archivierung von WALs oder Streaming-Replikation

Es gibt mehrere gute Produkte und Lösungen, einige sind Open Source und können kostenlos verwendet werden, während andere kommerziell sind. Meines Wissens nach sind dies:

• pgbarman von 2ndquadrant (kostenlos)
• pgRückenlehne (gratis)
• pg_probackup von Postgres Professional (kostenlos)
• BART von EDB (kommerziell)

Ich hatte keine Gelegenheit, BART auszuprobieren, da es auf Linux-Varianten läuft, die ich nicht verwende. In diesem Blog werde ich meine eigenen Gedanken und Eindrücke einfließen lassen, während ich mit den jeweiligen Autoren/Community/Betreuern jeder Lösung interagiere, da dies ein sehr wichtiger Aspekt ist, der am Anfang normalerweise unterschätzt wird. Ein bisschen Terminologie, um die verschiedenen Begriffe in jedem der Tools besser zu verstehen:

pgbarman

Pgbarman oder einfach nur Barmann ist das älteste dieser Werkzeuge. Die neueste Version ist 2.6 (veröffentlicht, während ich diesen Blog in Arbeit hatte! Das sind großartige Neuigkeiten).

Pgbarman unterstützt die Basissicherung über zwei Methoden:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

und WAL-Übertragung über:

• WAL-Archivierung
  • über rsync
  • über Barman-Wal-Archiv / Put-Wal
• WAL über Streaming-Replikation mit Replikationsslot
  • Asynchron
  • Synchron

Dies gibt uns 8 sofort einsatzbereite Kombinationen, mit denen wir Barkeeper verwenden können. Jeder hat seine Vor- und Nachteile.

Basissicherung über pg_basebackup (backup_method =postgres)

Vorteile:

• die neueste/modernste Art
• basiert auf bewährter PostgreSQL-Kerntechnologie
• von den offiziellen Dokumenten empfohlen

Nachteile:

• keine inkrementelle Sicherung
• keine parallele Sicherung
• keine Netzwerkkomprimierung
• keine Datendeduplizierung
• keine Begrenzung der Netzwerkbandbreite

Basissicherung über rsync (backup_method =rsync)

Vorteile:

• alt und bewährt
• Inkrementelle Sicherung
• Datendeduplizierung
• Netzwerkkomprimierung
• parallele Sicherung
• Netzwerkbandbreitenlimit

Nachteile:

• nicht der (von den Autoren) empfohlene Weg

WAL-Übertragung über WAL-Archivierung (über rsync)

Vorteile:

• einfacher einzurichten

Nachteile:

• Kein RPO=0 (kein Datenverlust)
• keine Möglichkeit zur Wiederherstellung nach langen und anhaltenden Netzwerkausfällen

WAL-Übertragung über WAL-Archivierung (über barman-wal-archive / put-wal)

Vorteile:

• der neueste und empfohlene Weg (eingeführt in 2.6)
• zuverlässiger/sicherer als rsync

Nachteile:

• Kein RPO=0 (kein Datenverlust)
• immer noch keine Möglichkeit, sich von langen und andauernden Netzwerkausfällen zu erholen

WAL-Übertragung per WAL-Streaming mit Replikationsslot (über pg_receivewal)

Vorteile:

• moderner (und empfohlen)
• RPO=0 (kein Datenverlust) im synchronen Modus

Nachteile:

• Immer mit Replikationsslot verbunden. Kann bei Netzwerkausfällen wachsen

Während also pg_basebackup (postgres-Methode) wie die Zukunft für pgbarman aussieht, kommen in Wirklichkeit alle ausgefallenen Funktionen mit der rsync-Methode. Lassen Sie uns also alle Funktionen von Barman detaillierter auflisten:

• Remote-Betrieb (Sicherungen/Wiederherstellungen)
• Inkrementelle Backups. Eine der großartigen Funktionen von barman, inkrementelle Sicherungen, basieren auf dem Vergleich der Datenbankdateien auf Dateiebene mit denen der letzten Sicherung im Katalog. Im Barkeeper bezieht sich der Begriff „differenziell“ auf ein anderes Konzept:In der Barmann-Terminologie ist ein differentielles Backup das letzte Backup + die individuellen Änderungen vom letzten Backup. Barman-Dokumente sagen, dass sie differenzielle Sicherungen über WALs bereitstellen. Inkrementelle Barman-Backups arbeiten auf Dateiebene, dh wenn eine Datei geändert wird, wird die gesamte Datei übertragen. Dies ist wie pgbackrest und im Gegensatz zu einigen anderen Angeboten wie pg_probackup oder BART, die differenzielle/inkrementelle Sicherungen auf Blockebene unterstützen. Inkrementelle Barman-Backups werden angegeben über:reuse_backup =verlinken oder kopieren. Durch die Definition von „Kopieren“ erreichen wir eine Verkürzung der Sicherungszeit, da nur die geänderten Dateien übertragen und gesichert werden, aber dennoch keine Reduzierung des Speicherplatzes, da die unveränderten Dateien aus der vorherigen Sicherung kopiert werden. Durch die Definition von „Link“ werden die unveränderten Dateien aus der letzten Sicherung fest verknüpft (nicht kopiert). Auf diese Weise erreichen wir sowohl Zeit- als auch Platzersparnis. Ich möchte hier keinesfalls noch mehr Verwirrung stiften, aber in Wirklichkeit sind inkrementelle Backups von barman direkt mit inkrementellen Backups von pgbackrest vergleichbar, da barman (per Link oder Kopie) ein inkrementelles Backup effektiv als vollständiges Backup behandelt. In beiden Systemen behandelt ein inkrementelles Backup also die Dateien, die seit dem letzten Backup geändert wurden. In Bezug auf differenzielle Sicherungen bedeutet dies jedoch in jedem der oben genannten Systeme etwas anderes, wie wir weiter unten sehen werden.
• Sicherung aus dem Standby. Barman bietet die Möglichkeit, den Großteil der Basis-Backup-Operationen von einem Standby-System aus durchzuführen und so das Primärsystem von der zusätzlichen E/A-Last zu befreien. Beachten Sie jedoch, dass die WALs immer noch von der Primärseite kommen müssen. Es spielt keine Rolle, ob Sie archive_command oder WAL-Streaming über Replikations-Slots verwenden, Sie können diese Aufgabe noch nicht (zum jetzigen Zeitpunkt mit Barman in Version 2.6) in den Standby auslagern.
• parallele Jobs für Sicherung und Wiederherstellung
• Ein reichhaltiger und umfassender Satz von Aufbewahrungseinstellungen basierend auf:
  • Redundanz (Anzahl der aufzubewahrenden Backups)
  • Wiederherstellungsfenster (wie weit in der Vergangenheit sollten die Backups aufbewahrt werden)
  Meiner Meinung nach ist das Obige aus Benutzersicht großartig. Der Benutzer kann reuse_backup =link und ein Wiederherstellungsfenster definieren und barman (seinen Cron-Job) den Rest erledigen lassen. Keine Diff-/Incr-/Full-usw.-Backups, über die Sie sich Gedanken machen oder die Sie planen oder verwalten müssen. Das System (Barmann) macht einfach transparent das Richtige.
• Programmieren Sie Ihre eigenen Vor-/Nachereignis-Hook-Skripte.
• Tablespace-Neuzuordnung

Das sind die größten Stärken eines Barkeepers. Und das ist wirklich fast mehr, als der durchschnittliche DBA von einem Sicherungs- und Wiederherstellungstool verlangen würde. Es gibt jedoch einige Punkte, die besser sein könnten:

• Die Mailingliste ist nicht so aktiv und die Betreuer schreiben oder beantworten selten Fragen
• Keine Funktion zum Fortsetzen eines fehlgeschlagenen/unterbrochenen Backups
• Replikationsslots oder die Verwendung von rsync/barman-wal-archive für die Archivierung verzeihen im Falle eines Netzwerkausfalls oder anderer Ausfälle der Backup-Site nicht. In beiden Fällen, wenn der Netzwerkausfall lang genug ist und die Änderungen in der Datenbank viele WAL-Dateien wert sind, leidet die primäre unter „kein Speicherplatz mehr auf dem Gerät“ und stürzt schließlich ab. (nicht gut). Vielversprechend ist hier, dass barman nun eine alternative (zu rsync) Möglichkeit bietet, WALs zu übertragen, so dass zusätzlicher Schutz vor z.B. pg_wal Platzerschöpfung könnte in Zukunft implementiert werden, was zusammen mit dem Backup-Lebenslauf den Barmann wirklich perfekt machen würde, zumindest für mich.

pgRückenlehne

Pgbackrest ist der aktuelle Trend unter den Open-Source-Backup-Tools, vor allem wegen seiner Effizienz bei der Bewältigung sehr großer Datenmengen und der äußersten Sorgfalt, mit der seine Entwickler Backups über Prüfsummen validieren. Zum jetzigen Zeitpunkt ist es Version v2.09, und die Dokumentation ist hier zu finden. Das Benutzerhandbuch ist möglicherweise etwas veraltet, aber der Rest der Dokumentation ist sehr aktuell und genau. Pgbackrest verlässt sich auf die WAL-Archivierung mit einem eigenen archive_command und einem eigenen Dateiübertragungsmechanismus, der besser und sicherer als rsync ist. pgbackrest ist also ziemlich fortschrittlich, da es nicht die größere Auswahl bietet, die der Barkeeper bietet. Da es sich nicht um einen synchronen Modus handelt, garantiert pgbackrest natürlich nicht RPO=0 (null Datenverlust). Lassen Sie uns die Konzepte von pgbackrest beschreiben:

• Ein Backup kann sein:
  • Voll. Eine vollständige Sicherung kopiert den gesamten Datenbankcluster.
  • Differential (diff). Bei einer differenziellen Sicherung werden nur die Dateien kopiert, die seit der letzten vollständigen Sicherung geändert wurden. Für eine erfolgreiche Wiederherstellung müssen sowohl die differenzielle Sicherung als auch die vorherige vollständige Sicherung gültig sein.
  • Inkrementell (inkr). Ein inkrementelles Backup kopiert nur die Dateien, die seit dem letzten Backup (das ein vollständiges Backup, ein differentielles oder sogar ein inkrementelles Backup sein kann) geändert wurden. Ähnlich wie bei der differenziellen Sicherung müssen für eine erfolgreiche Wiederherstellung alle vorherigen erforderlichen Sicherungen (einschließlich dieser Sicherung, der letzten Differenz und der vorherigen vollständigen) gültig sein.
• Eine Zeilengruppe ist die Definition aller erforderlichen Parameter eines PostgreSQL-Clusters. Ein PostgreSQL-Server hat normalerweise seine eigene Zeilengruppe, während Sicherungsserver eine Zeilengruppe für jeden PostgreSQL-Cluster haben, den sie sichern.
• In einer Konfiguration werden Informationen über Zeilengruppen gespeichert (normalerweise /etc/pgbackrest.conf)
• In einem Repository speichert pgbackrest WALs und Backups

Der Benutzer wird ermutigt, der Dokumentation so zu folgen, wie es die Dokumentation selbst vorschlägt, von oben nach unten. Die wichtigsten Features von pgbackrest sind:

• Parallele Sicherung und Wiederherstellung
• Kein direkter SQL-Zugriff auf den PostgreSQL-Server erforderlich
• Lokaler/Remote-Betrieb
• Aufbewahrung basierend auf:
  • Aufbewahrung vollständiger Sicherungen (Anzahl der aufzubewahrenden vollständigen Sicherungen)
  • Diff-Backup-Aufbewahrung (Anzahl der aufzubewahrenden Diff-Backups)
  Inkrementelle Backups haben keine eigene Aufbewahrung und verfallen, sobald ein vorheriges Backup abläuft. So kann der Benutzer einen Zeitplan für die Erstellung vollständiger Backups und einen fortlaufenden Satz von Diff-Backups zwischen ihnen definieren.
• Sicherung aus dem Standby. Einige Dateien müssen immer noch von der primären Datei stammen, aber die Massenkopie findet auf der Standby-Datei statt. Dennoch müssen WALs von der Primärseite stammen.
• Sicherungsintegrität. Die Leute hinter pgbackrest sind äußerst vorsichtig, wenn es um die Integrität der Backups geht. Jede Datei wird zum Sicherungszeitpunkt und auch nach der Wiederherstellung einer Prüfsumme unterzogen, um sicherzustellen, dass kein problematischer Hardware- oder Softwarefehler zu einer fehlerhaften Wiederherstellung führen kann. Auch wenn Prüfsummen auf Seitenebene auf dem PostgreSQL-Cluster aktiviert sind, werden sie auch für jede Datei berechnet. Zusätzlich werden Prüfsummen für jede WAL-Datei berechnet.
• Wenn die Komprimierung deaktiviert und Hardlinks aktiviert sind, ist es möglich, den Cluster direkt aus dem Katalog aufzurufen. Dies ist extrem wichtig für mehrere TB große Datenbanken.
• Wiederaufnahme eines fehlgeschlagenen/unterbrochenen Backs. Sehr praktisch bei unzuverlässigen Netzwerken.
• Delta-Wiederherstellung:Ultraschnelle Wiederherstellung großer Datenbanken, ohne den gesamten Cluster zu bereinigen.
• Asynchroner und paralleler WAL-Push zum Backup-Server. Dies ist einer der stärksten Punkte von pgbackrest. Der PostgreSQL-Archiver kopiert nur per Archive-Push in die Spool-Datei, und die schwere Arbeit der Übertragung und Verarbeitung erfolgt in einem separaten pgbackrest-Prozess. Dies ermöglicht massive WAL-Übertragungen und gewährleistet gleichzeitig niedrige PostgreSQL-Antwortzeiten.
• Tablespace-Neuzuordnung
• Amazon S3-Unterstützung
• Unterstützung für maximale WAL-Warteschlangengröße. Wenn die Backup-Site ausgefallen ist oder das Netzwerk ausfällt, täuscht die Verwendung dieser Option vor, als wäre die Archivierung erfolgreich gewesen, was PostgreSQL erlaubt, WAL zu löschen, wodurch verhindert wird, dass pg_wal gefüllt wird, und somit den pgsql-Server vor einer möglichen PANIK bewahrt.

In Bezug auf die Funktionen legt pgbackrest also viel Wert auf Datenvalidierung und Leistung, keine Überraschung, dass es von den größten und am stärksten ausgelasteten PostgreSQL-Installationen verwendet wird. Allerdings gibt es eine Sache, die verbessert werden könnte:

• Es wäre wirklich praktisch, eine „liberalere“ Option in Bezug auf die Aufbewahrung zu haben, d. h. eine Möglichkeit zu bieten, deklarativ einen Aufbewahrungszeitraum anzugeben und dann pgbackrest die vollständigen/diff/incr-Backups nach Bedarf behandeln zu lassen.

pg_probackup

Pg_proback ist ein weiteres vielversprechendes Tool für Backups. Es basiert ursprünglich auf pg_arman. Der Schwerpunkt liegt auf der Leistung des Backups. Es basiert auf Katalogen und Instanzen, sehr ähnlich zu den anderen Tools, die wir haben. Zu den Hauptmerkmalen gehören:

• Umfangreiche Unterstützung auf Sicherungsebene von:
  • Vollständige Sicherungen
  • Inkremental von drei Typen:
    • Seitensicherung. Durch WAL-Scanning gefundene Pegeländerungen. Erfordert vollen Zugriff auf die ununterbrochene WAL-Sequenz seit der letzten Sicherung.
    • DELTA-Sicherung. Nur geänderte Seiten werden in die Sicherung kopiert. Unabhängig von der WAL-Archivierung, belastet den Server etwas.
    • PTRACK-Sicherung. Erfordert spezielles pgsql-Core-Patching. Funktioniert, indem eine Bitmap im laufenden Betrieb beibehalten wird, sobald Seiten geändert werden. Wirklich schnelles Backup mit minimaler Belastung des Servers.
• Backups können auch unterteilt werden in:
  • Autonome Backups. Diese haben außerhalb des Backups keine Anforderungen an WAL. Kein PITR.
  • Archivsicherungen. Diese setzen auf kontinuierliche Archivierung und unterstützen PITR.
• Multithread-Modell (im Gegensatz zu Barman, pgbackrest und natürlich PostgreSQL selbst, die einem Multiprozess-Modell folgen)
• Datenkonsistenz und On-Demand-Validierung ohne Wiederherstellung
• Sicherung von einem Standby ohne Zugriff auf den primären.
• Eine aussagekräftige Aufbewahrungsrichtlinienspezifikation, bei der Redundanz in UND-Weise zusammen mit Fenster verwendet werden kann. Das Zusammenführen von Sicherungen (über Zusammenführen) wird unterstützt, indem frühere inkrementelle Sicherungen in vollständige Sicherungen umgewandelt werden, um Speicherplatz freizugeben und eine Methode für eine reibungslose Sicherungsrotation bereitzustellen.

Daher bietet pg_probackup eine Reihe großartiger Funktionen mit Schwerpunkt auf Leistung, was großen Installationen zugute kommen würde. Allerdings fehlen noch einige Dinge, nämlich:

• Keine offizielle Version unterstützt Remote-Backups. Das bedeutet, dass pg_probackup auf demselben Host wie der pgsql-Cluster ausgeführt werden muss. (Es gibt einen dev-Zweig, der sich mit der Sicherung von einem entfernten Standort sowie der Archivierung auf einem entfernten Sicherungsserver befasst)
• Keine Unterstützung für eine fehlgeschlagene Sicherungsfortsetzung.

Wir können die obigen Absätze mit einer Funktionsmatrix wie der folgenden zusammenfassen.

ClusterControl

ClusterControl bietet die Funktionalität, entweder ein sofortiges Backup zu erstellen oder eines zu planen und die Aufgabe auf einfache und schnelle Weise zu automatisieren.

Wir können zwischen zwei Backup-Methoden wählen, pgdump (logisch) und pg_basebackup (binär). Wir können auch angeben, wo die Backups gespeichert werden sollen (auf dem Datenbankserver, auf dem ClusterControl-Server oder in der Cloud), die Komprimierungsstufe und die Verschlüsselung.

Außerdem können wir mit ClusterControl die Point-in-Time-Recovery-Funktion und Backup-Verifizierung verwenden, um das generierte Backup zu validieren.