pgBackRest
Zuverlässige PostgreSQL-Sicherung & Wiederherstellung

Einführung

pgBackRest ist eine zuverlässige Backup- und Wiederherstellungslösung für PostgreSQL, die nahtlos bis zu den größten Datenbanken und Workloads skaliert.

pgBackRest v2.59.2 ist die aktuelle stabile Version. Versionshinweise finden Sie auf der Seite Releases.

Bitte geben Sie uns einen Stern auf GitHub, wenn Ihnen pgBackRest gefällt!

Neuigkeiten

27. September 2026 - pgBackRest 2.59.2 veröffentlicht

17. August 2026 - pgBackRest 2.59.1 veröffentlicht

20. Juli 2026 - Neues Distributions-Tarball

Funktionen

Parallele Sicherung & Wiederherstellung

Die Komprimierung ist normalerweise der Engpass bei Sicherungsvorgängen, daher löst pgBackRest dieses Problem mit paralleler Verarbeitung und effizienteren Komprimierungsalgorithmen wie lz4 und zstd.

Lokaler oder Remote-Betrieb

Ein benutzerdefiniertes Protokoll ermöglicht es pgBackRest, lokal oder remote über TLS/SSH mit minimaler Konfiguration zu sichern, wiederherzustellen und zu archivieren. Eine Schnittstelle zur Abfrage von PostgreSQL wird ebenfalls über die Protokollschicht bereitgestellt, sodass ein Remote-Zugriff auf PostgreSQL nie erforderlich ist, was die Sicherheit erhöht.

Mehrere Repositories

Mehrere Repositories ermöglichen beispielsweise ein lokales Repository mit minimaler Aufbewahrungsdauer für schnelle Wiederherstellungen und ein Remote-Repository mit längerer Aufbewahrungsdauer für Redundanz und unternehmensweiten Zugriff.

Vollständige, differenzielle und inkrementelle Sicherungen (auf Datei- oder Blockebene)

Vollständige, differenzielle und inkrementelle Sicherungen werden unterstützt. pgBackRest ist nicht anfällig für die Zeitauflösungsprobleme von rsync, wodurch differenzielle und inkrementelle Sicherungen sicher sind, ohne dass jede Datei mit einer Prüfsumme versehen werden muss. Sicherungen auf Blockebene sparen Speicherplatz, indem nur die geänderten Teile von Dateien kopiert werden.

Sicherungsrotation & Archivablauf

Aufbewahrungsrichtlinien können für vollständige und differenzielle Sicherungen festgelegt werden, um Abdeckung für jeden Zeitraum zu schaffen. Das WAL-Archiv kann für alle Sicherungen oder streng für die neuesten Sicherungen aufrechterhalten werden. Im letzteren Fall wird WAL, das benötigt wird, um ältere Sicherungen konsistent zu machen, im Archiv aufbewahrt.

Sicherungsintegrität

Für jede Datei in der Sicherung werden Prüfsummen berechnet und während einer Wiederherstellung oder Überprüfung erneut geprüft. Nachdem eine Sicherung das Kopieren von Dateien abgeschlossen hat, wartet sie, bis jedes WAL-Segment, das benötigt wird, um die Sicherung 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, eine Sicherung im Repository zu snapshotten und einen PostgreSQL-Cluster direkt auf dem Snapshot hochzufahren. Dies ist vorteilhaft für Datenbanken im Terabyte-Maßstab, deren Wiederherstellung auf traditionelle Weise zeitaufwändig ist.

Alle Vorgänge nutzen fsync auf Datei- und Verzeichnisebene, um die Dauerhaftigkeit zu gewährleisten.

Seitenprüfsummen

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 Sicherungsprozess nicht, aber Warnungen mit Details darüber, welche Seiten die Validierung nicht bestanden haben, werden an die Konsole und das Dateiprotokoll ausgegeben.

Diese Funktion ermöglicht es, Korruption auf Seitenebene frühzeitig zu erkennen, bevor Sicherungen, die gültige Kopien der Daten enthalten, ablaufen.

Sicherung fortsetzen

Eine unterbrochene Sicherung kann ab dem Punkt fortgesetzt werden, an dem sie gestoppt wurde. Dateien, die bereits kopiert wurden, werden mit den Prüfsummen im Manifest verglichen, um die Integrität zu gewährleisten. Da dieser Vorgang vollständig auf dem Repository-Host stattfinden kann, reduziert er die Last auf dem PostgreSQL-Host und spart Zeit, da die Prüfsummenberechnung schneller ist als das Komprimieren und erneute Übertragen von Daten.

Streaming-Komprimierung & Prüfsummen

Komprimierung 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 die 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 minimal zu halten.

Delta-Wiederherstellung

Das Manifest enthält Prüfsummen für jede Datei in der Sicherung, sodass während einer Wiederherstellung diese Prüfsummen verwendet werden können, um die Verarbeitung enorm zu beschleunigen. Bei einer Delta-Wiederherstellung werden alle Dateien, die nicht in der Sicherung vorhanden sind, zuerst entfernt und dann werden Prüfsummen für die verbleibenden Dateien generiert. Dateien, die mit der Sicherung übereinstimmen, bleiben an Ort und Stelle und der Rest der Dateien wird wie gewohnt wiederhergestellt. Die parallele Verarbeitung kann zu einer dramatischen Reduzierung der Wiederherstellungszeiten führen.

Paralleles, asynchrones WAL-Push & -Get

Es sind dedizierte Befehle zum Pushen von WAL in das Archiv und zum Abrufen von WAL aus dem Archiv enthalten. Beide Befehle unterstützen Parallelität zur Beschleunigung der Verarbeitung und laufen asynchron, um die schnellstmögliche Antwortzeit für PostgreSQL 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. Asynchrones WAL-Push ermöglicht es, die Übertragung an einen anderen Prozess auszulagern, der WAL-Segmente parallel für maximalen Durchsatz komprimiert. Dies kann eine kritische Funktion für Datenbanken mit extrem hohem Schreibvolumen sein.

Asynchrones WAL-Get unterhält eine lokale Warteschlange von WAL-Segmenten, die dekomprimiert und bereit für die Wiedergabe sind. Dies reduziert die Zeit, die benötigt wird, um WAL an PostgreSQL zu liefern, was die Wiedergabegeschwindigkeit maximiert. Verbindungen und Speicher mit höherer Latenz (wie S3) profitieren am meisten.

Die Befehle push und get stellen beide sicher, dass Datenbank und Repository übereinstimmen, indem sie PostgreSQL-Versionen und Systembezeichner vergleichen. Dies schließt die Möglichkeit einer Fehlkonfiguration des WAL-Archivspeicherorts praktisch aus.

Tablespace- & Link-Unterstützung

Tablespaces werden vollständig unterstützt und bei der Wiederherstellung können Tablespaces an jeden beliebigen Ort neu zugeordnet werden. Es ist auch möglich, alle Tablespaces mit einem einzigen Befehl einem einzigen Ort zuzuordnen, was für Entwicklungs-Wiederherstellungen nützlich ist.