pgbackrest
2.54.0:
pgBackRest ist eine zuverlässige Sicherungs- und Wiederherstellungslösung für PostgreSQL, die sich nahtlos auf die größten Datenbanken und Arbeitslasten skalieren lässt.
pgBackRest v2.54.0 ist die aktuelle stabile Version. Versionshinweise finden Sie auf der Seite „Releases“.
Bitte finden Sie uns auf GitHub und geben Sie uns einen Stern, wenn Ihnen pgBackRest gefällt!
Bei Sicherungsvorgängen stellt die Komprimierung normalerweise den Engpass dar. Daher löst pgBackRest dieses Problem durch Parallelverarbeitung und effizientere Komprimierungsalgorithmen wie lz4 und zstd.
Ein benutzerdefiniertes Protokoll ermöglicht es pgBackRest, lokal oder remote über TLS/SSH mit minimaler Konfiguration zu sichern, wiederherzustellen und zu archivieren. Über die Protokollschicht wird außerdem eine Schnittstelle zur Abfrage von PostgreSQL bereitgestellt, sodass kein Fernzugriff auf PostgreSQL erforderlich ist, was die Sicherheit erhöht.
Mehrere Repositorys ermöglichen beispielsweise ein lokales Repository mit minimaler Aufbewahrung für schnelle Wiederherstellungen und ein Remote-Repository mit längerer Aufbewahrung für Redundanz und Zugriff im gesamten Unternehmen.
Es werden vollständige, differenzielle und inkrementelle Sicherungen unterstützt. pgBackRest ist nicht anfällig für die Zeitauflösungsprobleme von rsync, wodurch differenzielle und inkrementelle Sicherungen sicher sind, ohne dass für jede Datei eine Prüfsumme erstellt werden muss. Backups auf Blockebene sparen Platz, indem sie nur die Teile der Dateien kopieren, die sich geändert haben.
Aufbewahrungsrichtlinien können für vollständige und differenzielle Backups festgelegt werden, um eine Abdeckung für jeden Zeitrahmen zu gewährleisten. Das WAL-Archiv kann für alle Backups oder ausschließlich für die aktuellsten Backups gepflegt werden. Im letzteren Fall wird die WAL, die erforderlich ist, um ältere Backups konsistent zu machen, im Archiv beibehalten.
Prüfsummen werden für jede Datei im Backup berechnet und während einer Wiederherstellung oder Überprüfung erneut überprüft. Nachdem ein Backup das Kopieren der Dateien abgeschlossen hat, wartet es, bis jedes WAL-Segment, das erforderlich ist, um das Backup konsistent zu machen, das Repository erreicht.
Sicherungen im Repository können im gleichen Format wie ein Standard-PostgreSQL-Cluster (einschließlich Tablespaces) gespeichert werden. Wenn die Komprimierung deaktiviert und Hardlinks aktiviert sind, ist es möglich, einen Snapshot eines Backups im Repository zu erstellen und einen PostgreSQL-Cluster direkt auf dem Snapshot zu erstellen. Dies ist von Vorteil für Datenbanken im Terabyte-Bereich, deren Wiederherstellung auf herkömmliche Weise zeitaufwändig ist.
Alle Vorgänge nutzen fsync auf Datei- und Verzeichnisebene, um die Haltbarkeit sicherzustellen.
Wenn Seitenprüfsummen aktiviert sind, validiert pgBackRest die Prüfsummen für jede Datei, die während einer Sicherung kopiert wird. Alle Seitenprüfsummen werden während einer vollständigen Sicherung validiert und Prüfsummen in geänderten Dateien werden während differenzieller und inkrementeller Sicherungen validiert.
Validierungsfehler stoppen den Sicherungsvorgang nicht, aber Warnungen mit genauen Angaben darüber, welche Seiten bei der Validierung fehlgeschlagen sind, werden an die Konsole und das Dateiprotokoll ausgegeben.
Mit dieser Funktion können Beschädigungen auf Seitenebene frühzeitig erkannt werden, bevor Backups, die gültige Kopien der Daten enthalten, abgelaufen sind.
Eine unterbrochene Sicherung kann an der Stelle fortgesetzt werden, an der sie gestoppt wurde. Bereits kopierte Dateien werden mit den Prüfsummen im Manifest verglichen, um die Integrität sicherzustellen. Da dieser Vorgang vollständig auf dem Repository-Host stattfinden kann, reduziert er die Belastung des PostgreSQL-Hosts und spart Zeit, da die Prüfsummenberechnung schneller ist als das Komprimieren und erneute Übertragen von Daten.
Komprimierungs- und Prüfsummenberechnungen werden im Stream durchgeführt, während Dateien in das Repository kopiert werden, unabhängig davon, ob sich das Repository lokal oder remote befindet.
Wenn sich das Repository auf einem Repository-Host befindet, wird die Komprimierung auf dem PostgreSQL-Host durchgeführt und Dateien werden in einem komprimierten Format übertragen und einfach auf dem Repository-Host gespeichert. Wenn die Komprimierung deaktiviert ist, wird eine niedrigere Komprimierungsstufe verwendet, um die verfügbare Bandbreite effizient zu nutzen und gleichzeitig die CPU-Kosten auf ein Minimum zu beschränken.
Das Manifest enthält Prüfsummen für jede Datei im Backup, sodass bei einer Wiederherstellung die Möglichkeit besteht, diese Prüfsummen zu verwenden, um die Verarbeitung enorm zu beschleunigen. Bei einer Delta-Wiederherstellung werden zunächst alle nicht im Backup vorhandenen Dateien entfernt und anschließend Prüfsummen für die verbleibenden Dateien generiert. Dateien, die mit der Sicherung übereinstimmen, bleiben an Ort und Stelle und die restlichen Dateien werden wie gewohnt wiederhergestellt. Die parallele Verarbeitung kann zu einer drastischen Verkürzung der Wiederherstellungszeiten führen.
Es sind spezielle Befehle enthalten, um WAL in das Archiv zu übertragen und WAL aus dem Archiv abzurufen. Beide Befehle unterstützen Parallelität, um die Verarbeitung zu beschleunigen, und werden asynchron ausgeführt, um PostgreSQL die schnellstmögliche Antwortzeit zu bieten.
WAL-Push erkennt automatisch WAL-Segmente, die mehrfach gepusht werden, und dedupliziert, wenn das Segment identisch ist. Andernfalls wird ein Fehler ausgelöst. Durch asynchronen WAL-Push kann die Übertragung auf einen anderen Prozess verlagert werden, der WAL-Segmente für maximalen Durchsatz parallel komprimiert. Dies kann eine kritische Funktion für Datenbanken mit extrem hohem Schreibvolumen sein.
Der asynchrone WAL-Abruf verwaltet eine lokale Warteschlange mit WAL-Segmenten, die dekomprimiert und zur Wiedergabe bereit sind. Dies reduziert die Zeit, die für die Bereitstellung von WAL für PostgreSQL benötigt wird, was die Wiedergabegeschwindigkeit maximiert. Verbindungen und Speicher mit höherer Latenz (z. B. S3) profitieren am meisten.
Die Push- und Get-Befehle stellen beide sicher, dass die Datenbank und das Repository übereinstimmen, indem sie PostgreSQL-Versionen und Systemkennungen vergleichen. Dadurch wird die Möglichkeit einer Fehlkonfiguration des WAL-Archivspeicherorts praktisch ausgeschlossen.
Tablespaces werden vollständig unterstützt und können bei der Wiederherstellung einem beliebigen Speicherort neu zugeordnet werden. Es ist auch möglich, alle Tablespaces mit einem einzigen Befehl einem Speicherort zuzuordnen, was für Entwicklungswiederherstellungen nützlich ist.
Datei- und Verzeichnisverknüpfungen werden für jede Datei oder jedes Verzeichnis im PostgreSQL-Cluster unterstützt. Beim Wiederherstellen ist es möglich, alle Links an ihren ursprünglichen Speicherorten wiederherzustellen, einige oder alle Links neu zuzuordnen oder einige oder alle Links als normale Dateien oder Verzeichnisse im Clusterverzeichnis wiederherzustellen.
pgBackRest-Repositorys können in S3-, Azure- und GCS-kompatiblen Objektspeichern abgelegt werden, um praktisch unbegrenzte Kapazität und Aufbewahrung zu ermöglichen.
pgBackRest kann das Repository verschlüsseln, um Backups überall dort zu sichern, wo sie gespeichert sind.
pgBackRest bietet Unterstützung für zehn Versionen von PostgreSQL, die fünf unterstützten Versionen und die letzten fünf EOL-Versionen. Dadurch bleibt ausreichend Zeit für ein Upgrade auf eine unterstützte Version.
pgBackRest ist bestrebt, einfach zu konfigurieren und zu bedienen:
Benutzerhandbücher für verschiedene Betriebssysteme und PostgreSQL-Versionen.
Befehlsreferenz für Befehlszeilenoperationen.
Konfigurationsreferenz zum Erstellen von pgBackRest-Konfigurationen.
Die Dokumentation für Version 1 finden Sie hier. Für Version 1 sind keine weiteren Veröffentlichungen geplant, da Version 2 abwärtskompatibel mit den Optionen und Repositorys von Version 1 ist.
Beiträge zu pgBackRest sind immer willkommen! Einzelheiten dazu, wie Sie Funktionen, Verbesserungen oder Probleme beisteuern können, finden Sie in unseren Beitragsrichtlinien.
pgBackRest ist völlig kostenlos und Open Source unter der MIT-Lizenz. Sie können es ohne jegliche Einschränkungen für persönliche oder kommerzielle Zwecke nutzen. Fehlerberichte werden sehr ernst genommen und so schnell wie möglich behoben.
Die Erstellung einer robusten Disaster-Recovery-Richtlinie mit geeigneten Replikations- und Backup-Strategien kann eine sehr komplexe und entmutigende Aufgabe sein. Möglicherweise benötigen Sie während der Architekturphase Hilfe und fortlaufende Unterstützung, um sicherzustellen, dass Ihr Unternehmen weiterhin reibungslos läuft.
Crunchy Data bietet Paketversionen von pgBackRest für die wichtigsten Betriebssysteme und professionellen kommerziellen Support über den gesamten Lebenszyklus für pgBackRest und alles, was mit PostgreSQL zu tun hat. Crunchy Data ist bestrebt, Open-Source-Lösungen ohne Anbieterbindung bereitzustellen und sicherzustellen, dass die Kreuzkompatibilität mit der Community-Version von pgBackRest stets strikt gewahrt bleibt.
Weitere Informationen finden Sie unter Crunchy Data.
Die erste Anerkennung geht an Stephen Frost für all seine wertvollen Ratschläge und Kritik während der Entwicklung von pgBackRest.
Crunchy Data hat viel Zeit und Ressourcen in pgBackRest investiert und unterstützt die Entwicklung weiterhin aktiv. Resonate trug auch zur Entwicklung von pgBackRest bei und ermöglichte die Installation früherer (aber gut getesteter) Versionen als primäre PostgreSQL-Backup-Lösung.
Sesselgrafik von Sandor Szabo.
