Proton-Ausfall: Was der Kühlungskollaps offenlegt

Der Ausfall von Proton am 27. August 2026 führt eindringlich vor Augen, dass Redundanz auf eine Weise versagen kann, die in klassischen Failover-Konzepten selten abgebildet ist. Ein Totalausfall der Klimakühlung im Frankfurter Rechenzentrum ließ die Raumtemperatur in weniger als 30 Minuten von 21.8°C auf 51.9°C emporschnellen. Hardware fiel Komponente für Komponente aus, und Ingenieure mussten unter hohem Zeitdruck abwägen, ob sie den Dienstbetrieb erzwingen oder die physische Hardware retten sollten.

Proton veröffentlichte am Folgetag einen bemerkenswert transparenten Vorfallsbericht, sodass man nicht auf Spekulationen angewiesen ist. Der Ablauf liefert konkrete Temperaturverläufe, Ausfallmuster, Datenbankentscheidungen und Ursachenanalysen, die weit mehr Erkenntnisse vermitteln als allgemeine Phrasen über das Vorhalten redundanter Systeme.

Was war die eigentliche Ursache für den Proton-Ausfall?

Laut Proton war die primäre Ursache ein vollständiger Ausfall des Kühlsystems im Frankfurter Rechenzentrum. Die spätere Untersuchung ergab, dass die Störung durch einen Luftfilterwechsel ausgelöst wurde, der zeitgleich an beiden redundanten Luftkompressoren der Kälteanlage durchgeführt worden war.

Dem Bericht zufolge führte der Rechenzentrumsbetreiber diese Wartungsarbeiten mitten in der Nacht ohne vorherige Ankündigung an Proton durch. Zudem versäumte es der Betreiber, den Ausfall der Kühlung umgehend zu melden, als dieser eintrat. Dadurch verstrich wertvolle Reaktionszeit, bevor das On-Call-Team von Proton eingreifen konnte.

Die erste fundamentale Lektion: Zwei nominell redundante Komponenten teilen sich häufig dennoch denselben Wartungsprozess, denselben Dienstleister, dieselbe Arbeitsanweisung oder dieselbe menschliche Fehlentscheidung. Werden beide Pfade zeitgleich angefasst, existiert Redundanz zwar auf dem Schaltplan, nicht jedoch in der betrieblichen Realität.

In unserem Rechenzentrums- und AIOps-Bereich zählen genau solche verdeckten Abhängigkeiten zu den kritischsten Risikofaktoren.

Wie schnell wurde die Überhitzung gefährlich?

Der Hauptserverraum heizte sich in weniger als einer halben Stunde von etwa 21.8°C auf 51.9°C auf; einzelne Sensoren im Raum registrierten sogar 60°C Lufttemperatur. Mit steigender Hitze fielen Server und Netzwerk-Switches nacheinander aus.

Dieses Tempo überraschte selbst ein Team, das explizit auf Rechenzentrumsausfälle vorbereitet war. Proton betont, dass die gestiegene Leistungsdichte moderner Server die thermischen Zeitfenster radikal verkürzt hat: Was früher drei oder vier Stunden gedauert hätte, wurde bei diesem Vorfall innerhalb von rund 20 Minuten geschäftskritisch.

Das verändert Einsatzpläne grundlegend. Hochdichte CPUs und GPUs geben enorme Wärmemengen in denselben Raum ab. Fällt die aktive Kühlung weg, schrumpft der thermische Puffer auf einen Bruchteil früherer Annahmen. Ein Notfallkonzept, das nach einem Kälteausfall von einer Stunde stabiler Restlaufzeit ausgeht, ist strukturell fehlerhaft, wenn das reale Zeitfenster in Minuten gemessen wird.

Warum konnte die Redundanz den Ausfall nicht verhindern?

Proton verfügte über redundante Systeme und ausreichende Gesamtkapazitäten, um den Totalausfall eines Standorts abzufangen. Der reale Ausfall verlief jedoch schleichend, asymmetrisch und unübersichtlich: Komponenten fielen unregelmäßig aus, was nicht dem sauberen Zustand „Standort verfügbar oder nicht verfügbar" entsprach, für den automatisierte Failover-Routinen optimiert sind.

Die Störung eskalierte für Endnutzer, als auf einem kritischen Rack zeitgleich der primäre und der sekundäre Netzwerk-Switch den Hitzetod starben. Genau in diesem Rack befanden sich mehrere primäre Datenbankinstanzen.

Die meisten Proton-Dienste schalten vollautomatisch um, doch das Failover primärer Datenbanken erfordert zwingend menschliche Freigaben. Proton begründet dies mit dem Schutz vor Split-Brain-Zuständen, bei denen Datenbestände nach Netzwerkunterbrechungen auseinanderlaufen und sich später kaum noch konsistent zusammenführen lassen.

Diese Entwurfsentscheidung ist legitim, bedeutet jedoch, dass die Wiederherstellungsgeschwindigkeit davon abhängt, ob Ingenieure unter Extrembedingungen ausreichend Zeit und verlässliche Telemetriedaten besitzen, um die richtige Replikatskopie auszuwählen.

Warum war die Entscheidung zwischen Frankfurt und Zürich so heikel?

Das Notfallteam musste entscheiden, ob die Datenbanken auf verbliebene Replikate in Frankfurt oder auf Standorte in Zürich umgeschaltet werden sollten. Ein lokales Failover in Frankfurt böte geringere Latenzen und weniger Störungen für Nutzer, doch ein Replikat im selben überhitzten Gebäude drohte Augenblicke später ebenfalls thermisch abzuschalten.

