Step-by-Step: PostgreSQL Point-in-Time-Recovery (PITR) bei Produktivdatenbanken durchführen

PostgreSQL Point-in-Time-Recovery (PITR) ist die Fähigkeit, eine physische Datenbankinstanz auf einen genau definierten Zeitpunkt in der Vergangenheit zurückzusetzen. Für Betreiber produktiver Installationen ist PITR oft der einzige Weg, um fehlerhafte Transaktionen, versehentliche Löschungen oder Ransomware‑Schäden zielgenau rückgängig zu machen. Dieser Leitfaden erweitert die Grundlagen um erprobte Prüfschritte, Timeline‑Wechsel, Integritätsprüfungen, Automatisierungsbeispiele und konkrete Troubleshooting‑Schritte, damit Sie in realen Notfällen sicher handeln können.

Kurzüberblick: Was ist PITR und wie funktioniert es?

PITR kombiniert zwei physische Bestandteile von PostgreSQL: Base Backups (konsistente Schnappschüsse des Datenverzeichnisses PGDATA) und Write‑Ahead‑Logs (WAL), die jede Datenänderung sequenziell dokumentieren. Für eine erfolgreiche Wiederherstellung benötigen Sie ein Base Backup und alle WAL‑Segmente bis zum gewünschten Zeitpunkt. Fehlt ein WAL‑Segment, ist die Wiederherstellung bis zu diesem Punkt nicht möglich und Sie müssen auf einen früheren Zeitpunkt ausweichen oder fehlende Archive aus sekundären Repositorien beschaffen.

Wann ist PITR die richtige Methode?

PITR ist die passende Methode, wenn Sie Änderungen bis zu einem exakten Zeitpunkt rückgängig machen wollen, nicht dagegen, wenn Sie einzelne Tabellen selektiv rekonstruieren müssen (für diese Fälle sind logische Backups wie pg_dump oder Logical Replication geeigneter). Typische Einsatzfälle:

• Fehlerhafte Massenupdates / unbeabsichtigtes Löschen großer Datenmengen.
• Forensische Analyse: Zustand der DB zu einem bestimmten Zeitstempel rekonstruieren.
• Teilweise Datenkorruption, wo nur ein enger Zeitbereich betroffen ist.
• Ransomware-Szenarien, wenn Sie einen sauberen Zustand vor dem Befall wiederherstellen wollen.

Grundvoraussetzungen und Architektur

Vor einem PITR müssen diese Voraussetzungen zuverlässig erfüllt sein:

• Aktives WAL‑Archiving (archive_mode = on) und ein getestetes archive_command.
• Regelmäßige, konsistente Base Backups (z. B. mit pg_basebackup oder konsistenten Storage‑Snapshots).
• Ein verlässliches Archivziel mit Redundanz (lokaler Archivpfad, NFS oder Objekt‑Store wie S3) und abgesicherten Zugriffsrechten.
• Dokumentation: Zuordnung von Base Backup Zeitstempel, WAL‑Ranges und Timeline‑IDs.

Prüfen Sie Konfiguration schnell mit psql:

psql -At -c "SHOW archive_mode; SHOW wal_level; SHOW archive_command; SHOW archive_timeout;"

Wichtige Parameter kurz erklärt

In einem Satz:

• archive_mode: Schaltet WAL‑Archivierung ein.
• archive_command: Shell‑Befehl/Script, das WAL‑Segmente ins Archiv überträgt.
• wal_level: Muss mindestens replica sein, damit vollständige WAL‑Daten für PITR verfügbar sind.
• archive_timeout: Erzwingt periodisches Archivieren auch bei niedriger Aktivität.

PostgreSQL Point-in-Time-Recovery (PITR): Timeline, WAL‑Retention und Betrieb

In produktiven Umgebungen treten zwei besonders kritische operationalle Aspekte auf: Timeline‑Wechsel und WAL‑Retention. Timeline‑IDs entstehen bei Promotionen oder Failovers; WAL‑Filenames und Backup‑Labels enthalten diese. Wenn ein Timeline‑Sprung stattgefunden hat, müssen WALs der richtigen Timeline verfügbar sein, sonst stoppt das Replay.

