Point-in-Time-Rollback: Backups, die man wirklich zurückspielen kann

Ein Backup ist erst dann eines, wenn der Restore bewiesen ist. Wie inkrementelle Snapshots, WAL-Archivierung und Off-Site-Kopien zusammenspielen — und warum wir Restores regelmäßig testen.

Die traurigste Erkenntnis im Datenverlust-Fall ist nicht "wir haben kein Backup". Es ist "wir haben eines, aber es lässt sich nicht zurückspielen" — zu alt, unvollständig, nie getestet, oder es liegt auf demselben System, das gerade brennt. Eine Backup-Strategie ist eine Restore-Strategie, alles andere ist Ablage.

Drei Schichten statt einer

Unser Standard kombiniert drei Mechanismen: Engmaschige inkrementelle Snapshots auf dem Cluster für den schnellen Griff zurück ("die letzten vier Stunden"). Tägliche Voll-Backups auf einen separaten Backup-Server. Und verschlüsselte Off-Site-Replikation an einen zweiten, physisch getrennten Standort — für den Fall, den niemand plant: Standort weg, Verschlüsselungstrojaner, fataler Bedienfehler mit Admin-Rechten.

Point-in-Time: die Minute vor dem Fehler

Für Datenbanken reichen Snapshots allein nicht — zwischen zwei Snapshots liegen Transaktionen. Deshalb archivieren wir bei PostgreSQL das Write-Ahead-Log lückenlos: Ein Restore setzt auf dem letzten Basis-Snapshot auf und spielt das WAL bis zu einem frei wählbaren Zeitpunkt nach. "Zurück auf 14:32:07, direkt vor das fehlerhafte Deployment" ist damit keine Heldentat, sondern ein Vorgang von Minuten.

Restores werden geprobt, nicht gehofft

Jede Kette ist nur so gut wie ihr letzter Test. Wir spielen deshalb regelmäßig komplette Restores in isolierte Umgebungen ein und messen die Dauer — das Ergebnis steht im Cockpit ("Letzter Restore-Test: erfolgreich, 11 Minuten"). Erst diese Zahl macht aus einem Backup ein Versprechen: Sie wissen vorher, wie lange der Ernstfall dauert.

Ransomware verändert die Anforderungen

Moderne Angreifer verschlüsseln zuerst die Backups, dann die Systeme. Dagegen helfen Versionierung, getrennte Zugangsdaten für die Backup-Infrastruktur und unveränderliche Aufbewahrung (Object Lock) im Off-Site-Speicher. Ein Backup, das derselbe Admin-Account löschen kann, der kompromittiert wurde, ist keine letzte Verteidigungslinie.

Off-Site-Backups sind bei uns für jede Ebene zubuchbar — und der Restore-Weg gehört immer dazu. Denn gesichert ist erst, was zurückkam.