True IT Stories

Gleiches Symptom, anderer Täter

Dienstag, 15:22 Uhr. Ein Partner-Systemhaus meldet per Ticket: 36 Backup-Server verbinden sich nicht mehr mit unserer Service Provider Console. Die Dienste hat der Techniker schon neu gestartet, ohne Erfolg. Unser Ticket-Agent stuft das automatisch auf hoch und warnt vor Datenverlust. Das war dramatischer als die Lage, denn die Backups selbst liefen weiter. Ein getrennter Management Agent heißt: Wir sind blind, nicht die Daten weg.

Trotzdem gingen bei uns alle Lampen an. Zwei Wochen vorher hatten wir genau dieses Bild gesehen, massenhaft getrennte Agents. Damals war es ein echter Fehler in der Konsole, bewiesen per Paketmitschnitt , nach siebzehn Tagen behoben und inzwischen als Fix in den Release Notes . Und wir hatten die Konsole am selben Tag planmäßig neu gestartet.

Bekanntes Symptom, passender Zeitpunkt, frische Narbe. Die Diagnose schrieb sich fast von selbst.

Die These, die alles erklärte

Der Export aus der Konsole machte es noch überzeugender. Es waren nicht 36 Systeme eines Partners, sondern 62 Systeme bei sechs Partnern, alle mit dem letzten Lebenszeichen am selben Tag. Die meisten liefen mit der neuesten Agent-Version. Veraltete Software schied also aus, eine zentrale Ursache lag nahe.

Wir haben das Herstellerticket aufgemacht, mit Verweis auf den alten Fall. Derselbe Support-Engineer, der den ersten Fall gelöst hatte, zog es sofort an sich, kündigte die Entwicklung an und bot für den nächsten Tag um 13 Uhr eine gemeinsame Sitzung an. Der Plan für den Abend stand auch schon: Konsolendienste durchstarten, die Medizin vom letzten Mal.

Ein Detail passte nicht. Der Agent auf unserem eigenen Cloud-Connect-Server hatte sich nach dem Neustart der Konsole ganz normal wieder verbunden. Nur die Systeme draußen bei den Kunden hingen. Bei einem Fehler in der Konsole hätte es alle treffen müssen.

„Warum läuft hier eigentlich die PostgreSQL nicht?"

Mittwochvormittag, gemeinsamer Call mit dem Techniker des Partners, Bildschirm geteilt, wir sammeln Logs für den Hersteller. Dann der Satz, der alles dreht: Warum läuft hier eigentlich die PostgreSQL nicht?

Ein Veeam-Server ohne seine Datenbank kann nichts. Der Management Agent meldet folgerichtig „FailedToConnect", und zwar völlig unabhängig davon, was die Konsole tut. Der Techniker hatte die Agent-Dienste neu gestartet. Das kann bei diesem Fehlerbild nie helfen, weil der Agent gar nicht das Problem ist.

Die Ereignisanzeige lieferte Tatzeit und Hergang auf die Minute:

  • 02:04 bis 02:07 Uhr: Das nächtliche App-Patching des RMM-Systems installiert Updates. Darunter Firefox und, unscheinbar, die Microsoft Visual C++ 2022 Runtime in Version 14.51.36247, als vier MSI-Pakete.
  • Der Installer stellt fest, dass vcruntime140.dll und msvcp140.dll in Benutzung sind. Von jedem einzelnen Veeam-Dienst und von PostgreSQL. Die Ereignisanzeige listet sie seitenweise auf.
  • Der Windows Restart Manager stoppt daraufhin PostgreSQL, um die Dateien tauschen zu können. Die Veeam-Dienste lassen sich nicht stoppen und laufen weiter.
  • Dann: „Ein Neustart ist erforderlich. Der Neustart wurde auf einen späteren Zeitpunkt verschoben." Der Installer beendet sich, und niemand startet PostgreSQL wieder.

Beim nächsten Start meldete das PostgreSQL-Log, das Datenbanksystem sei unterbrochen worden. Abgewürgt, nicht heruntergefahren. Auf dem Referenzsystem stand die Datenbank da schon 32 Stunden, und niemand hatte es bemerkt.

Der Beweis dauerte sieben Minuten. PostgreSQL um 10:19 Uhr gestartet, sonst nichts geändert. Um 10:26 Uhr stand im Log des Agents: „Connection result: Registered".

Unser Konsolen-Neustart am Vortag war Zufall. Und die sechs Partner erklärten sich ganz ohne zentrale Ursache: Dieselbe Runtime wurde in derselben Nacht über die Patch-Kataloge in viele Netze verteilt, im üblichen Fenster um zwei Uhr.

Der Deppen-Moment

Die ehrlichste Zeile aus dem Call war sinngemäß: Wenn das jetzt nur an den Kundensystemen liegt, mache ich mich beim Hersteller zum Deppen.

Genau so war es. Es war ein bisschen peinlich, und es war in Ordnung. Diese Sorge hat die eigene Nachprüfung angetrieben, statt auf die Sitzung mit der Entwicklung zu warten. Wir haben die Sitzung abgesagt, das Ticket selbst zurückgezogen und die Update-Details mitgeliefert: Ursache gefunden, kein Veeam-Fehler.

Die Antwort des Engineers: kein Known Issue, weil Datenbank-Updates außerhalb des Veeam-Supports liegen. Aber man nehme den Fall in die interne Falldatenbank auf, für das nächste Mal. Derselbe Engineer, der das Ticket in Minuten gezogen hatte, nahm den Rückzieher genauso schnell an. Beides hat denselben Grund: Beim ersten Fall hatten wir Beweise geliefert statt Vermutungen.

Die Heilung

Die Reihenfolge, im Call auf einem zweiten System live geprüft:

  1. PostgreSQL starten
  2. 45 Sekunden warten
  3. Den Management Agent neu starten

Nach wenigen Minuten ist das System in der Konsole wieder da. Der Partner hat das als Skript über sein RMM auf alle Systeme mit Veeam ausgerollt. Von der Meldung bis zur geprüften Lösung vergingen rund 20 Stunden. Der erste Fall hatte siebzehn Tage gedauert, und ohne ihn wäre auch dieser nicht so schnell gegangen.

Noch am selben Tag ist daraus ein Leitfaden für unsere Partner entstanden: Agent getrennt? Erst die Datenbank prüfen, dann die letzte Patchnacht, dann das Netz.

Was wir daraus mitnehmen

  1. Gleiches Symptom heißt nicht gleiche Ursache. Läuft die Datenbank? Was wurde letzte Nacht gepatcht? Ist das Netz offen? Das kommt vor jeder Eskalation, gerade wenn das Muster bekannt vorkommt.
  2. App-Patching gehört auf Backup- und Datenbankservern an die Leine. Runtime-Updates wie Visual C++ oder .NET stoppen über den Restart Manager Dienste und starten sie nicht garantiert wieder. Also ausnehmen, in ein Wartungsfenster mit Neustart legen oder hinterher prüfen.
  3. Ein gestoppter Kerndienst darf nicht 32 Stunden unbemerkt bleiben. Überwachung mit Alarm und Startversuch für PostgreSQL, den Management Agent und die Veeam-Kerndienste. Das hätte aus 20 Stunden eine Minute gemacht.
  4. „Neustart später" ist eine Schuld. Wer den Neustart verschiebt, muss ihn auch einplanen.
  5. „Agent getrennt" hat fast nie mit dem Agent zu tun. Das galt beim ersten Fall, und es galt hier.