Wöchentlich einen PostgreSQL-PITR-Restore-Drill fahren (hier ist unser Runbook)

Ein Backup, das nie wiederhergestellt wurde, ist eine Hoffnung, kein Backup. Jede gemanagte Postgres-Datenbank, die wir betreiben, durchläuft einen wöchentlichen Point-in-Time-Recovery-Drill (PITR), durchgehend automatisiert, mit dem Ergebnis in Ihrem monatlichen Health-Report.

Was der Drill tatsächlich macht

1. Einen zufälligen Zeitstempel innerhalb der letzten 7 Tage WAL-Retention auswählen.
2. Eine Sandbox-Instanz in einer günstigeren Instance-Klasse als Produktion bereitstellen.
3. Das neueste Base-Backup in die Sandbox zurückspielen.
4. WAL bis zum gewählten Zeitstempel abspielen.
5. Eine Integritätssonde laufen lassen — Schema-Diff gegen Produktion, Row-Count-Delta innerhalb der Toleranz, eine Handvoll Integritäts-SQL-Checks.
6. Die Sandbox abreißen. ~5 Minuten Compute berechnet. Erfolg oder Fehlschlag melden.

Was er einfängt

Die vier Dinge, die dieser Drill einfängt und die „Backup ist gelaufen"-Alerts nicht einfangen:

• Backups, die stillschweigend von WAL+Base zu „nur Snapshots" gewechselt sind, weil jemand die Retention-Policy geändert hat
• WAL-Lücken durch archive_command-Fehler, die niemand bemerkte, weil die Datenbank weiterlief
• Permission-Drift, der Backups laufen lässt, aber dem Restore-Rolle das Lesen blockiert
• Encryption-Key-Rotation, die ältere Snapshots unbrauchbar machte

Was wir nicht automatisieren

Wir automatisieren nicht die Katastrophen-Erklärung. Das Runbook verlangt explizit, dass ein Mensch entscheidet, wir machen ein echtes Restore, nicht den Drill. Diese Leitplanke hat uns mehr als einmal vor „Automation läuft Amok und stellt Produktion auf gestern wieder her" bewahrt.

Das vollständige Runbook auf Medium enthält das Terraform, mit dem wir die Sandbox aufdrehen, das Bash, das Schemas vergleicht, und die Alert-Regeln, die eskalieren, wenn der Drill zweimal hintereinander fehlschlägt.