pgBackRest sichert viele Postgres-Datenbanken mit Wiederherstellung auf jeden Zeitpunkt

Ein Team, das für mehrere Projekte jeweils eine eigene Postgres-Datenbank selbst betreibt, sichert diese Datenbanken oft über einen nächtlichen pg_dump, einen Exportbefehl, der den gesamten Inhalt zu einem festen Zeitpunkt in eine Datei schreibt. Das reicht, solange ein Fehler noch in derselben Nacht auffällt. Löscht eine fehlerhafte Migration um 14:32 Uhr versehentlich Zeilen ohne WHERE-Bedingung und bemerkt das Team den Fehler erst gegen 17 Uhr, hilft der nächtliche Dump nicht weiter: Er enthält entweder den Stand vor der Migration mit allen seither eingegangenen, jetzt wieder verlorenen Änderungen, oder gar keinen Stand aus diesem Zeitraum. pgBackRest schließt genau diese Lücke. Ein einmal eingerichteter Wiederherstellungspunkt lässt sich auf jede beliebige Sekunde zwischen zwei Sicherungen zurückspielen, nicht nur auf den Moment der letzten Sicherung selbst.

pgBackRest ist ein quelloffenes, aktiv gepflegtes Sicherungswerkzeug für PostgreSQL. Version 2.59.1 erschien am 17. August 2026, und das Projekt unterstützt laut eigener Dokumentation zehn PostgreSQL-Hauptversionen gleichzeitig: die fünf aktuell gepflegten sowie die fünf zuletzt ausgelaufenen. Anders als ein einzelner pg_dump-Befehl kombiniert pgBackRest drei Bausteine zu einer durchgehenden Sicherungskette: eine vollständige Basissicherung, ergänzende differenzielle oder inkrementelle Sicherungen, und eine ununterbrochene Archivierung der WAL-Dateien, also der Write-Ahead-Log-Segmente, in denen Postgres jede Datenänderung zuerst protokolliert, bevor sie in die eigentlichen Datendateien geschrieben wird.

Systemvoraussetzungen

Eine Installation braucht wenige, klar benannte Bausteine. Die folgende Tabelle listet sie mit den aktuellen Angaben aus der Konfigurationsreferenz und der Release-Historie des Projekts.

Komponente	Version oder Anforderung	Zweck
pgBackRest	Version 2.59.1 (17. August 2026, aktuelle stabile Version)	Führt Sicherung, Archivierung und Wiederherstellung aus
PostgreSQL	Eine der zehn von pgBackRest unterstützten Hauptversionen: die fünf aktuell gepflegten sowie die fünf zuletzt ausgelaufenen	Zu sichernde Datenbank-Instanz je Stanza
Einstellung archive_command	In postgresql.conf gesetzt auf pgbackrest --stanza=<name> archive-push %p, dazu archive_mode = on	Übergibt jedes WAL-Segment laufend an pgBackRest
S3-kompatibles Repository	Objektspeicher mit Endpoint, Bucket, Zugriffsschlüssel und Region, z. B. repo1-type=s3	Zentraler, gemeinsamer Speicherort für Basissicherungen und archivierte WAL-Segmente
Netzwerkzugriff	Ausgehende HTTPS-Verbindung vom Postgres-Server zum S3-Endpoint	Überträgt Sicherungen und WAL-Segmente zum Repository
Plattenplatz für pg_wal	Ausreichend Reserve auf dem Primärserver, unabhängig vom Repository-Speicher	Puffer, falls die Archivierung kurzzeitig stockt

Systemarchitektur

In einer Umgebung mit vielen selbstgehosteten Datenbanken bekommt jede Postgres-Instanz in pgBackRest eine eigene Stanza, den projekteigenen Begriff für die Konfigurationseinheit einer einzelnen Datenbank-Instanz: Pfad zum Datenverzeichnis, Archivierungsregeln und Aufbewahrungsdauer. Mehrere Stanzas teilen sich dabei ein gemeinsames Repository, den zentralen Speicherort für Sicherungen und archivierte WAL-Segmente.

