PostgreSQL 18 Backup: Datenbanken sind für zahlreiche Unternehmensanwendungen der zentrale Zustandsspeicher. Wenn ein Administrator versehentlich Datensätze löscht, ein Schema-Update scheitert oder ein Storage-System beschädigt wird, zählt nicht nur das Vorhandensein einer Sicherungsdatei. Entscheidend ist, wie weit sich der letzte konsistente Datenstand wiederherstellen lässt und ob die Anwendung danach fachlich korrekt funktioniert. PostgreSQL 18 Backup bietet in Kombination mit Base Backups und Write-Ahead Log (WAL) die Grundlage für Point-in-Time-Recovery (PITR). Der Leitfaden erklärt, wie Sie vollständige und inkrementelle Backups, WAL-Archivierung, Verifikation und echte Restore-Tests zu einem kontrollierten Betriebsprozess verbinden.
GORTNET Fachredaktion · Stand: 28. Oktober 2026
Backupstrategie vor der Auswahl des Werkzeugs
Die wichtigste Frage lautet nicht, welches Tool am schnellsten eine Sicherung erstellt, sondern welche Geschäftsprozesse geschützt werden sollen. Definieren Sie ein Recovery Point Objective (RPO) für maximal tolerierbaren Datenverlust und ein Recovery Time Objective (RTO) für die Wiederanlaufzeit. Eine Testdatenbank benötigt eventuell nur tägliche Sicherung; bei zentralen Bestell- oder Buchungssystemen können sehr viel engmaschigere Ziele notwendig sein.
Erfassen Sie Datenbankgröße, tägliche Änderungsrate, Transaktionsvolumen, externe Abhängigkeiten und Anforderungen an die Aufbewahrung. Eine gut geplante PostgreSQL-Sicherung berücksichtigt die Infrastruktur der gesamten Anwendung. Selbst eine erfolgreich wiederhergestellte Datenbank hilft wenig, wenn notwendige Konfigurationsdateien, Zertifikate, Secrets oder Anwendungsversionen fehlen. Führen Sie diese Bestandteile deshalb im Recovery-Runbook auf.
PostgreSQL 18 Backup: Physische und logische Sicherung
PostgreSQL unterstützt logische Backups über Werkzeuge wie pg_dump und pg_dumpall. Sie sind nützlich für bestimmte Migrations- oder Objektwiederherstellungsfälle. Für eine kontinuierliche Wiederherstellung über WAL-Dateien reichen logische Dumps allein jedoch nicht aus. PITR nutzt einen physischen Base Backup und die dazugehörigen WAL-Informationen; die Formate erfüllen unterschiedliche Aufgaben.
Ein physisches Backup kopiert den Zustand des Datenbankclusters in einem dafür vorgesehenen konsistenten Verfahren. Es kann für einen vollständigen Cluster-Restore oder als Ausgangspunkt eines Standby-Systems dienen. Beachten Sie, dass ein Cluster-Backup nicht automatisch einzelne Tabellen wie ein logischer Export zurückspielt. Für besonders kritische Anwendungen kann daher eine Kombination aus physischen Backups und gezielten logischen Exporten sinnvoll sein.
Wie das Write-Ahead Log funktioniert
PostgreSQL schreibt Änderungen über das Write-Ahead Log, bevor die zugehörigen Datenblöcke dauerhaft verarbeitet werden. Dieses Verfahren unterstützt die Konsistenz nach einem Absturz. Wird WAL zusätzlich archiviert, können Änderungen nach einem Base Backup für die Wiederherstellung erneut eingespielt werden. Damit ist es möglich, den Zustand des Clusters zu einem ausgewählten früheren Zeitpunkt zu rekonstruieren.
Entscheidend ist die lückenlose Verfügbarkeit der benötigten WAL-Segmente. Eine einzige fehlende Datei kann den geplanten Recovery-Zielzeitpunkt unerreichbar machen. Überwachen Sie daher nicht nur den letzten Base-Backup-Job, sondern den kontinuierlichen WAL-Archivierungsprozess. Ein grüner Backupstatus ist wertlos, wenn seit mehreren Tagen keine WAL-Dateien mehr sicher übertragen werden.
WAL-Archivierung korrekt einrichten
Die offiziellen PostgreSQL-Unterlagen erläutern die erforderlichen Konfigurationen für WAL-Archivierung und kontinuierliche Wiederherstellung. Je nach eingesetzter Architektur können archive_mode und ein geeignetes Archivierungsverfahren relevant sein. Nutzen Sie für die Übertragung ein zuverlässiges, gesichertes Ziel und dokumentieren Sie Fehlerbehandlung, Wiederholversuche und die Kapazität des Archivspeichers.
Testen Sie die Archivierung vor dem ersten produktiven Base Backup. Prüfen Sie, ob WAL-Dateien nach Rotation tatsächlich im vorgesehenen Speicherort ankommen. Erstellen Sie Alarme für ausbleibende Archivierung, wachsende lokale WAL-Verzeichnisse und unzureichenden freien Speicherplatz. Eine falsch konfigurierte Archivierung kann die Produktionspartition unter Last füllen und dadurch einen zusätzlichen Ausfall erzeugen.
pg_basebackup für vollständige Backups nutzen
Das Werkzeug pg_basebackup kann einen laufenden PostgreSQL-Cluster physisch sichern, ohne sämtliche Clients grundsätzlich vom Datenbankdienst auszuschließen. Bei einem vollständigen Base Backup werden die erforderlichen Clusterdateien erfasst. Die Konfiguration benötigt passende Verbindungsrechte, ausreichend Speicherkapazität und einen sicheren Zielort. Für größere Systeme müssen Sie Netzwerkbandbreite und Einfluss auf die I/O-Leistung berücksichtigen.
Erstellen Sie einen nachvollziehbaren Zeitplan für vollständige Sicherungen und kontrollieren Sie, ob das Archiv konsistent mit der verwendeten Datenbankversion ist. Ein Backup sollte eine eindeutige Kennung, den Start- und Endzeitpunkt und einen dokumentierten Speicherort erhalten. Vermeiden Sie allgemeine Shared Accounts ohne begrenzte Rechte. Auch der Backupdienst muss überwacht und gegen unberechtigte Änderungen geschützt werden.
Inkrementelle Base Backups in PostgreSQL 18
Die aktuelle Dokumentation zu pg_basebackup beschreibt neben vollständigen auch inkrementelle Base Backups. Bei inkrementellen Sicherungen werden gegenüber einer Referenzbasis veränderte Datenblöcke in einem unterstützten Verfahren berücksichtigt. Der Vorteil kann eine Verringerung des übertragenen Datenvolumens sein. Allerdings entsteht eine Abhängigkeit zwischen mehreren Backupstufen, die für die Wiederherstellung korrekt behandelt werden muss.
Ein inkrementelles Backup kann nicht ohne zusätzliche Vorbereitung direkt wie ein vollständiger physischer Cluster gestartet werden. Die PostgreSQL-Dokumentation nennt pg_combinebackup, um die benötigte Backupkette zu einem verwendbaren Zustand zusammenzuführen. Prüfen Sie vor dem Einsatz die genaue Versionskompatibilität, die notwendigen Manifeste und den Speicherbedarf. Ein günstigerer Backupjob ist nur dann eine Verbesserung, wenn der vollständige Restore im vereinbarten Zeitfenster funktioniert.
PITR: Auf einen bestimmten Zeitpunkt zurückkehren
Point-in-Time-Recovery ermöglicht die Wiederherstellung eines Clusterzustands zu einem definierten Zeitpunkt innerhalb der verfügbaren Backup- und WAL-Historie. Das ist beispielsweise nützlich, wenn eine fehlerhafte Datenänderung nicht sofort bemerkt wird. Anders als bei einem reinen Tagesbackup lässt sich unter geeigneten Voraussetzungen ein Zeitpunkt vor dem Problem wählen und so ein Teil des Datenverlusts begrenzen.
Der Zeitpunkt muss sorgfältig gewählt werden. Berücksichtigen Sie Zeitzonen, Anwendungslogs und den tatsächlichen Beginn der fehlerhaften Transaktion. Führen Sie den Restore zunächst in einer isolierten Umgebung durch und vergleichen Sie die Daten mit fachlichen Erwartungen. Eine unkontrollierte Rücksetzung des Produktivsystems kann wiederum legitime spätere Transaktionen entfernen. Ein dokumentierter Entscheidungs- und Freigabeprozess gehört daher zum Recovery.
pg_verifybackup: Integritätsprüfung mit Grenzen
Das Werkzeug pg_verifybackup überprüft anhand eines Backup-Manifests verschiedene Eigenschaften eines physischen Backups. Dazu gehören vorhandene Dateien und Checksummen. Unter geeigneten Voraussetzungen können auch erforderliche WAL-Informationen überprüft werden; bei bestimmten Tar-Formaten gelten Einschränkungen, die in der PostgreSQL-Dokumentation ausdrücklich beschrieben werden.
Ein erfolgreiches pg_verifybackup beweist nicht, dass jede Anwendung nach einem Restore korrekt arbeitet. PostgreSQL warnt selbst vor den Grenzen dieser Prüfung und empfiehlt echte Wiederherstellungstests. Verbinden Sie daher technische Verifikation mit dem Start eines Testclusters, einfachen Datenbankabfragen und der fachlichen Abnahme. Verifikation reduziert Risiken, ersetzt aber nicht das eigentliche Recovery-Training.
Replikation ist kein Backup
Streaming Replication und Standby-Server können die Verfügbarkeit erhöhen und den Wiederanlauf nach Hardwareausfällen erleichtern. Sie sind jedoch kein Ersatz für eine historische Sicherung. Eine versehentliche Löschung oder eine schädliche Änderung kann durch Replikation auf den Standby gelangen. Auch ein privilegierter Angreifer kann mehrere online erreichbare Systeme gleichzeitig beeinflussen.
Kombinieren Sie Hochverfügbarkeit mit ausreichend lange aufbewahrten, voneinander unabhängig geschützten Backupständen. Definieren Sie, welcher Failover-Prozess auf einen Ausfall reagiert und wann stattdessen ein historischer Restore nötig ist. Diese Entscheidungen unterscheiden sich in Bezug auf Datenverlust, Wiederanlaufdauer und technische Komplexität. Dokumentieren Sie sie in getrennten Runbooks.
Verschlüsselung, Rechte und Offsite-Kopien
Backup-Dateien enthalten häufig die sensibelsten Daten eines Unternehmens. Speichern Sie sie verschlüsselt und vergeben Sie minimale Rechte an Backup- und Restore-Konten. Stellen Sie sicher, dass Schlüssel und Zugangsdaten auch im Desaster verfügbar, aber nicht frei zugänglich sind. Prüfen Sie, wer Sicherungen löschen, Retention verändern oder ältere Versionen überschreiben darf.
Eine unabhängige Offsite-Kopie reduziert das Risiko standortweiter Ausfälle. Zusätzliche unveränderliche oder offline verwahrte Kopien können gegen bestimmte Ransomware-Szenarien helfen. Entscheidend ist die tatsächliche administrative Trennung: Wenn dieselben kompromittierten Zugangsdaten Produktion und Backup ohne weitere Hürden löschen können, reicht der zweite Speicherort allein nicht aus. Führen Sie regelmäßige Kontrollen der Berechtigungen und Wiederherstellbarkeit durch.
Restore-Tests mit echter Applikationsabnahme
Ein belastbarer Test beginnt mit einem klaren Szenario: Beispielsweise wird eine Testtabelle absichtlich verändert und anschließend auf einen Zeitstempel vor der Änderung zurückgesetzt. Der Datenbankadministrator baut den Cluster isoliert auf, prüft Verbindungen und dokumentiert die verwendeten Base Backups und WAL-Dateien. Erst danach wird die Anwendung gegen den wiederhergestellten Datenbestand getestet.
Erfassen Sie das tatsächliche RTO, mögliche Datenlücken und Konfigurationsabweichungen. Testen Sie außerdem einen vollständigen Neuaufbau auf anderer Infrastruktur, nicht nur das Zurückspielen einzelner Daten in ein bereits funktionierendes Testsystem. Prüfen Sie Integrationszugänge und notwendige Hintergrundjobs, denn ein technisch erreichbarer Datenbankport beweist keine vollständige Wiederherstellung der Geschäftsprozesse.
Monitoring von PostgreSQL und Backup-Pipeline
Überwachen Sie Datenbankerreichbarkeit, Storage-Auslastung, WAL-Generierung, Archivierungsfehler, Replikationsverzögerung und die Dauer von Backupjobs. Bei wachsendem Datenbestand verändern sich die Anforderungen an Sicherungsfenster und Speichervolumen. Ein kleiner Pilotbackup kann nach einigen Monaten deutlich länger dauern, wenn die Anzahl der Transaktionen steigt.
Erstellen Sie unterschiedliche Warnstufen und eine klare Eskalation. Kritisch ist etwa der Ausfall der WAL-Archivierung, auch wenn die letzte vollständige Sicherung erfolgreich war. Legen Sie fest, wer bei unzureichendem Speicher oder ausbleibenden Sicherungen reagiert. Ein Monitoring-Eintrag ohne definierten Verantwortlichen verhindert keinen Datenverlust. Die Schutzmaßnahmen müssen in das reguläre Incident- und Change-Management eingebettet werden.
30-Tage-Plan für PostgreSQL 18 Backup
Woche eins: Datenbankinventar, RPO, RTO und bisherige Backups dokumentieren. Woche zwei: Physische Base Backups und WAL-Archivierung für einen Pilotcluster einrichten und Verifikation testen. Woche drei: einen Point-in-Time-Restore durchführen und die Anwendung fachlich abnehmen lassen. Woche vier: Offsite-Speicherung, Zugriffsrechte, Alarme und wiederkehrende Recovery-Übungen definieren.
Schließen Sie die Einführung erst ab, wenn eine vollständige Dokumentation des Restorewegs existiert und eine andere qualifizierte Person sie nachvollziehen kann. Prüfen Sie nach PostgreSQL-Upgrades oder Änderungen an der Backupsoftware die Kompatibilität und wiederholen Sie den Test. Eine Backupstrategie ist erst dann belastbar, wenn sie auch ohne den ursprünglichen Einrichter funktioniert.
FAQ zu PostgreSQL 18 Backup
Reicht pg_dump für vollständiges PITR?
Nein. PITR benötigt geeignete physische Sicherungen und eine durchgehende WAL-Historie.
Kann ein inkrementelles pg_basebackup direkt gestartet werden?
Nicht ohne Weiteres; die dokumentierte Backupkette muss beispielsweise mit pg_combinebackup vorbereitet werden.
Ersetzt ein Replikat die Datensicherung?
Nein. Replikation kann auch versehentliche Löschungen und schädliche Änderungen übertragen.
Reicht pg_verifybackup als Nachweis?
Nein. Es erkennt bestimmte Sicherungsfehler, ersetzt aber keine echten Restore- und Anwendungstests.
Fazit: Restore-Fähigkeit entscheidet
Eine gute Strategie für PostgreSQL 18 Backup verbindet RPO/RTO, physische Base Backups, zuverlässige WAL-Archivierung, unabhängige Kopien und regelmäßig getestete Point-in-Time-Recovery. Messen Sie die tatsächliche Wiederherstellungsdauer und lassen Sie den Datenbestand fachlich prüfen. Ein erfolgreicher Backupjob allein beweist noch keine betriebliche Resilienz.
Weiterführende GORTNET-Inhalte
Für eine belastbare Backup- und Restore-Strategie GORTNET kontaktieren.
Offizielle Dokumentation
- PostgreSQL 18: pg_basebackup
- PostgreSQL 18: pg_verifybackup
- PostgreSQL: Continuous Archiving and PITR
- PostgreSQL 18: Server Administration
Beispiele vor Produktivänderungen anhand der konkreten PostgreSQL-Version, Speicherarchitektur und Anwendung testen.