Um 00:45 Uhr MESZ war die Kühlung wiederhergestellt und die Temperaturen begannen zu sinken. Proton entschied sich dafür, intakte Frankfurter Replikate weiterzunutzen und nur dort nach Zürich zu wechseln, wo vor Ort keine funktionsfähige Instanz mehr existierte, auch um massive Routing-Änderungen während der akuten Instabilität zu vermeiden.

Das stellte den Betrieb jedoch nicht schlagartig wieder her: Zahlreiche Netzwerkkarten hatten Temperaturen von 105°C erreicht, verglichen mit einer regulären Betriebstemperatur von etwa 45°C. Die Karten schalteten in thermische Schutzmodi und verlangten einen vollständigen Kaltstart der betroffenen Server.

Zusätzlich verlangten Protons strikte Sicherheitsvorgaben für Out-of-Band-Managementschnittstellen die Einbindung weiterer Spezialisten. Das illustriert einen weiteren Kompromiss: Strenge administrative Zugriffshürden minimieren das Angriffsrisiko, verlangsamen jedoch die Notfallrettung, wenn der Zugangspfad nicht für Standortkrisen optimiert ist.

Gab es bei Proton Datenverlust?

Proton bestätigte, dass keine E-Mails verloren gingen. Der E-Mail-Empfang und -Versand verzögerte sich spürbar, und unkritischere Hintergrunddienste wie Push-Mitteilungen und Zahlungsabwicklungen benötigten mehr Zeit zur Erholung.

Gegen 01:30 Uhr MESZ waren die Kernfunktionen für die Mehrheit der Nutzer wieder erreichbar, verbleibende Systeme folgten bis etwa 02:00 Uhr MESZ. Die eigentlichen Aufräumarbeiten dauerten jedoch an: Primäre Datenbanken liefen verteilt zwischen Zürich und Frankfurt, und mehrere Cluster arbeiteten mit reduzierter Redundanz.

Vorfallsberichte sollten diese Zustände sauber trennen: Eine Plattform kann für Anwender wieder erreichbar sein, während ihre Infrastruktur hochgradig fragil bleibt und das Betriebsteam nur einen Hardwarefehler vom nächsten Ausfall entfernt ist.

Dasselbe Prinzip gilt für Datensicherungen: Ein erfolgreicher Backup-Lauf beweist lediglich, dass Daten geschrieben wurden; erst ein getesteter Restore belegt, dass man sie im Ernstfall zurückerhält. Unser Proxmox Backup Server Leitfaden widmet sich genau dieser Trennung, da im Ernstfall allein der Wiederherstellungszustand zählt.

Was lehrt dieser Vorfall über Kühlungsredundanz?

Kühlungsredundanz muss Wartungsabläufe und Betriebsprozesse ebenso umfassen wie doppelt vorhandene Aggregate. Wenn zwei Kompressoren redundant ausgelegt sind, jedoch zeitgleich derselben Wartungsmaßnahme unterzogen werden, schafft der Prozess eine gemeinsame Ausfalldomäne.

Ein Audit sollte klären: Wer darf Kältepfade außer Betrieb nehmen? Welche Alarmmeldungen erreichen Kunden direkt? Ist die thermische Telemetrie unabhängig vom Betreiber des Rechenzentrums einsehbar? Und welche automatisierten Maßnahmen starten, wenn Temperaturschwellen überschritten werden?

Zudem muss die reale thermische Überlebenszeit moderner Serverbestände ermittelt werden. Übernehmen Sie keine historischen Erfahrungswerte aus Zeiten geringerer Leistungsdichte, sondern messen oder simulieren Sie das Verhalten bei aktuellen Rack-Leistungen.

Schließlich muss definiert werden, wie ein schleichender Standortausfall für Automatisierungssysteme aussieht. Ein unvollständiger, fortschreitender Hitzeausfall ist für Regelsysteme ungleich schwerer zu handhaben als ein harter Stromausfall, weil jede Entscheidung Systeme berücksichtigen muss, die im nächsten Moment ausfallen können.

Was nach Protons Postmortem zu testen ist

Testen Sie ein Kälteausfallszenario, das von lediglich 20 Minuten Vorwarnzeit ausgeht, bevor Hardware unberechenbar reagiert. Das zwingt Teams zu klären: Welche Systeme werden zuerst heruntergefahren? Welche Dienste schalten automatisch um? Welche Datenbanken verlangen manuelle Freigaben und reicht die Kapazität am Ausweichstandort tatsächlich aus?

Überprüfen Sie gemeinsame Wartungsabhängigkeiten: Können redundante Strom-, Kälte-, Netzwerk- oder Storage-Pfade von einem einzigen Dienstleister über ein einziges Wartungsticket bearbeitet werden? Falls ja, ist die angebliche Redundanz eine Fiktion.

Erproben Sie Out-of-Band-Zugänge unter Notfallbedingungen. Hohe Sicherheitsstandards müssen gewahrt bleiben, doch Notfallzugriffe dürfen nicht davon abhängen, ob mitten in der Nacht eine bestimmte Schlüsselperson erreichbar ist.

Sich allein auf automatisches Site-Failover zu verlassen, funktioniert nur, wenn die Softwarearchitektur einen Standort als binäre Einheit begreift. Protons Vorfall zeigt, dass moderne Hochdichte-Infrastruktur im Ernstfall selten in so bequemen Mustern versagt.