flowchart TD
    A[Mehrere Postgres Instanzen als getrennte Stanzas] --> B[archive_command uebergibt jedes WAL Segment sofort]
    B --> C[Gemeinsames S3 kompatibles Repository]
    A --> D[Geplante Basissicherung voll differenziell oder inkrementell]
    D --> C
    C --> E[Aufbewahrungsregel loescht abgelaufene Vollsicherungen automatisch]
    C --> F[Restore Befehl waehlt Basissicherung und WAL Segmente]
    F --> G[Wiederherstellung bis zu einem exakten Zeitpunkt]
    B --> H[Check Befehl prueft Ankunft der WAL Segmente]
    H -->|Fehler erkannt| I[Warnung vor Volllaufen von pg_wal auf dem Primaerserver]

Der Ablauf beginnt bei PostgreSQL selbst: Die Einstellung archive_command ruft nach jedem vollgeschriebenen WAL-Segment automatisch pgbackrest archive-push auf und übergibt die Datei an das Repository. Parallel dazu läuft in festen Abständen eine Basissicherung, je nach Zeitplan als Vollsicherung, als differenzielle oder als inkrementelle Sicherung. Beim Wiederherstellen kombiniert der restore-Befehl die letzte passende Basissicherung mit den seither archivierten WAL-Segmenten und spielt sie bis zu einem gewählten Zeitpunkt vor, nicht zwingend bis zum aktuellen Rand des Protokolls. Der check-Befehl prüft dabei fortlaufend, ob die Archivierung tatsächlich ankommt, und deckt so genau die Lücke ab, die eine reine Dump-Strategie nie sichtbar macht.

Schritt-für-Schritt-Umsetzung

pgbackrest.conf für zwei Stanzas anlegen

Eine einzelne pgBackRest-Installation verwaltet beliebig viele Postgres-Instanzen aus einer gemeinsamen Konfigurationsdatei, üblicherweise unter /etc/pgbackrest/pgbackrest.conf. Ein [global]-Abschnitt trägt die Repository-Einstellungen, die für alle Stanzas gelten. Jede weitere Sektion benennt eine einzelne Datenbank-Instanz über ihren eigenen Namen und den Pfad zu ihrem Datenverzeichnis.

[global]
repo1-type=s3
repo1-s3-bucket=firma-postgres-backups
repo1-s3-endpoint=s3.eu-central-1.amazonaws.com
repo1-s3-region=eu-central-1
repo1-s3-key=AKIAEXAMPLEKEY123
repo1-s3-key-secret=BEISPIELWERT-NICHT-PRODUKTIV-VERWENDEN
repo1-path=/pgbackrest
repo1-retention-full=4
repo1-retention-full-type=count

[projekt-a]
pg1-path=/var/lib/postgresql/17/main
pg1-port=5432

[projekt-b]
pg1-path=/var/lib/postgresql/17/main
pg1-port=5433

Jede Stanza legt innerhalb desselben Repositorys ihren eigenen Namensraum für Sicherungen und WAL-Archiv an, sodass sich die Datenbanken von projekt-a und projekt-b niemals vermischen, obwohl beide auf denselben S3-Bucket zeigen. Eine weitere Datenbank bekommt jeweils nur einen zusätzlichen Konfigurationsabschnitt, keine eigene pgBackRest-Installation.

WAL-Archivierung in PostgreSQL aktivieren

Damit pgBackRest überhaupt WAL-Segmente bekommt, muss PostgreSQL sie aktiv an das Werkzeug übergeben. Vier Schritte reichen für eine neue Stanza.

1. Archivierung in postgresql.conf einschalten. Die Einstellungen archive_mode und archive_command aktivieren gemeinsam die Übergabe jedes fertigen WAL-Segments an pgBackRest.
2. PostgreSQL neu laden oder neu starten. Erst danach greifen die geänderten Einstellungen.
3. Stanza im Repository anlegen. Der Befehl stanza-create richtet die Verzeichnisstruktur für die neue Stanza im gemeinsamen Repository ein.
4. Konfiguration prüfen. Der Befehl check testet Repository-Zugriff und Archivierung gemeinsam und meldet Fehler, bevor die erste echte Sicherung läuft.

archive_mode = on
archive_command = 'pgbackrest --stanza=projekt-a archive-push %p'

