True IT Stories

Drei Wochen mit Veeam R&D

TL;DR

  1. Evidenz statt Symptom. Erst ein Mitschnitt auf Paketebene brachte den Fall vom Support zu R&D.
  2. Ein Fix kann einen alten Schaden sichtbar machen. Der Hotfix ließ den Agent wieder herein und legte damit einen Fehler aus der eigenen Fehlersuche frei.
  3. Der Fehler steht heute in den Release Notes. Behoben ist er in VSPC 9.3 Patch 1. Wer älter fährt, hat den Fix nicht.

Vom 25. August bis zum 11. September lag bei uns die Verwaltungsebene der Cloud-Backups lahm. Die Sicherungen liefen die ganze Zeit. Die Portal-Ebene darüber, die Veeam Service Provider Console, kam nicht mehr an unseren Cloud-Connect-Server heran. Die einzelnen Etappen stehen in einer eigenen Reihe. Dieser Beitrag zieht Bilanz: Was haben wir als Provider aus siebzehn Tagen Zusammenarbeit mit dem Hersteller gelernt?

Die Reihe

Wie man zu R&D kommt

Der Support schlägt zuerst vor, was meistens hilft: neu verbinden, neu installieren, neu registrieren. Wir haben die ganze Leiter abgearbeitet und jede Stufe mitgeschrieben. Der Fehler kam jedes Mal beim ersten Handshake wieder.

Das hat den Fall weitergebracht, nicht die Dringlichkeit. Ein Protokoll, das dreimal dasselbe zeigt, lässt sich nicht mit einer weiteren Neuinstallation beantworten. Es landet bei den Entwicklern.

Was R&D geliefert hat

Einen Hotfix nach acht Tagen. Eine einzelne Bibliothek, an zwei Stellen einzuspielen. Danach verband sich der Agent in unter einer Sekunde.

Eine Ursache. Bei sehr vielen gleichzeitigen Agent-Verbindungen blieb die Verarbeitung der Handshakes hängen. Ein Windows-Update, das wir tagelang im Verdacht hatten, war laut R&D am Ende unbeteiligt.

Ein Skript für die Folgeschäden. Nach dem Hotfix fehlten alle Zuweisungen der Reseller. Sie waren nicht gelöscht, sondern nur als gelöscht markiert. Ausgelöst hatte das unsere Neuinstallation des Agents aus der Fehlersuche, wirksam wurde es erst mit dem Hotfix. Das Skript von R&D stellte die Zuweisungen wieder her, mit einem Probelauf vorab. Funktioniert hat es erst mit dem Datenbankstand von vor dem Vorfall, und den hatten nur wir, in unserer eigenen Sicherung.

Einen offiziellen Patch. Seit dem 4. September steht der Fehler in den Release Notes zu VSPC 9.3 Patch 1 (KB4788 , Build 9.3.0.35706):

„When a large number of management agents connect to the Veeam Service Provider Console Portal at the same time, the management agent installed on the Veeam Cloud Connect server can be disconnected.“

Was wir mitnehmen

  • Wer Beweise schickt, kommt zu R&D. Wer nur Symptome schickt, bekommt die nächste Neuinstallation vorgeschlagen.
  • Jeden abgestimmten Schritt aufschreiben. Ohne unsere Chronologie hätte niemand nachweisen können, wann die Zuweisungen gebrochen sind.
  • Vorschläge des Herstellers prüfen. Freundlich, aber gegen die eigenen Daten.
  • Die eigene Datenbank so sichern, dass ein Stand von vor dem Vorfall zurückkommt. Daran hing am Ende die Wiederherstellung.
  • Den Management Agent am Cloud-Connect-Server nicht deinstallieren, solange der Support es nicht ausdrücklich anleitet. Das Verhalten ist dokumentiert, man liest es aber erst, wenn es zu spät ist.
  • Eskalieren, wenn der Engineer selbst darum bittet. Dann hilft es, ohne die Arbeitsebene zu beschädigen.

Warum jetzt auf 13.1?

13.1 ist nicht fehlerfrei, und dieser Beitrag behauptet das auch nicht. Die Geschichte ist eine andere: Ein Provider findet einen Fehler, belegt ihn, und der Hersteller behebt ihn.

Der Fix kam bei uns als Patch 1 für VSPC 9.3. Veeam stellt VSPC 9.3 zusammen mit Veeam Data Platform 13.1 vor. Unseren Cloud-Connect-Server haben wir mitten in der Störung auf Backup & Replication 13.1.1.18 gebracht.

Warum also jetzt? Weil ein Fehler, den jemand anders schon gefunden und bewiesen hat, nur dem nicht mehr passiert, der den Fix eingespielt hat. Wer die Kette auf dem aktuellen Stand hält, hat den Eintrag aus den Release Notes installiert, bevor er das Symptom überhaupt sieht.