Point-in-Time-Recovery: Datenbank auf einen Zeitpunkt zurücksetzen

Kurz: Point-in-Time-Recovery (PITR) stellt eine Datenbank auf einen beliebigen Moment in der Vergangenheit wieder her, indem ein Basis-Backup mit dem Transaktionsprotokoll bis zu diesem Zeitpunkt abgespielt wird.

Genauer: Ein nächtliches Backup hilft wenig, wenn um 14:03 Uhr versehentlich eine Tabelle gelöscht wird: Es fehlt dann der halbe Tag. PITR schließt diese Lücke, indem es neben dem Backup auch jede einzelne Änderung aufbewahrt.

Im Detail

Prinzip

Datenbanken schreiben jede Änderung zuerst in ein Write-Ahead-Log (WAL). Bei PITR gibt es ein Basis-Backup (Vollkopie der Daten) plus das fortlaufend archivierte WAL. Zur Wiederherstellung spielt man das Basis-Backup zurück und lässt das WAL bis kurz vor dem Fehler ablaufen (recovery_target_time). Ergebnis: Zustand von 14:02:59 statt gestern Nacht.

Umsetzung (PostgreSQL)

• archive_mode = on und archive_command kopieren fertige WAL-Segmente an einen sicheren Ort.
• Basis-Backup mit pg_basebackup (oder Werkzeuge wie pgBackRest, Barman, WAL-G).
• Wiederherstellung: Backup einspielen, recovery.signal anlegen, Zielzeit setzen, Server starten.
• Managed-Dienste (zum Beispiel Neon, Supabase, RDS) bieten PITR als Funktion, oft mit begrenztem Zeitfenster (Stunden bis Tage je nach Tarif).

Wichtige Hinweise

• PITR schützt vor Bedienfehlern und fehlerhaften Updates, nicht vor dem Ausfall des Speichers, wenn das WAL-Archiv am gleichen Ort liegt: extern ablegen.
• Wiederherstellung testen; ein ungetestetes Backup ist ein Hoffnungswert.
• Man stellt meist in eine neue Instanz wieder her und übernimmt nur die benötigten Daten.
• Aufbewahrungsfrist passend zur Aufbewahrungspflicht und zum Datenschutz (gelöschte Personendaten verschwinden aus Backups erst nach der Frist).
• Kenngrößen: RPO (wie viel Datenverlust ist tragbar) und RTO (wie lange darf die Wiederherstellung dauern).

Siehe auch: pg_dump und psql, Transaktionen und ACID, Neon