sudo -u postgres pgbackrest --stanza=projekt-a --log-level-console=info stanza-create
sudo -u postgres pgbackrest --stanza=projekt-a --log-level-console=info check

%p ist ein Platzhalter, den PostgreSQL beim Aufruf durch den Pfad zur jeweils fertigen WAL-Datei ersetzt. Der check-Befehl bringt dabei selbst ein WAL-Segment zum Wechseln und kontrolliert dessen Ankunft im Repository. Damit deckt er genau den Fehlerfall ab, den eine reine Dump-Strategie nie sichtbar macht.

Sicherungen fahren und Aufbewahrung begrenzen

Die erste Sicherung einer Stanza ist immer eine Vollsicherung, pgBackRest kopiert dabei den gesamten Inhalt des Datenverzeichnisses. Danach reichen für den laufenden Betrieb schnellere inkrementelle Sicherungen, die nur die seit der letzten Sicherung veränderten Dateien kopieren.

sudo -u postgres pgbackrest --stanza=projekt-a --type=full backup
sudo -u postgres pgbackrest --stanza=projekt-a --type=incr backup

Die Einstellung repo1-retention-full=4 aus der Konfiguration oben hält vier Vollsicherungen je Stanza vor. Läuft eine fünfte Vollsicherung, verwirft pgBackRest automatisch die älteste der vier gespeicherten zusammen mit jeder differenziellen und inkrementellen Sicherung, die auf ihr aufbaut. Ohne gesetzten Wert für repo1-retention-full wächst das Repository dagegen unbegrenzt weiter, und pgBackRest gibt beim Sichern lediglich eine Warnung aus, keinen Fehler.

Auf einen exakten Zeitpunkt zurückspielen

Im eingangs beschriebenen Fall, der Migration mit der versehentlichen Löschung um 14:32 Uhr, reicht ein einzelner Befehl, um die Datenbank auf den Stand kurz davor zurückzuspielen.

sudo -u postgres pgbackrest --stanza=projekt-a --delta --type=time \
  --target="2026-08-25 14:31:59+02" --target-action=promote restore

--type=time mit --target gibt den gewünschten Zeitpunkt vor, wobei die Zeitzone im Zielwert stehen muss, damit pgBackRest sie korrekt gegen die in den WAL-Segmenten protokollierten Zeitstempel abgleicht. --target-action=promote öffnet die Datenbank nach der Wiederherstellung sofort für Schreibzugriffe, statt im Wiederherstellungsmodus zu verharren. --delta vergleicht vorhandene Dateien im Datenverzeichnis per Prüfsumme und kopiert nur, was sich geändert hat, was einen erneuten Restore auf demselben Server deutlich beschleunigt.

Häufige Fehlerquellen

• WAL-Archivierung schlägt lautlos fehl. PostgreSQL löscht ein WAL-Segment erst aus dem Verzeichnis pg_wal auf dem Primärserver, sobald archive_command es erfolgreich übergeben hat. Bei einem falsch konfigurierten Befehl sammeln sich die Segmente dort an und können den Plattenplatz des Datenbankservers selbst knapp werden lassen, unabhängig vom Speicher im Repository. Fix: Den check-Befehl regelmäßig automatisiert laufen lassen und den info-Befehl auswerten, der die minimale und maximale WAL-Position im Archiv anzeigt.
• Kein Wert für die Vollsicherungs-Aufbewahrung gesetzt. Ohne repo1-retention-full gibt pgBackRest beim Sichern nur eine Warnung aus, und das Repository wächst unbegrenzt weiter, weil keine Sicherung jemals abläuft. Fix: repo1-retention-full und repo1-retention-full-type von Anfang an explizit setzen.
• Zeitzone im Wiederherstellungsziel fehlt. Ein --target-Wert ohne Zeitzonenversatz kann pgBackRest auf einen anderen Zeitpunkt zurückspielen lassen als beabsichtigt, weil der Wert gegen die von PostgreSQL geführten Zeitstempel abgeglichen wird. Fix: Immer die vollständige Zeitzone im --target-Wert angeben.
• Zugriffsschlüssel für das S3-Repository abgelaufen oder falsch berechtigt. archive-push schlägt dann für jedes neue WAL-Segment fehl, und der Fehler zeigt sich zuerst in den PostgreSQL-Logs, nicht in einer aktiven Warnmeldung. Fix: Einen neuen Zugriffsschlüssel vor dem produktiven Einsatz mit dem check-Befehl testen und Schlüsselrotation fest einplanen.
• Stanza-Name oder Datenverzeichnis-Pfad falsch zugeordnet. Stimmt pg1-path nicht exakt mit dem von PostgreSQL gemeldeten Datenverzeichnis überein, schlägt stanza-create fehl oder eine Sicherung erfasst das falsche Verzeichnis. Fix: Den Pfad direkt aus der laufenden Datenbank abfragen, statt ihn aus der Erinnerung einzutippen.

