Der Job, der nicht mehr anlief und nichts meldete
Vor einem geplanten Update wollten wir nur eine einzige Frage beantworten: Gibt es einen Weg zurück? Drei Docker-Hosts, auf denen unter anderem unser GitLab, unser Ticketsystem und ein Objektspeicher liegen. Auf allen dreien läuft ein Veeam-Agent, alle drei sind seit Monaten unauffällig. Die Prüfung sollte fünf Minuten dauern.
Auf zwei Hosts stand der letzte erfolgreiche Lauf vom Vorabend, 20:00 Uhr. Auf dem dritten stand er vom 12. Juni.
Es war Ende August.
Was auf dem Host zu sehen war
Nichts Auffälliges. Genau das ist der Punkt.
Der Agent war installiert. Der Dienst war aktiv — systemctl meldete brav active (running). Der Job war konfiguriert, mit einem sauberen Namen, alle zwei Stunden. Wer auf diese Maschine schaut und die Frage „ist hier ein Backup eingerichtet?" beantworten soll, beantwortet sie mit Ja, und liegt damit nicht einmal falsch.
Der Sitzungsverlauf erzählte eine andere Geschichte. Letzter Erfolg am 12. Juni um acht Uhr morgens. Danach vier Fehlschläge am selben Tag. Ein weiterer Versuch Mitte Juli. Und seitdem: nichts. Keine Fehlschläge mehr. Der Job lief gar nicht mehr an.
Warum er aufhörte, wissen wir bis heute nicht. Wir haben es nicht ermittelt — als der Befund auf dem Tisch lag, ging es darum, überhaupt wieder Sicherungen zu bekommen, und danach war die Spur kalt. Das ist unbefriedigend und gehört trotzdem hierher.
Dazu die Aufbewahrung: 14 Tage. Gelöscht war deshalb nichts — aufgeräumt wird im Joblauf, und der fand ja nicht statt. Was dort lag, war nur zwei Monate alt. Für ein GitLab, ein Ticketsystem und einen Objektspeicher, in die täglich geschrieben wird, ist das derselbe Befund in freundlicherer Verpackung: zurückspielen hätte das niemand wollen.
Warum das niemandem aufgefallen ist
Zwei Dinge kommen zusammen, und beide sind unangenehm einleuchtend, sobald man sie einmal gesehen hat.
Erstens: Ein Job, der nicht mehr anläuft, meldet keinen Fehler. Er meldet gar nichts. Eine Überwachung, die auf „letzter Lauf fehlgeschlagen" reagiert, sieht hier nichts, weil es keinen letzten Lauf gibt, über den sie urteilen könnte. Das Fehlen eines Ereignisses ist kein Ereignis. Alles, was auf Alarme wartet, wartet in diesem Fall für immer.
Gebraucht wird die umgekehrte Prüfung, und die klingt banal, bis man sie einmal eingebaut hat: Wann war der letzte erfolgreiche Lauf — und ist das länger her als das Intervall? Diese Frage findet beide Fälle, den fehlgeschlagenen und den ausgebliebenen. Die Frage nach dem Fehler findet nur einen davon.
Zweitens erzeugt „Agent installiert und Dienst aktiv" ein falsches Gefühl von Sicherheit. systemctl is-active sagt aus, dass ein Prozess läuft. Es sagt nichts darüber, ob jemals Daten geflossen sind. Wir haben diesen Unterschied jahrelang gekannt und trotzdem nicht überwacht, weil ein aktiver Dienst auf einem Dashboard eben grün ist und Grün beruhigt.
Die Prüfung, die tatsächlich etwas aussagt
Lesend, direkt auf dem Host:
sudo veeamconfig job list
sudo veeamconfig session list | tail
sudo veeamconfig job info --name "<Jobname>"
Drei Werte sind interessant, und der dritte macht aus den ersten beiden erst eine Aussage:
- Datum der letzten erfolgreichen Sitzung.
- Datum der letzten Sitzung überhaupt. Die Lücke zwischen 1 und 2 ist der eigentliche Befund — sie beschreibt den Zeitraum, in dem es noch Versuche gab. Fehlt sie, hat der Job irgendwann aufgehört, es überhaupt zu versuchen.
- Die Aufbewahrung aus der Job-Information. Sie sagt, wie alt der Bestand höchstens sein sollte. Liegt der letzte Erfolg darüber, ist die Kette eingefroren: Die Konsole zeigt weiter Sicherungen an, nur ist keine davon jünger als der Stillstand. Angezeigt heißt nicht brauchbar.
Punkt 3 ist der, den man beim ersten Lesen überfliegt. Er ist der Unterschied zwischen einer Anzeige und einer Aussage.
Dasselbe Muster in fremdbetreuten Umgebungen
Diesen Befund als Einzelfall abzutun, wäre bequem. Er ist keiner. Aus Healthchecks in fremdbetreuten Umgebungen kennen wir dieselbe Form in schärferer Ausprägung:
Bei einem Kunden lief über ein Jahr lang kein Backup mehr. Aufgefallen ist es nicht durch das Monitoring, sondern durch den Ausfall einer Anwendung — also erst durch den Schaden, gegen den das Backup schützen sollte.
Bei einem zweiten fand sich ein Standort, dessen letzte funktionierende Sicherung mehr als vier Jahre zurücklag. Vier Jahre, in denen jeden Tag jemand hätte hinsehen können und niemand einen Anlass dazu hatte, weil nichts rot war.
Bei einem dritten waren Backup-Copy- und Tape-Jobs seit Monaten deaktiviert. Nicht kaputt, sondern abgeschaltet. Jemand hatte sie einmal aus gutem Grund stillgelegt — so ein Wartungsfenster richtet man für Feiertage und Updates ganz bewusst ein — und niemand hatte sie wieder eingeschaltet.
Was diese drei Fälle mit unserem verbindet, ist nicht die Ursache. Es ist die Art, wie sie sich zeigen: gar nicht. Ein defektes Backup schreit. Ein abwesendes schweigt.
Was wir daraus gemacht haben
Zwei Regeln, beide unspektakulär, beide vorher nicht aufgeschrieben.
Die Prüfung gehört an den Anfang, nicht ans Ende. Vor jeder Entscheidung, die sich auf einen Rollback stützt — Update, Migration, Umbau —, wird nachgesehen, ob es den Rollback gibt. Nicht ob er eingerichtet ist. Ob er existiert. Wir hatten das Update ohne diese Prüfung angefangen und sind nur deshalb darüber gestolpert, weil jemand nebenbei die Frage stellte.
Und der zweite Teil, der weiter reicht: Ein Job, der grün meldet, ist noch kein geprüfter Restore. Der Unterschied zwischen „Sicherung erfolgreich" und „Wiederherstellung funktioniert" kostet genau dann Zeit, wenn keine da ist. Was sie beantwortet, ist ein Testboot aus der Sicherung heraus: automatisch und nächtlich, wo die Umgebung das hergibt, sonst von Hand und halbjährlich als Rückfallebene. Alles andere ist eine Vermutung mit Zeitstempel.
Wie weit man dieser Vermutung trauen kann, wenn wirklich etwas passiert, steht in einem anderen Fall: Als das Backup nicht helfen konnte. Und wie sehr eine Konfiguration lügen kann, ohne einen einzigen Fehler zu produzieren, zeigt der Fall mit den dreißig Restore Points.
Ein Backup, das nicht nachgesehen wurde, ist kein Backup. Wir haben zwei Monate gebraucht, um das an uns selbst zu bemerken.