Das Backup-Unternehmen, das sich mit dem eigenen Backup rettete
Der Hotfix war eingespielt, der Agent verbunden, der Server „Healthy". Die Erfolgsmeldung an die Partner lag fertig im Entwurf. Wir klickten noch einmal durch die Konsole, um sie mit gutem Gewissen abzuschicken.
Alle Reseller-Zuweisungen waren weg. Rund dreißig Partner, überall „Not assigned". Kontingente zeigten „15 out of 0 (N/A)". Jede Änderung scheiterte mit einer Meldung, die auf eine Site-ID verwies, die niemand kannte.
Die Kundenzuordnungen waren intakt, die Verbrauchsdaten auch. Aber die komplette Ebene dazwischen — welcher Partner welches Repository mit welchem Kontingent hat — war tot.
Das ist der dritte Teil. Der erste handelt von der Fehlermeldung, die auf das falsche Problem zeigte, der zweite vom Paketmitschnitt, der den Fall zur Entwicklung brachte.
Die ehrlichste Mail der Serie
Sie ging noch am selben Tag raus: Ich habe mich zu früh gefreut. Selbstservice bleibt gesperrt, das Ticketverfahren gilt weiter.
Es war nicht das erste Mal in diesem Fall. Schon am ersten Tag hatten wir zweimal „alles grün" gemeldet und es zweimal zurückgenommen, einmal nach vier Minuten. Ab hier galt deshalb ein Prinzip ohne Ausnahme: Endgültige Entwarnung erst nach eigener Verifikation — in beide Richtungen. Nicht „die Konsole zeigt grün", sondern „wir haben etwas geändert, und es ist unten angekommen".
Nichts anfassen. Bis auf eins.
Wir luden ein frisches Datenbank-Backup zum Hersteller hoch. Vierzig Gigabyte, in neun Teile gesplittet — Nebenbefund: Das Bordmittel-Zip von PowerShell scheitert an der Zwei-Gigabyte-Grenze, 7-Zip rettet.
Und wir trafen eine Entscheidung, die sich später auszahlte: Wir fassen nichts an. Keine Reparaturversuche an dreißig Zuweisungen, die wir nicht verstanden. Mit einer Ausnahme: einen einzigen Reseller haben wir bewusst von Hand neu zugewiesen, zwei Einträge — als Referenzmuster, um zu sehen, wie ein korrekter Eintrag nach dem Fix aussieht.
Der Hersteller relativierte die Kausalität: kein ausreichender Beleg, dass der Hotfix die Zuweisungen zerstört habe. Wir hielten die Chronologie schriftlich dagegen: Zuweisungen intakt bis zum Fix, Server nie aus der Konsole entfernt — laut Hersteller der einzige bekannte Weg, sie zu verlieren —, Bruch exakt mit der Neuregistrierung.
Der zähe Teil
Die Termine rissen weiter. Aus dem ersten verschobenen Termin wurden drei, jeder mit derselben Formel: still investigating.
Und eine neue Zeitbombe: 27 von 285 Mietlizenzen liefen in wenigen Tagen ab. Der Mechanismus: Lizenzen verlängern sich mit jedem verarbeiteten Monatsbericht automatisch um dreißig Tage. Kein Bericht, keine Verlängerung — und der Berichtszyklus hing seit dem ersten Ausfall. Die erste nervöse Reseller-Anfrage kam prompt. Die Recherche beruhigte — sechzig Tage Kulanz, keine Sicherung stoppt — aber ab dem folgenden Montag hätten Warnungen auf Kundenkonsolen gestanden.
Also die pragmatische Entscheidung: vorläufig abrechnen und vorläufig an den Distributor melden, auf der besten verfügbaren Datenbasis, mit angekündigter Korrektur. Das Sicherheitsnetz war die schriftliche Zusage aus dem zweiten Teil. Prompt zogen sich die ersten Systeme wieder frische Lizenzen — der Zyklus sprang an.
Die Eskalation, um die der Engineer bat
Formale Eskalationen hatten wir bis dahin bewusst vermieden. Erfahrungswert: Sie bringen oft nichts und vergiften die Arbeitsebene, auf der die eigentliche Arbeit passiert.
Dann schrieb der Support-Engineer selbst: „feel free to escalate via Talk to a Manager". Übersetzt: Ich komme intern nicht durch, macht Druck von oben.
Das haben wir getan, mit zwei Sätzen. Der eine: Wir bitten nicht um einen weiteren Termin, wir bitten darum, dass sich jemand den Fall ansieht und liefert. Der andere: Es geht um die Priorisierung in der Entwicklung, nicht um die Qualität des Supports — eine Schutzklausel für den Engineer, der uns die Tür geöffnet hatte.
Ein Support-Manager antwortete substanziell. Es war die erste Antwort oberhalb der Arbeitsebene, die auf den Fall selbst einging.
Eskalation wirkt am besten, wenn der Engineer selbst darum bittet — und man ihn dabei schützt.
Das fehlende Puzzlestück
Ein neuer Engineer übernahm und lieferte auf alle offenen Punkte. Manuelles Zuweisen freigegeben. Ursache des ersten Akts endgültig benannt: ein Deadlock in der Handshake-Verarbeitung bei sehr vielen gleichzeitigen Verbindungen — serverseitig also, wie wir im zweiten Teil geschlossen hatten, nur nicht in der Datenbank, sondern im Verbindungsdienst. Die Microsoft-Updates hielt die Entwicklung inzwischen für unbeteiligt.
Aber: Das Skript der Entwicklung zur automatischen Wiederherstellung scheiterte an einer Vergleichsbasis. Es brauchte den Datenbankstand von vor dem Vorfall. Unser Upload war von danach.
Moment.
Wir sind ein Backup-Unternehmen. Unser SQL-Server wird — selbstverständlich — von unserem eigenen Veeam gesichert, alle vier Stunden. In der Historie lag ein Wiederherstellungspunkt vom Morgen des Hotfix-Tages, 08:03 Uhr. 72 Minuten, bevor der Hotfix eingespielt wurde.
Die Lösung des Veeam-Falls lag in unserem eigenen Veeam-Backup.
Ein Vormittag mit zwei Datenbanken
File-Level-Restore der Datenbankdateien, als Kopie neben die Produktion gehängt. Dann SQL, nur lesend, Tabelle für Tabelle, bis die gefunden war, in der die Reseller-Zuweisungen leben.
Vor dem Vorfall: dreißig Einträge, alle intakt.
In der Live-Datenbank daneben: dreißig verwaiste Einträge, die auf die alte Objekt-ID des Servers zeigten — plus unsere zwei Referenzeinträge, die korrekt auf die neue zeigten.
Und damit ergab die Fehlermeldung endlich Sinn, andersherum als gedacht. Die ID darin war das neue Objekt, nicht das verlorene alte. Die Konsole suchte auf der neuen Site nach Ressourcen und fand keine, weil alle Zuweisungen noch auf die alte zeigten. Tagelang hatten wir die Rollen der beiden IDs verdreht.
Bonus: Eine der dreißig Zeilen war eine Datenleiche, ein 2024 gelöschter Reseller. Also 29 echte, eine Leiche. Wir zogen die komplette Liste: jeder Reseller, sein Repository, sein ursprüngliches Kontingent. Nur drei von dreißig hatten überhaupt echte Limits. Mit dieser Liste wäre selbst die Handarbeit nur noch Stunden gewesen, nicht Tage.
Hochgeladen an den Hersteller, mit Ansage: Das fehlende Puzzlestück ist da, dazu unsere Kartierung. Aus „die Entwicklung kann nicht, weil die Vergleichsbasis fehlt" wurde innerhalb weniger Stunden „die Entwicklung hat alles — was fehlt noch?".
14 Uhr, Remote-Session
Der Engineer brachte das Skript der Entwicklung mit, im Labor bereits auf dem hochgeladenen Vor-Vorfall-Stand getestet. Sauber gebaut: ein Probelauf-Modus, der unsere zwei Referenzeinträge und die Datenleiche erkannte und übersprang.
Und es enthüllte den Mechanismus. Die Zuweisungen waren nie gelöscht worden. Sie waren soft-deleted — ein Löschdatum gesetzt, die Zeile noch da. Deshalb „Not assigned" in der Konsole, deshalb waren sie im Backup und in der Live-Datenbank gleichermaßen vorhanden.
Dann die eigentliche Ursache des zweiten Akts, endlich offiziell: Wird der Management-Agent auf einem Cloud-Connect-Server deinstalliert, gehen die Reseller-Zuweisungen verloren. Dokumentiertes Verhalten, seit Jahren, steht im Handbuch.
Unsere fabrikneue Installation aus dem zweiten Teil — die sechste Sprosse der Leiter, mit dem Support abgestimmt — war die scharfgestellte Bombe. Gezündet hat sie erst, als der Hotfix die Registrierung wieder durchließ. Den Vorschlag des Supports, den Server aus der Konsole zu entfernen, hatten wir abgelehnt, um genau diese Zuweisungen zu schützen. Derselbe Mechanismus hat sie durch die Hintertür trotzdem erwischt.
Den Management-Agent eines Cloud-Connect-Servers niemals ohne ausdrückliche Anleitung des Supports deinstallieren. Es kostet die Reseller-Zuweisungen, und es steht im Handbuch.
Der Fix dafür ist ebenfalls im neuen Build.
Skript läuft. Alle Zuweisungen zurück. Die Kontingente stimmen aufs Gigabyte mit unserer Liste vom Vormittag überein.
Mitten in der Session platzte übrigens die kleine Tochter ins Homeoffice und diktierte dem Engineer „Melone, Banane, Kakadu" ins Protokoll. Der Fall hatte auch seine leichten Momente.
Erst prüfen, dann Entwarnung
Die Kette in Schreibrichtung: Kontingentänderung im eigenen Reseller-Konto über den Selbstservice, von 103 auf 50 Terabyte. Binnen Minuten stand der neue Wert unten auf der Cloud-Connect-Infrastruktur. Beide Richtungen funktionierten.
Jetzt erst ging die Entwarnung raus. Siebzehn Tage nach der ersten Störung.
Was in den Release Notes steht
In den Release Notes der Veeam Service Provider Console 9 steht seit Build 9.3.0.35706 unter „Resolved Issues":
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.
Soweit wir wissen, geht der Eintrag auf unseren Fall zurück: Der Fix wurde dafür gebaut, und das Symptom ist wörtlich unseres. Jeder Cloud-Provider, der künftig darüber stolpert, findet eine Lösung.
Hotfix nach acht Tagen, ein Skript aus der Entwicklung, ein offizieller Fix — mehr kann man von einem Hersteller in so einem Fall nicht verlangen. Die Termine hat er trotzdem gerissen, und das haben wir ihm gesagt.
Was bleibt
Das eigene Backup ist auch für den eigenen Betrieb da. Wir predigen kurze Sicherungsintervalle für Datenbanken. Vier Stunden haben uns 72 Minuten Vorsprung gegeben.
Wer eine Sofortmaßnahme empfiehlt, muss wissen, was daran hängt. Die Neuinstallation war mit dem Support abgestimmt. Dass sie die Zuweisungen kostet, stand im Handbuch — wir hatten es nicht gelesen, und der Support hat nicht gewarnt.