Häufig gestellte Fragen

Was unterscheidet eine Vollsicherung von einer differenziellen und einer inkrementellen Sicherung in pgBackRest?

Eine Vollsicherung kopiert bei pgBackRest den gesamten Inhalt des Postgres-Datenverzeichnisses und bildet damit die erste Sicherung jeder Stanza. Eine differenzielle Sicherung kopiert danach nur noch die Dateien, die sich seit der letzten Vollsicherung verändert haben, während eine inkrementelle Sicherung nur die Änderungen seit der jeweils letzten Sicherung erfasst, ganz gleich ob diese selbst voll, differenziell oder inkrementell war. Für den laufenden Betrieb reichen inkrementelle Sicherungen meist aus, weil sie am wenigsten Speicherplatz und Zeit brauchen.

Wie stellt pgBackRest eine Postgres-Datenbank auf einen exakten Zeitpunkt statt auf den letzten Sicherungsstand wieder her?

pgBackRest stellt eine Datenbank auf einen exakten Zeitpunkt wieder her, indem der restore-Befehl mit --type=time und einem --target-Zeitstempel die letzte passende Basissicherung einspielt und anschließend die seither archivierten WAL-Segmente bis genau zu diesem Zeitpunkt abspielt. Die Kombination aus Basissicherung und fortlaufendem WAL-Archiv erlaubt eine Wiederherstellung auf jede beliebige Sekunde zwischen zwei Sicherungen, nicht nur auf den Moment der letzten Sicherung selbst. Der Zeitstempel im --target-Wert braucht dafür eine Zeitzone, damit pgBackRest ihn korrekt gegen die von PostgreSQL geführten Protokollzeiten abgleicht.

Was passiert, wenn die WAL-Archivierung bei pgBackRest über längere Zeit ausfällt?

Fällt die WAL-Archivierung bei pgBackRest über längere Zeit aus, etwa wegen eines falsch konfigurierten archive_command oder eines abgelaufenen Zugriffsschlüssels für das Repository, löscht PostgreSQL die betroffenen WAL-Segmente nicht mehr aus dem Verzeichnis pg_wal auf dem Primärserver, weil es sie laut Projektdokumentation erst nach erfolgreicher Übergabe freigibt. Sammeln sich dort genug Segmente an, kann der Plattenplatz auf dem Datenbankserver selbst knapp werden, unabhängig vom Speicherplatz im Repository. Der check-Befehl und der info-Befehl mit seiner Anzeige der minimalen und maximalen WAL-Position im Archiv zeigen einen solchen Rückstand frühzeitig an, bevor er zum echten Problem wird.

Kann eine einzige pgBackRest-Installation mehrere getrennte Postgres-Datenbanken gegen ein gemeinsames Repository sichern?

Eine einzige pgBackRest-Installation kann mehrere getrennte Postgres-Datenbanken gegen ein gemeinsames Repository sichern, indem jede Datenbank-Instanz als eigene Stanza in derselben pgbackrest.conf angelegt wird. Die Repository-Einstellungen stehen dabei einmalig im [global]-Abschnitt, während jede Stanza nur ihren eigenen Namen und den Pfad zu ihrem Datenverzeichnis mitbringt. Im Repository selbst bleiben die Sicherungen und WAL-Archive der einzelnen Stanzas getrennt, sodass sich eine zusätzliche Datenbank ohne weitere Softwareinstallation anschließen lässt.