# Timeline-Infos aus dem Base Backup / control
psql -c "SELECT timeline_id, last_wal_replay_lsn() FROM pg_control_checkpoint();"
# Timeline-History Dateien im Archiv prüfen
ls -1 /srv/pg_wal_archive/*.history

Planen Sie WAL‑Retention so, dass Ihr Recovery‑Window (RPO) abgedeckt ist. Für S3/Objekt‑Store empfiehlt sich eine Lifecycle‑Policy, die WALs mindestens so lange aufbewahrt, wie Ihr größtes geplantes Recovery‑Fenster.

Step‑by‑Step: PITR durchführen (erweiterte Ablaufbeschreibung)

Die folgenden Schritte bauen auf dem Basisablauf auf, erweitern ihn um Prüfungen und Verifikationen, und geben konkrete Handlungsempfehlungen:

1) Planung, Isolierung und Kommunikation

Wählen Sie Recovery‑Zeitpunkt und informieren Sie Stakeholder. Bereiten Sie einen isolierten Recovery‑Host oder eine Kopie des PGDATA vor; überschreiben Sie niemals das produktive PGDATA direkt. Definieren Sie eine Rückfallbedingung im Runbook: z. B. Abbruch, wenn WALs fehlen oder Checksummenfehler auftreten.

2) Base Backup identifizieren und integritätsgeprüft bereitstellen

Prüfen Sie das Base Backup auf Vollständigkeit und Integrität. Falls Sie Tar‑Backups nutzen, prüfen Sie backup_label, Manifest und optional gespeicherte Checksummen.

mkdir -p /recovery/pgdata
cd /recovery/pgdata
tar -xzf /backups/basebackup_2026-07-26.tar.gz
cat /recovery/pgdata/backup_label
# Optional: Prüfen einer manifest-Datei mit SHA256-Hashes
sha256sum -c /backups/basebackup_2026-07-26.manifest

3) restore_command gründlich testen

Fehlerhafte restore_command‑Skripte sind eine der häufigsten Ursachen für fehlschlagende Recoveries. Testen Sie die gesamte Kette manuell als postgres-User, inklusive Netzwerk‑Credentials, SELinux/AppArmor‑Kontexte und Pfad zu aws/gsutil.

# Beispiel: S3-Objekt abrufen und auf Lesbarkeit prüfen
sudo -u postgres bash -c "aws s3 cp s3://my-pg-wal-archive/0000000100000000000000A0 /tmp/test_wal.gz && gunzip -c /tmp/test_wal.gz > /tmp/test_wal && file /tmp/test_wal"
# Prüfen auf Exit-Code
if [ $? -ne 0 ]; then echo 'restore_command failed'; fi

4) Recovery‑Parameter setzen und Timeline‑Regeln prüfen

Für PostgreSQL 12+ setzen Sie die Recovery‑Parameter in postgresql.conf oder in einer separaten recovery.conf‑ähnlichen Konfiguration. Achten Sie auf recovery_target_time, recovery_target_lsn und recovery_target_timeline. recovery_target_timeline steuert, ob bei vorhandenem Timeline‑Branch der neueste Branch verwendet werden soll (latest) oder nur die aktuelle Timeline (current), oder eine explizite Timeline‑ID.

# Beispielkonfiguration
restore_command = '/usr/local/bin/restore_wal_from_s3.sh %f %p'
recovery_target_time = '2026-07-27 14:12:03+00'
recovery_target_timeline = 'latest'
recovery_target_action = 'promote'

5) Start, Monitoring und WAL‑Replay‑Analyse

Starten Sie die Recovery mit einer recovery.signal (PG12+) im Recovery‑PGDATA. Überwachen Sie Logs und Replay‑LSN. Verwenden Sie pg_waldump, um WAL‑Inhalte vorab zu analysieren, falls Sie Unregelmäßigkeiten vermuten (z. B. plötzliches Ende eines Segments):

# WAL-Inhalt prüfen
pg_waldump -f /srv/pg_wal_archive/0000000100000000000000A0 | head -n 50
# Replay-Status prüfen
psql -c "SELECT pg_is_in_recovery(), pg_last_wal_replay_lsn(), pg_last_wal_replay_timestamp();"

Wird das Replay an einer bestimmten WAL‑Datei gestoppt, prüfen Sie diese Datei auf Korruption und vergleichen Sie ggf. mit einer alternativen Kopie (z. B. sekundäres Archiv oder andere Region).

6) Promotion und Validierung

Nach Erreichen des Zielzeitpunkts führen Sie Promotion oder Shutdown gemäß Runbook durch. Validieren Sie mit stichprobenhaften Geschäftsabfragen, Row‑Counts und Index‑Checks. Erstellen Sie anschließend ein neues Base Backup, um die Recovery‑Kette sauber zu schließen.

Fehleranalyse: häufige Probleme und konkrete Gegenmaßnahmen

• Fehlende WALs: Prüfen Sie andere Archivziele, Replikate oder Backups. Falls nicht vorhanden, reduzieren Sie den Recovery‑Zeitpunkt auf den letzten verfügbaren LSN und kommunizieren Sie Datenverlustumfang.
• WAL‑Korruption: Verwenden Sie pg_waldump, um die Korruption zu identifizieren. Korruptionsfixes sind in der Regel nicht möglich — Sie benötigen eine intakte Kopie der betreffenden WAL oder müssen vor dem korrupten Segment stoppen.
• Timeline‑Verwirrung: Prüfen Sie .history‑Dateien im Archiv und setzen Sie recovery_target_timeline entsprechend.
• Berechtigungs- und Environment‑Fehler: Testen Sie alle Scripts als postgres‑User; prüfen Sie SELinux/AppArmor und Umgebungsvariablen für aws/gsutil.

Integritätsprüfungen und Validierungstechniken

Zusätzlich zu einfachen Stichproben sollten Sie strukturierte Prüfungen einplanen:

• Vergleich von Row‑Counts für Schlüsseltabellen zwischen produktivem Log und wiederhergestelltem System.
• Checksum‑Validierung bei Base Backups (sofern beim Backup erstellt) und bei Archivobjekten durch gespeicherte SHA256‑Manifeste.
• Funktions‑ und Integrationschecks mit einer Kopie der Anwendung in Read‑Only‑Modus.

Automatisierung und Monitoring: empfohlene Prüfqueries

Richten Sie Monitoring‑Checks ein, die Archivierungsfehler frühzeitig melden:

# Letzte Archivierungs‑Informationen
psql -c "SELECT archived_count, failed_count, last_archived_wal FROM pg_stat_archiver;"
# Letzte WAL-File-Zeitstempel
psql -c "SELECT name, last_modified FROM pg_ls_waldir() LIMIT 10;" -- Abhängig von installierten Helper-Funktionen

Ergänzen Sie Alerts in Prometheus/Nagios, die alarmieren, wenn seit X Stunden keine WALs mehr archiviert wurden oder ein restore_command fehlschlägt.

Wenn PITR unmöglich ist: Alternativen

Wenn WAL‑Lücken bestehen und kein vollständiger PITR möglich ist, kommen Alternativen zum Tragen:

• Logische Wiederherstellung von Tabellen mit pg_dump/pg_restore, sofern vorhandene logische Backups existieren.
• Rekonstruktion aus Anwendungslogs oder ETL‑Sourcen.
• Teilweise Wiederherstellung: Recovery bis zur letzten verfügbaren WAL und ergänzende Korrekturen durch Anwendungsteams.

Praxis‑Tipps für den Betrieb

• Automatisieren Sie Probe‑Restores in einer isolierten Umgebung und dokumentieren Sie Zeiten (RTO) und Aufwand.
• Katalogisieren Sie Backups und WAL‑Ranges in einem zentralen Verzeichnis/DB mit Metadaten (Start/End LSN, Timeline, Checksummen).
• Verwalten Sie Zugriffe auf Archivziele minimalistisch (IAM‑Principle of Least Privilege) und nutzen Sie verschlüsselte Speicherung.
• Erstellen Sie nach jedem Recovery umgehend ein neues Base Backup, um die zukünftige Chain zu vereinfachen.

Checkliste: Vor dem Live‑PITR (Erweiterte Version)

1. Asset‑Check: Base Backup vollständig, backup_label und Manifest geprüft.
2. WAL‑Check: Alle WAL‑Dateien vorhanden und integritätsgeprüft.
3. restore_command: manuell als postgres‑User getestet, Exit‑Codes korrekt.
4. Timeline‑Check: .history‑Dateien und Timeline‑IDs abgeglichen.
5. Recovery‑Host: Ressourcen, Isolierung und Storage‑IO geprüft.
6. Kommunikation: Stakeholder informiert, Eskalationskette bereit.
7. Rückfall: Aktuelles PGDATA gesichert, Rückfallkriterien im Runbook definiert.

Fazit

PostgreSQL Point-in-Time-Recovery (PITR) ist mächtig, aber betrieblich anspruchsvoll. Entscheidend sind verlässliche Base Backups, lückenlose WAL‑Archivierung, getestete restore_command‑Skripte, klare Timeline‑Dokumentation und automatisierte Prüfungen. Mit regelmäßigen Probe‑Restores, redundanten Archivstrategien und einer sauberen Runbook‑Dokumentation wird PITR zu einem verlässlichen Baustein Ihrer Disaster‑Recovery‑Strategie. Planen Sie Ressourcen für Prüfung und Automation ein — die Kosten für präventive Tests sind im Vergleich zu ungeplanten, chaotischen Wiederherstellungen gering.

Weiterführende Hinweise für interne Verlinkung

Interne Seiten, die Sie verlinken sollten: Backup‑Policy, WAL‑Archivierungskonfiguration, Recovery‑Runbook, IAM‑Richtlinien für Cloud‑Storage und Kontaktliste der verantwortlichen Teams. Diese Links erleichtern die Verantwortungszuweisung und beschleunigen das Recovery im Ernstfall.

PostgreSQL Point‑in‑Time‑Recovery (PITR): Architektur‑ und Integrationsaspekte

Ergänzend zu Restore‑Ablauf und Prüfschritten lohnt sich ein Blick auf Architekturentscheidungen und Integrationen, die im Betrieb den Unterschied zwischen schnell wiederherstellbarer Umgebung und langwieriger Incident‑Rekonstruktion machen.

Archivierung, Objekt‑Storage und Lifecycle: praktische Regeln

WAL‑Archive landen heute häufig in S3‑ähnlichen Objektspeichern. Planen Sie Lifecycles so, dass WALs mindestens bis zum größen Recovery‑Fenster (RPO) vorhanden bleiben. Achten Sie auf Objekt‑Versionierung/Immutability, um versehentliches Überschreiben zu verhindern. Beachten Sie Netzwerk‑Egress‑Kosten bei großem Wiederherstellungsbedarf aus Cloud‑Regionen.

Sicherheit, Credentials und Least‑Privilege

Das restore_command benötigt Zugriff auf Archivziele. Verwenden Sie kurzlebige Rollen/Token (IAM‑Session, presigned URLs) statt statischer Keys. Rollen sollten nur Leserechte für die relevanten Prefixes haben. Dokumentieren Sie Schlüsselrotation und Audit‑Trails, damit ein kompromittiertes Archiv‑Credential schnell entzogen werden kann.

Kubernetes, Snapshots und PITR: Fallen vermeiden

In containerisierten Umgebungen sind PV‑Snapshots attraktiv, aber sie ersetzen nicht automatisch ein konsistentes Base Backup + WAL‑Kette. Ein Snapshot eines laufenden Postgres‑Pods muss koordiniert werden (z. B. pg_start_backup/pg_stop_backup oder Filesystem‑Freeze), sonst fehlen WALs oder das Backup ist inkonsistent. Bei StatefulSets empfiehlt sich eine Kombination aus CSI‑Snapshots für schnelle Recoveries und regulären Base Backups für PITR‑Fähigkeit.

Idempotenz und Robustheit des restore_command

restore_command wird bei jedem fehlenden WAL‑Segment mehrfach aufgerufen. Sorgen Sie dafür, dass das Script idempotent ist, temporäre Dateien atomar schreibt und Fehlercodes korrekt propagiert. Testen Sie das Script unter Bedingungen wie langsamer Netzwerkverbindung, unerwartetem 403/404 und partiellen Downloads.

# Überwachung: einfache Prüfqueries, die Sie in Alerts nutzen können
psql -c "SELECT archived_count, failed_count, last_archived_wal FROM pg_stat_archiver;"
psql -c "SELECT status, receive_start_lsn, receive_start_tli FROM pg_stat_wal_receiver;"

Operationales Zusammenspiel mit Replikation und Failover

Führen Sie Recovery immer isoliert durch — vermeiden Sie automatische Promotions von Streaming‑Replica während eines geplanten PITR. Timeline‑Branching nach einer Promotion führt sonst zu komplexen .history‑Situationen. Definieren Sie im Runbook, wann Replicas gestoppt, wann konservative Promotions erlaubt und wann ein manueller Eingriff notwendig ist.

Validierung als Prozess: Automatisierte Probe‑Restores

Automatisieren Sie Probe‑Restores in regelmäßigen Intervallen und dokumentieren Sie RTO/RPO. Ein sauberes Reporting über Erfolgsrate, Dauer und aufgetretene Archivfehler macht PITR‑Bereitschaft messbar und reduziert das Risiko von Überraschungen im Ernstfall.

Für dieses Thema sind auch Wal-Archiving wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.