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:
- 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.
- 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.
Passend bei ayedo
- SaaS Hosting – Komplettpaket für Softwarehersteller
- App Hosting – Ihre Anwendung auf Managed Kubernetes
- Managed Kubernetes vs. klassisches Hosting – TCO und Betriebsmodelle
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.