Backup ist dein Sicherheitsnetz, nicht deine Migrationsstrategie

Dein Team hat gerade eine Datenbank-Migration ausgeführt, die die Tabelle orders_archive gelöscht hat. Die Daten wurden in eine neue Tabelle verschoben, also sah alles sauber aus. Aber ein altes System, an das niemand mehr dachte, las immer noch aus dieser Tabelle. Jetzt ist die Tabelle weg, die Daten sind weg, und die neue Migration, um sie neu zu erstellen, hat nichts, was sie wiederherstellen könnte.

Oder du hast eine Spalte price von INTEGER auf DECIMAL geändert, und ein Batch-Job, der jede Stunde läuft, schreibt immer noch Integer-Werte in diese Spalte und korrumpiert dabei stillschweigend Datensätze.

In solchen Momenten ist der Instinkt verständlich: „Wir haben Backups. Stellen wir einfach die Datenbank auf den Stand vor der Migration wieder her.“

Das klingt vernünftig. Aber die Folgen sind oft schlimmer als das ursprüngliche Problem.

Wofür Backups eigentlich da sind

Backups existieren für katastrophale Szenarien. Ein Brand im Serverraum. Ein Ausfall des Storage-Arrays. Eine korrumpierte Festplatte. Ein Admin, der versehentlich eine kritische Tabelle löscht. In diesen Situationen ist die Wiederherstellung aus dem Backup die richtige Entscheidung. Du hast keine andere Option, und die Kosten, nicht wiederherzustellen, sind ein vollständiger Datenverlust.

Aber eine fehlgeschlagene Migration ist keine Katastrophe. Es ist ein routinemäßiges Betriebsereignis. Und wenn du es wie eine Katastrophe behandelst, schaffst du neue Probleme.

Die zwei Probleme mit Backup-basiertem Rollback

Datenverlust

Ein Backup ist ein Snapshot deiner Daten zu einem bestimmten Zeitpunkt. Wenn du das Backup um 2:00 Uhr morgens erstellt hast und die Migration um 10:00 Uhr fehlschlägt, hast du acht Stunden Benutzeraktivität, die nur in deiner Produktionsdatenbank existiert. Getätigte Bestellungen. Aktualisierte Profile. Erstellte Support-Tickets. Durchgeführte Konfigurationsänderungen.

Wenn du das Backup von 2:00 Uhr morgens wiederherstellst, verschwinden all diese Daten. Es gibt keine Möglichkeit, sie zurückzubekommen, es sei denn, du hast eine andere Quelle. Diese Lücke wird größer, je länger die Zeit zwischen Backup und Wiederherstellung ist. Selbst wenn du Point-in-Time-Recovery verwendest und auf 9:59 Uhr wiederherstellst, verlierst du immer noch alles, was in dieser letzten Minute passiert ist.

Ausfallzeit

Die Wiederherstellung einer Datenbank ist nicht sofort erledigt. Bei Datenbanken im Bereich von Hunderten von Gigabyte kann die Wiederherstellung Stunden dauern. Während dieser Zeit kann deine Anwendung keinen normalen Traffic bedienen. Die Daten sind inkonsistent, teilweise geladen oder durch den Wiederherstellungsprozess gesperrt.

Vergleiche das mit einem Roll-forward-Ansatz, bei dem du eine neue Migration ausführst, die Minuten dauert. Oder einem kompensierenden Skript, das Daten anpasst, ohne die Anwendung zu stoppen. Backup-basiertes Rollback zwingt dein Team, zwischen Datenverlust und langer Ausfallzeit zu wählen – oft beidem.

Point-in-Time-Recovery reduziert, löst aber nicht

Einige Teams verwenden Point-in-Time-Recovery (PITR), um die Datenlücke zu verkleinern. Anstatt auf das letzte vollständige Backup zurückzusetzen, stellen sie auf eine bestimmte Transaktionslog-Position wieder her, zum Beispiel eine Minute bevor die Migration lief.

Das hilft. Du verlierst weniger Daten. Aber du verlierst immer noch welche. Transaktionen, die in den Sekunden vor der Migration abgeschlossen wurden, sind weg. Und die Wiederherstellung selbst dauert immer noch Zeit. PITR ist besser als eine vollständige Backup-Wiederherstellung, aber es ist kein sauberer Rollback-Mechanismus.

Wo Backups in deiner Wiederherstellungshierarchie hingehören

Backups haben eine klare Rolle bei der Datenbankwiederherstellung: Sie sind die letzte Option. Das Sicherheitsnetz für den Fall, dass alles andere versagt hat und du bereit bist, Datenverlust und Ausfallzeit zu akzeptieren, weil die Alternative schlimmer ist.

In einem reifen Team werden Backups regelmäßig erstellt und periodisch getestet. Aber wenn eine Migration schiefgeht, greift das Team nicht zuerst zum Backup. Sie arbeiten eine Hierarchie ab:

Das folgende Flussdiagramm fasst diesen Entscheidungsprozess zusammen:

1. Roll-forward: Schreibe eine neue Migration, die die Änderung rückgängig macht oder das fehlende Stück hinzufügt.
2. Kompensierendes Skript: Führe ein Skript aus, das Daten anpasst, ohne eine vollständige Migration.
3. Backup-Wiederherstellung: Erst nach Abwägung der Kompromisse bei Datenverlust und Ausfallzeit.

Eine praktische Checkliste, bevor du zum Backup greifst

Bevor du aus dem Backup wiederherstellst, stelle dir diese Fragen:

• Können wir eine Migration schreiben, die die entfernte Tabelle oder Spalte wieder hinzufügt?
• Können wir ein kompensierendes Skript ausführen, das die verlorenen Daten aus Logs oder anderen Quellen rekonstruiert?
• Wie viele Daten werden wir verlieren, wenn wir aus dem letzten Backup wiederherstellen?
• Wie lange wird die Wiederherstellung dauern, und kann das Geschäft diese Ausfallzeit akzeptieren?
• Gibt es eine Möglichkeit, die Anwendung teilweise laufen zu lassen, während wir die Daten reparieren?

Wenn die Antwort auf die ersten beiden Fragen „Ja“ lautet, brauchst du keine Backup-Wiederherstellung. Wenn die Antwort auf die letzten drei Fragen „inakzeptabel“ lautet, musst du einen anderen Weg finden.

Die Erkenntnis

Backup ist dein Sicherheitsnetz für Katastrophen, nicht deine Migrations-Rollback-Strategie. Wenn eine Migration fehlschlägt, beginne mit Roll-forward oder kompensierenden Skripten. Greife nur dann zum Backup, wenn diese Optionen ausgeschöpft sind und du die Kosten für Datenverlust und Ausfallzeit akzeptiert hast. Ein Team, das Backup als Standard-Rollback-Plan behandelt, ist ein Team, das Produktionsdaten und Schlaf verlieren wird.