Point-in-Time Recovery (PITR) als Produktversprechen: Backup-Strategien im Scale

In der Welt der Datenbanken gibt es einen gewaltigen Unterschied zwischen einem “Backup” und der “Wiederherstellbarkeit”. Für einen DBaaS-Anbieter ist ein täglicher Snapshot der Daten nicht genug. Wenn ein Kunde versehentlich um 14:05 Uhr eine wichtige Tabelle löscht, hilft ihm ein Backup von 02:00 Uhr morgens nur bedingt - er verlöre die Arbeit eines ganzen Vormittags.

Das echte Produktversprechen einer modernen Datenbank-Plattform lautet Point-in-Time Recovery (PITR). Es ermöglicht die Wiederherstellung auf jede beliebige Sekunde innerhalb des Aufbewahrungszeitraums.

1. Die Mechanik: Base Backups und WAL-Streaming

Um PITR technisch umzusetzen, nutzen wir ein kombiniertes Verfahren aus zwei Komponenten:

1. Full Base Backups: In regelmäßigen Abständen (z. B. täglich) wird ein komplettes Abbild der Datenbank erstellt und im Object Storage (Ceph RGW) gespeichert.
2. WAL-Archivierung (Write-Ahead-Logs): Jede Änderung an der Datenbank wird in sogenannten WAL-Files protokolliert. Diese Dateien werden kontinuierlich - fast in Echtzeit - in den S3-Speicher gestreamt.

Bei einem Restore-Wunsch spielt das System zuerst das letzte Base Backup vor dem Zielzeitpunkt ein und “spult” dann die WAL-Files bis zur exakten Sekunde vor. Das Ergebnis: Ein konsistenter Datenstand mit minimalem Datenverlust (RPO nahe Null).

2. Skalierung: Hunderte Instanzen, eine Backup-Logik

Die Herausforderung für unseren Kunden war die Menge: Wie managt man diese Logik für hunderte Datenbanken gleichzeitig, ohne dass der Storage explodiert oder die Übersicht verloren geht?

• Zentrale Orchestrierung: Der Datenbank-Operator übernimmt die automatische Rotation der Backups und die Bereinigung alter WAL-Files (Retention Management).
• Georedundanz als Standard: Jedes Backup wird sofort nach der Erstellung in eine zweite, physisch getrennte Region repliziert. So ist die Plattform auch gegen den Ausfall eines kompletten Rechenzentrums gewappnet.
• Kostenkontrolle durch Object Storage: Da WAL-Files massiv anwachsen können, ist die Speicherung auf günstigem S3-Speicher (Ceph) der Schlüssel zur wirtschaftlichen Skalierung.

3. Die Restore-Garantie: Vertrauen ist gut, automatisierte Tests sind besser

Ein Backup ist nur so viel wert wie der erfolgreiche Restore. In der Praxis scheitern viele DR-Konzepte (Disaster Recovery), weil die Wiederherstellung nie ernsthaft geprobt wurde.

Wir haben für die Plattform automatisierte Restore-Tests etabliert. Das System erstellt regelmäßig Test-Instanzen aus den vorhandenen Backups und verifiziert deren Integrität. Nur so kann der Anbieter seinen Kunden gegenüber mit gutem Gewissen eine Verfügbarkeits- und Sicherheitsgarantie abgeben.

Fazit: Datensicherheit als Kernwert

PITR ist für einen DBaaS-Anbieter kein “Feature”, sondern die Lebensversicherung für das Geschäft seiner Kunden. Indem wir die Wiederherstellung auf Sekunden-Ebene automatisieren und georedundant absichern, schaffen wir das nötige Vertrauen, um auch geschäftskritische Workloads auf der Plattform zu halten.

FAQ: Backup & Recovery

Wie weit kann ein Kunde in der Zeit zurückgehen? Das hängt von der definierten “Retention Policy” ab. Üblich sind Zeiträume zwischen 7 und 30 Tagen. Da die WAL-Files Speicherplatz belegen, ist dies oft auch ein Differenzierungsmerkmal zwischen verschiedenen Tarifmodellen des Anbieters.

Beeinflusst das WAL-Streaming die Datenbank-Performance? Durch die Nutzung von asynchronem Archivierung und dediziertem Object Storage halten wir den Overhead extrem gering. Die Datenbank schreibt ihre Logs ohnehin lokal; der Kopiervorgang in den S3-Speicher passiert im Hintergrund.

Was passiert bei einem “Corruption”-Fehler in der Datenbank? Genau hier glänzt PITR. Wenn die Daten korrumpiert wurden (z. B. durch einen Software-Bug), kann der Kunde den Zeitpunkt kurz vor dem korrumpierenden Ereignis wählen und eine saubere Instanz wiederherstellen.

Kann der Kunde Restores selbst auslösen? Ja, das ist das Ziel von Self-Service. Über das API oder das Kundenportal wählt der Nutzer den Zeitpunkt und die Ziel-Instanz. Die Plattform kümmert sich im Hintergrund um das Provisionieren der Ressourcen und das Einspielen der Daten.