Als das Backup nicht helfen konnte
Der Techniker hatte alles richtig machen wollen, und das ist keine Floskel, mit der ich ihn schone. Er hatte es tatsächlich richtig gemacht.
Ein geplantes Update in einer VMware-Umgebung. Erst der ESXi-Host, sauber durch. Dann sollte das vCenter dran — die zentrale Verwaltungsinstanz, ohne die in so einer Umgebung wenig geht. Vor dem Update wollte er einen Snapshot ziehen, und zwar nicht im laufenden Betrieb, sondern im ausgeschalteten Zustand. Ein Cold Snapshot ist die vorsichtige Variante: keine offenen Transaktionen, kein halb geschriebener Zustand, nichts, was hinterher inkonsistent sein könnte.
Er fuhr das vCenter also geordnet herunter, zog den Snapshot und startete es wieder.
Die Kerndienste kamen nicht mehr hoch.
Die Ursache, die vorher schon da war
Nach Stunden der Analyse blieb eine Erklärung übrig, und ich schreibe sie als das hin, was sie ist: eine begründete Vermutung, nie mit letzter Sicherheit festgestellt. Eine früher geänderte Kennwortrichtlinie hatte die Passwörter interner Dienstkonten ablaufen lassen.
Im laufenden Betrieb merkt das niemand. Die Dienste laufen ja — sie haben sich beim Start angemeldet und halten ihre Sitzung. Ein abgelaufenes Passwort fällt erst beim nächsten Anmeldevorgang auf, und der findet nicht statt, solange nichts neu startet.
Das System hatte eine Laufzeit von mindestens 120 Tagen. Vier Monate, in denen der Fehler mitlief, ohne sich zu zeigen. Vier Monate, in denen jede Sicherung ihn brav mitgesichert hat.
Erst der Neustart machte ihn sichtbar. Und da war er schon älter als alles, was zur Rettung bereitstand.
„Da hilft kein Backup"
Jetzt kommt der Teil, der diesen Fall für jeden interessant macht, der Backup betreibt oder verantwortet.
Das Backup war da. Mehrfach sogar.
Der Snapshot-Rollback? Reproduzierte das Problem punktgenau. Die abgelaufenen Passwörter steckten bereits darin — der Snapshot war ja Minuten vor dem Neustart entstanden, der Fehler Monate davor. Dass abgelaufene Dienstkonten so lange unsichtbar bleiben, ist kein Einzelfall — über eigene Dienstkonten statt administrator@vsphere haben wir hier schon einmal geschrieben.
Der dateibasierte Restore der Appliance? Stellte exakt denselben kaputten Zustand wieder her. Die Korruption war älter als jede verfügbare Sicherung ihrer Symptome.
Und das eigentliche Rettungswerkzeug — Veeam Backup & Replication — war in dieser Umgebung über das vCenter angebunden. Mit dem vCenter fiel damit auch der Weg zu den Sicherungen weg.
Ein Ausweg wäre gewesen, den ESXi-Host direkt in Veeam einzubinden und von dort auf einen Standalone-Host zurückzuspielen. Das geht grundsätzlich. Es geht nur nicht schnell und nicht nebenbei, während eine Produktivumgebung steht und das Telefon klingelt. In dieser Nacht war es keine Option, die getragen hätte.
Das ist kein Mangel des Produkts, und ich will es auch nicht als einen darstellen. Es ist eine Architektureigenschaft: Das Backupwerkzeug spricht mit der Verwaltungsebene, weil es genau dort erfährt, welche Maschinen es überhaupt gibt. Dass daneben noch ein zweiter, vCenter-freier Weg bereitsteht, ist eine Entscheidung, die man vorher trifft — oder eben nicht. Nur führt diese vollkommen vernünftige Konstruktion zu einer Zirkelabhängigkeit, sobald ausgerechnet die Verwaltungsebene das ausgefallene System ist.
Der Ausweg war eine Neuimplementierung.
Der Dominoeffekt danach
Damit war es nicht vorbei, es fing damit an.
Ein neu aufgesetztes vCenter kennt die vorhandenen virtuellen Maschinen nicht als dieselben Objekte. Für das Backupwerkzeug sind sie neu. Man kann versuchen, die Zuordnung von Hand wiederherzustellen; in dieser Lage, mit frisch aufgebauter Verwaltungsebene und Zeitdruck, wollte sich niemand darauf verlassen. Neue Objekte heißen: keine Fortsetzung bestehender Ketten, sondern Vollsicherung des gesamten Bestands. Vollsicherung des gesamten Bestands heißt: Platzbedarf im Sicherungsziel, den niemand eingeplant hatte, und ein Zeitfenster, das es im Tagesbetrieb nicht gibt.
Der eigentliche Schaden dieses Vorfalls lag nicht in der Nacht des Ausfalls. Er lag in den Wochen danach.
Was man daraus mitnimmt
Drei Dinge, und keines davon ist ein Produktkauf.
Ein Backup stellt auch einen kaputten Zustand zuverlässig wieder her. Es ist keine Prüfinstanz. Es fragt nicht nach, ob das, was es sichert, funktioniert. Wer vom Backup Rettung erwartet, erwartet damit implizit, dass irgendwann in der Aufbewahrungsspanne ein gesunder Zustand lag — und genau diese Annahme trägt nicht, wenn der Fehler still ist und älter als die Spanne.
Lange Laufzeit ohne Neustart ist kein Qualitätsmerkmal, sondern ein Risikospeicher. 120 Tage Uptime klingen nach Stabilität. Sie bedeuten in Wahrheit: 120 Tage lang wurde nicht geprüft, ob dieses System noch startet. Ein geplanter Neustart ist keine Störung, sondern eine Messung — und man macht sie besser zu einem Zeitpunkt, den man sich aussucht.
Und die Verwaltungsinstanz braucht eine eigene Behandlung. Ein eigener Sicherungsjob mit eigener, kürzerer Kette und eigener Aufbewahrung. Die Wiederherstellbarkeit muss auch dann gegeben sein, wenn das vCenter selbst ausgefallen ist — was in der Praxis heißt: der Weg dorthin darf nicht über das vCenter führen. Dazu ein automatischer nächtlicher Testboot der Sicherung in einer isolierten Umgebung, der prüft, ob das System hochkommt und ob die Dienste starten.
Genau dieser Testboot hätte den Fehler hier Monate vor der Krise gefunden. Nicht, weil er klug ist, sondern weil er das Einzige tut, was zählt: Er startet die Maschine wirklich, statt zu bestätigen, dass eine Datei existiert.
Wie weit „die Datei existiert" von „es funktioniert" entfernt sein kann, steht auch im stillen Backup-Ausfall — dort in der Variante, in der überhaupt keine Datei mehr entsteht.
Der Satz, der von diesem Fall hängengeblieben ist, kam vom Techniker selbst, irgendwann gegen Mitternacht: Ich habe alles gesichert, was man sichern kann. Er hatte recht. Es hat nicht gereicht.