Der OVHcloud-Brand zeigte, dass Datenlokalität keine Katastrophentrennung ist

Zusammenfassung

• Feueralarme wurden am 10. März 2021 um 00:35 am Straßburger Standort von OVHcloud ausgelöst. Der Brand begann in Energieräumen im Erdgeschoss von SBG2, zerstörte dieses Gebäude, beschädigte vier der zwölf Räume von SBG1 und erzwang eine Stromabschaltung auf dem gesamten Campus. SBG3 und SBG4 wurden nicht vom ursprünglichen Brand erfasst, aber ihre Dienste waren nicht verfügbar, da eine elektrische Isolation, Sicherheitsinspektion, Reinigung und ein gestaffelter Neustart erforderlich waren. Es gab keine Todesfälle oder Verletzten.
• Die französische Untersuchung zur Industriesicherheit konnte die genaue Ursache der nahezu gleichzeitigen elektrischen Störungen an einer USV und den dazugehörigen Bleibatterien nicht ermitteln. Sie stellte jedoch Ausbreitungs- und Reaktionsfaktoren fest: kein automatisches Löschsystem in den fünf Straßburger Gebäuden, schnelle Rauchausbreitung durch die offene kühlungsorientierte Bauweise von SBG2, begrenzte Löschwasserkapazität und eine schwierige standortweite Stromabschaltung. Funktionierende Detektion, nächtliches Personal, feuerbeständige Trennungen zum Schutz von SBG3 und der Einsatz eines leistungsstarken deutsch-französischen Löschboots verhinderten schlimmere Folgen.
• Verfügbarkeitsverlust und dauerhafter Datenverlust waren unterschiedliche Ergebnisse. OVHcloud meldete etwa 65.000 betroffene Kunden und 120.000 gestörte Dienste, während Netcraft grob 3,6 Millionen Websites auf 464.000 Domains offline sah. OVHcloud sagte, viele Kunden, die Daten verloren, hätten kein optionales Backup ausgewählt. Das schließt die Frage der Verantwortlichkeit nicht ab: OVHclouds eigenes Registrierungsdokument besagte, dass angebotene Backups im selben oder einem anderen Rechenzentrum gespeichert werden konnten, und ein späteres Berufungsurteil betraf einen Kunden, dessen bezahltes automatisiertes Backup im selben Gebäude wie die Produktion zerstört wurde.
• Das Ereignis offenbarte einen Kategoriefehler im Cloud-Beschaffungswesen. Datensouveränität, Rechtshoheit, Latenz, Verfügbarkeit, Backup und Disaster Recovery sind verwandt, aber nicht austauschbar. Das Speichern von Daten in Frankreich oder der Europäischen Union kann eine Lokalitätspolitik erfüllen, während Produktions- und Wiederherstellungskopien eine gemeinsame physische Gefahr teilen. Umgekehrt kann eine geografisch entfernte Kopie innerhalb desselben Rechtsgebiets und unter denselben europäischen Kontrollen bleiben.
• OVHcloud gab umfangreiche Änderungen nach dem Brand bekannt, darunter breitere automatische Löschsysteme, stärkere Abschnitte, separate Energieräume, ferngesteuerte Stromabschaltungen, Standortaudits, Zusammenarbeit mit Feuerwehren sowie neue Multi-Zonen- und Fernbackup-Optionen. Ein rechenschaftspflichtiger Abschluss erfordert jedoch dienst- und standortspezifische Nachweise: abgeschlossene Kontrollabdeckung, unabhängige Inspektion, realistische Brand- und Stromisolationstests, deklarierte Backup-Standorte, erfolgreiche Wiederherstellungstests und den Nachweis, dass die Kundenwiederherstellung nicht von der beschädigten Region oder derselben Steuerungsebene abhängt.

Ein physischer Brand wurde zu einem Cloud-Verantwortlichkeitsereignis

Der Ausdruck „Daten in der Cloud“ fördert eine Abstraktion. Er ist nützlich, wenn Ingenieure eine einheitliche Schnittstelle zu Rechenkapazitäten benötigen, aber gefährlich, wenn Entscheidungsträger beginnen, Standort, Strom und Feuer als Details anderer zu behandeln. Jeder virtuelle Server befindet sich in einem Raum. Jedes Speicherreplikat belegt Geräte, die an elektrische und Kühlsysteme angeschlossen sind. Jeder Wiederherstellungsworkflow hängt von Menschen, Netzwerken, Anmeldeinformationen, Katalogen und einem Ort ab, von dem Ersatzkapazität bezogen werden kann.

Straßburg machte diese physische Kette sichtbar. In den frühen Morgenstunden des 10. März 2021 zerstörte ein Feuer SBG2, eines der Gebäude auf dem OVHcloud-Campus am Port du Rhin. SBG1 wurde teilweise zerstört. Die beiden anderen Rechenzentren auf dem Gelände wurden heruntergefahren, obwohl das erste Unternehmensupdate sie als unbeschädigt beschrieb. Der Verlust erfolgte daher über mindestens drei verschiedene Mechanismen: Ausrüstung wurde physisch zerstört; Ausrüstung in benachbarten Gebäuden wurde Hitze, Rauch, Wasser oder Unsicherheit ausgesetzt;

und gesunde Ausrüstung wurde unverfügbar, als das Gelände elektrisch isoliert und gesichert werden musste.

Diese Mechanismen sind wichtig, weil sie verschiedenen Kontrollen entsprechen. Automatische Löschsysteme und Brandabschnitte können ein Feuer eindämmen. Unabhängige Stromzonen können den Bereich verkleinern, den Feuerwehrleute trennen müssen. Eine Multi-Standort-Anwendung kann weiterlaufen, während ein Standort nicht verfügbar ist. Ein entferntes, verifiziertes Backup kann den Wiederaufbau unterstützen, nachdem Daten zerstört wurden. Eine Statusseite kann Kunden durch diese Optionen führen. All dies als „Redundanz“ zu bezeichnen, verbirgt, wer jede Ebene kontrolliert und welches Ereignis sie überstehen kann.

Die maßgeblichste öffentliche Rekonstruktion ist der Untersuchungsbericht des französischen Bureau d’enquêtes et d’analyses sur les risques industriels (BEA-RI) vom Mai 2022 (Link). Sein Auftrag war die Prävention, nicht die Zuweisung zivil- oder strafrechtlicher Haftung. Diese Grenze ist wichtig. Der Bericht kann Beobachtungen, mögliche Ursachen, beitragende Faktoren und Sicherheitsempfehlungen feststellen. Er kann nicht in ein gerichtliches Urteil umgewandelt werden, dass jede identifizierte Schwachstelle fahrlässig war oder dass eine Schwäche rechtlich den Verlust eines bestimmten Kunden verursacht hat.

Verantwortlichkeitsanalyse stellt eine verwandte, aber breitere Frage: Welche Akteure hatten Autorität über die Bedingungen, die es einem nächtlichen Geräteereignis ermöglichten, zu einem gebäudeübergreifenden Ausfall, einer verlängerten Wiederherstellung und irreversiblem Kundenverlust zu werden? OVH kontrollierte das Design und den Betrieb des Standorts, die angebotenen Produkte, die Genauigkeit ihrer Beschreibungen und die Reaktion. Kunden kontrollierten die Workload-Klassifizierung, Architektur, viele Dienstauswahlen und unabhängige Kopien. Regulierungsbehörden und Berufsverbände kontrollierten Teile des Mindestrahmens.

Keine dieser Rollen löscht die anderen aus.

Was die Beweise belegen und was nicht

Der BEA-RI-Bericht setzt den ersten Alarm um 00:35 Uhr. Ein Wachmann erreichte um 00:37 Uhr einen Energieraum von SBG2 und fand dichten schwarzen Rauch. Das Gebäude wurde um 00:39 Uhr evakuiert, die Feuer- und Rettungsdienste des Bas-Rhin wurden um 00:42 Uhr gerufen, und die ersten Einsatzkräfte trafen um 00:59 Uhr ein. OVHs öffentliche Vorfallseite verwendete 00:47 Uhr als Zeitpunkt des Brandausbruchs.

Der Unterschied sollte beibehalten werden, anstatt in einen Zeitstempel gezwungen zu werden: Die Sicherheitsuntersuchung hatte Zugang zu Alarm- und Betriebsaufzeichnungen, während die Unternehmensseite eine öffentliche Vorfallsmarkierung lieferte.

Die Notstromversorgung von SBG2 wurde um 01:13 Uhr unterbrochen, die von SBG1, SBG3 und SBG4 um 01:28 Uhr. Feuerwehrleute hatten Lichtbögen gesehen und zögerten den Wasser Einsatz hinaus, bis das Risiko kontrolliert werden konnte. Um 01:42 Uhr hatte sich das Feuer über das erste Stockwerk ausgebreitet. Gegen 02:00 Uhr meldeten Feuerwehrleute eine vollständige Beteiligung von SBG2. Das leistungsstarke Löschboot EUROPA traf gegen 03:00 Uhr ein und schöpfte aus dem angrenzenden Wasserweg. Das Feuer wurde um 10:02 Uhr gelöscht, und der Einsatz wurde um 18:13 Uhr als abgeschlossen betrachtet.

Die Untersuchung lokalisierte den Brandursprung in Räumen mit Batterien und unterbrechungsfreien Stromversorgungsanlagen. Video- und Überwachungsaufzeichnungen zeigten einen nahezu gleichzeitigen elektrischen Fehler an der USV-Einheit ASI2 und den dazugehörigen Batterien, die sich in getrennten Räumen befanden. An diesem Morgen gab es Wartungsarbeiten an der USV und später ungewöhnliche Feuchtigkeitsmessungen. Die Ermittler listeten mehrere Hypothesen auf, darunter Feuchtigkeit, wartungsbedingte Fehlfunktion oder Betrieb unter unerwarteten Bedingungen.

Sie stellten ausdrücklich fest, dass die Beweise nicht ausreichten, um eine genaue Auslöseursache zu bestimmen.

Diese Zurückhaltung wurde in Nacherzählungen, die ein undichtes Kühlsystem oder eine kürzlich gewartete USV als „Ursache“ des Feuers bezeichnen, oft verloren. Der offizielle französische ARIA-Unfallbericht (Link) ist eine nützliche Bestätigung für die Maschinenraumumgebung und die Reaktion, aber er macht aus einem plausiblen Mechanismus keine bewiesene Grundursache. Ein glaubwürdiger Bericht sollte sagen, dass die frühen elektrischen Ereignisse und der Ursprungsbereich bekannt sind; der Grund für diese Ereignisse wurde im veröffentlichten BEA-RI-Bericht nicht geklärt.

Die Unterscheidung verhindert keine Kontrollanalyse. Eine Organisation muss auf Geräteausfälle vorbereitet sein, ohne zu wissen, welche Komponente als nächstes ausfällt. Brandschutz ist auf diese Unsicherheit ausgelegt. Die rechenschaftspflichtige Frage ist nicht nur, ob OVH eine bestimmte elektrische Sequenz hätte vorhersagen sollen. Es ist, ob Erkennung, automatische Steuerung, Brandabschnitte, Wasser, elektrische Isolation, Gebäudedesign und Notfallverfahren den Menschen und angrenzenden Diensten nach einem Zündereignis genügend unabhängigen Schutz boten.

Das Gebäude erkannte Gefahr, konnte sie aber nicht eindämmen

Der Standort Straßburg erfüllte eine Lebenssicherheitsaufgabe gut. Optische und aspirierende Rauchmelder funktionierten. Nachtpersonal ermöglichte schnelle Überprüfung und einen frühen Anruf bei der Feuerwehr. Alle flohen, und es gab keine Verletzungen. Der BEA-RI-Bericht würdigt diese Kontrollen. Rechenschaft sollte erfolgreiche Barrieren ebenso beachten wie gescheiterte, da zukünftiges Design davon abhängt zu wissen, was tatsächlich Zeit verschafft hat.

Der Erkennung stand keine automatische Löschung gegenüber. Die Untersuchung ergab, dass keines der fünf Gebäude des Standorts über ein automatisches Brandschutzsystem verfügte. Die Batterie- und USV-Räume von SBG2 wurden überwacht, aber es gab kein System, das darauf ausgelegt war, das Feuer in seinem frühesten Stadium zu löschen, zu kontrollieren oder zu verzögern. Ein solches System hätte vor der vollständigen Stromabschaltung wirken können, ohne die Feuerwehrleute unter Spannung stehenden Geräten auszusetzen.

Es hätte die Löschung nicht garantiert, insbesondere in einem Elektroraum, aber es hätte die Wachstumskurve des Feuers verändern können.

Das Gebäude half dann Rauch und Hitze sich auszubreiten. SBG2 verwendete eine offene, turmartige Kühlungsbauweise, die für Außenluft hoch durchlässig war. Innerhalb von fünfzehn Minuten nach dem ersten Ereignis hatten aspirierende Melder auf jeder Ebene ausgelöst. Der BEA-RI warnte, dass die Melderzeit auf Rauch, nicht unbedingt auf Flammen hinweist, schloss jedoch, dass die Bauweise eine schnelle Rauchausbreitung ermöglichte. Innerhalb von etwa neunzig Minuten war SBG2 allgemein betroffen.

Der Vergleich mit dem benachbarten SBG3 war lehrreich: zweistündige feuerbeständige Wände und eine Brandschutztür, zusammen mit Löschwasser, hinterließen es weniger beschädigt als das kleinere und weniger geschützte SBG1.

Wasser und Strom interagierten mit dieser Bauweise. Die öffentliche Löschwasserversorgung, die der ersten Reaktion zur Verfügung stand, war für das sich entwickelnde Ereignis unzureichend, so die Untersuchung, und OVH hatte weder eine eigene Löschwasserreserve noch eine Möglichkeit, direkt aus dem nahen Kanal zu pumpen. Die Ankunft der EUROPA war entscheidend. Elektrische Unabhängigkeit, normalerweise eine Stärke von Rechenzentren, machte die Notfalltrennung schwierig: Der Standort kombinierte Netzeinspeisungen, Generatoren und große Batteriesysteme.

Die Feuerwehr konnte große Wasserströme nicht sicher einsetzen, bis diese Quellen neutralisiert waren.

Dies ist das Paradoxon der Infrastrukturresilienz. Notstrom erhält die Rechenleistung während eines normalen Stromausfalls, wird aber während eines Brandes zu einer weiteren zu managenden Energiequelle. Offene Luftströmung kann Kühlkosten senken und Betriebseffizienz verbessern, kann aber die Rauch- und Hitzeeindämmung schwächen. Dichte Ausrüstung und gemeinsame Standortnutzung können Skaleneffekte verbessern, konzentrieren aber die Auswirkungen. Jede Optimierung schafft ein Risiko, das durch eine andere Barriere kontrolliert werden muss.

OVHs formelle Antwort auf die BEA-RI-Empfehlungen (Link) argumentierte, dass das Fehlen automatischer Löschung keine regulatorische Anforderung verletzte und dass die von der Untersuchung zitierte Branchenrichtlinie nach dem Design von SBG2 veröffentlicht wurde. Dies ist für die rechtliche und Compliance-Analyse relevant. Es ist nicht das Ende der betrieblichen Rechenschaft. Minimale Compliance fragt, ob eine Regel eine Kontrolle erzwang. Resilienz fragt, ob die Kontrolle für ein glaubwürdiges Szenario mit hohen Auswirkungen erforderlich war.

OVHs Entscheidung nach dem Brand, automatische Löschsysteme auf nicht ausgerüsteten Standorten zu verallgemeinern, ist selbst ein Beweis dafür, dass sich die Risikobehandlung geändert hat.

Vier Gebäude bedeuteten nicht vier unabhängige Ergebnisse

Von einem Kunden-Dashboard aus konnten SBG1, SBG2, SBG3 und SBG4 wie mehrere Infrastrukturstandorte aussehen. Während des Vorfalls bildeten sie einen einzigen Notfallstandort. SBG2 brannte. SBG1 und SBG3 waren in unterschiedlichem Maße vom Feuer betroffen. SBG4 wurde durch das ursprüngliche Feuer nicht beschädigt. Dennoch wurde der Strom für alle vier unterbrochen, der Zugang wurde kontrolliert, gemeinsame Systeme mussten bewertet werden, und die überlebende Infrastruktur erforderte Reinigung, Inspektion, Neuverkabelung und gestaffelten Neustart.

OVHclouds zeitgleiches Straßburg-Updatelog (Link) macht den physischen Charakter der Wiederherstellung ungewöhnlich sichtbar. Teams entfernten, reinigten, inspizierten, installierten und starteten Ausrüstung raumweise, gangweise, rackweise und serverweise neu. Rußverseuchte Server wurden zu einer Fabrik in Croix für Spezialarbeiten gebracht. Bergbare Maschinen von SBG1 wurden in andere Rechenzentren verlegt. Datensicherungsspezialisten versuchten, Datenträger aus beschädigten Räumen zu bergen.

Die erste Wiederherstellung war nicht linear. SBG3 wurde am 18. März betriebsbereit. Am Abend des 19. März wurde Rauch in einem nicht verbundenen Batterieraum von SBG1 entdeckt. OVH schaltete SBG1 und SBG4 vorsorglich wieder ab und überarbeitete den Neustartplan. Die Dienstwiederherstellung wurde am 22. März fortgesetzt. Ende März waren die Bare-Metal-Server von SBG4 zugänglich und SBG3-Dienste kehrten in Prozenten zurück, während die Ausrüstung von SBG1 noch gereinigt, repariert und verlegt wurde.

OVHs Registrierungsdokument sagte später, dass die meisten Kundendienste innerhalb von drei bis vier Wochen zurückkehrten und die Dienste für die etwa 65.000 betroffenen Kunden, die etwa 120.000 Dienste nutzten, Anfang Mai vollständig wiederhergestellt waren. „Dienst wiederhergestellt“ kann nicht als „alle Daten wiederhergestellt“ gelesen werden. Ein Ersatzserver kann bereitgestellt werden, während die früheren Datenträger und Aufzeichnungen des Kunden zerstört bleiben. Die Wiederherstellungsberichterstattung muss Infrastrukturverfügbarkeit, Anwendungsstart, Datenwiederherstellung, Datenaktuellität und Geschäftsakzeptanz trennen.

Die standortweite Abschaltung zeigt auch, warum das Wort „Rechenzentrum“ für die Katastrophenplanung zu granular sein kann. Eine Ausfall-Domäne ist das, was eine Gefahr gemeinsam betreffen kann. Für die Brandbekämpfung in Straßburg umfasste die relevante Domäne die benachbarten Gebäude, Stromtrennverfahren, Notzugang, Wasserkapazität, Rauch, gemeinsamen Betrieb und die Sicherheitsbehörde, die den Wiedereintritt kontrollierte. Mehrere Gebäudenamen schufen keine unabhängige Wiederherstellung, wenn dieselbe Notfallentscheidung alle unverfügbar machen konnte.

Die Auswirkungen zählen erfordert mehr als eine Zahl

Netcrafts externe Messung des Ausfalls (Link) fand etwa 3,6 Millionen Websites auf 464.000 unterschiedlichen Domains offline und mehr als 18 Prozent der OVH in seiner letzten Umfrage zugeschriebenen IP-Adressen antworteten während des Messzeitraums nicht. Das ist eine Internet-weite Sicht auf verlorene Erreichbarkeit. Es erfasst gehostete Subdomains und nachgelagerte Hosting-Vereinbarungen, weshalb es die Kundenzahl von OVH weit übersteigt.

OVHs 65.000 betroffene Kunden und 120.000 Dienste beschreiben kommerzielle und Produktbeziehungen. Keine der Zahlen sagt, wie viele Endnutzer keinen Dienst erreichen konnten, wie viele Unternehmen einen Umsatzkanal verloren oder wie viele Datensätze unwiederbringlich waren. Zeitgenössische Reuters-Berichterstattung (Link) identifizierte Regierungsportale, Banken, Geschäfte, Nachrichtenseiten und andere Online-Dienste unter den Störungen. Diese Beispiele zeigen die Vielfalt der Auswirkungen, nicht eine vollständige Zählung.

Die Wirkung variierte auch im Laufe der Zeit. Eine zustandslose Website mit Code in einem externen Repository konnte in einer anderen Region in Stunden wieder aufgebaut werden. Ein verwalteter Dienst mit vom Anbieter gehaltenen Wiederherstellungsdaten könnte zurückkehren, wenn OVH seine Plattform wiederherstellte. Ein Bare-Metal-Kunde, der auf Inspektion oder physische Verlegung wartete, könnte wochenlang nicht verfügbar sein. Ein Kunde, dessen einzige Produktionsdaten und Backups zerstört wurden, erlitt dauerhaften Verlust, unabhängig davon, wie schnell ein neuer leerer Server eintraf.

Ein rechenschaftspflichtiger Vorfallsbericht sollte daher mehrere Nenner verwenden: Kunden, Dienste, physische Server, Domains, extern nicht erreichbare Adressen, Dauerbänder, erfolgreiche Anbieter-Wiederherstellungen, kundeninitiierte Wiederaufbauten und Fälle dauerhaften Datenverlusts. Er sollte identifizieren, wie viele Kunden kein Backup, eine Kopie im selben Gebäude, eine Kopie am selben Standort, eine andere OVH-Region oder eine Kopie unter unabhängiger Kontrolle hatten. Öffentliche Beweise liefern diese vollständige Matrix nicht.

Das Fehlen ist wichtig, weil die Abhilfe dem Verlustmechanismus folgen sollte. Wenn Kunden kein klar angebotenes Remote-Backup ausgewählt haben, sind bessere Produktaufklärung und sicherere Voreinstellungen relevant. Wenn ein Produkt namens Backup alle Kopien innerhalb eines Gebäudes platzierte, ohne klare Offenlegung der Ausfall-Domäne, sind Produktdesign und Vertragsgestaltung zentral. Wenn Remote-Kopien existierten, Kunden sie aber nicht abrufen konnten, weil Identität, Schlüssel, Kataloge oder Netzwerkpfade an Straßburg gebunden waren, ist die Unabhängigkeit des Wiederherstellungssystems das Problem.

Die Zusammenfassung dieser Fälle als „einige Kunden hatten kein Backup“ verhindert präzise Rechenschaft.

Ein Backup ist eine Behauptung über eine zukünftige Wiederherstellung

OVHclouds Registrierungsdokument 2021 (Link) sagte, dass Datensicherungsdienste für die meisten Kunden optionale kostenpflichtige Dienste waren und einige dauerhaften Datenverlust erlitten. Es sagte auch, dass Kunden angebotene Optionen wählen konnten, bei denen gesicherte Daten entweder im selben Rechenzentrum oder in einem anderen Rechenzentrum gespeichert wurden. Bestimmte vom Anbieter verwaltete Dienste, einschließlich E-Mail, wurden nur geringfügig unterbrochen und verloren keine Daten, da OVH sie sicherte.

Diese Offenlegungen widerlegen zwei einfache Geschichten. Es ist ungenau zu sagen, OVH habe jeden Dienst gesichert und es versäumt, alle Kopien zu erhalten. Es ist auch unzureichend zu sagen, jeder Kunde, der Daten verloren hat, habe es versäumt, ein Backup zu kaufen. Die Servicemodelle unterschieden sich. Einige Kunden behielten die Verantwortung für die einzige dauerhafte Kopie, einige wählten Anbieteroptionen mit unterschiedlichen Standorten, und einige nutzten Dienste, bei denen OVH die Wiederherstellung kontrollierte.

Ein Backup ist nicht allein durch einen erfolgreichen Kopierjob definiert. Es ist ein kontrolliertes Versprechen, dass eine Organisation nach bestimmten Ausfällen eine ausreichend aktuelle, intakte Version ihrer Informationen abrufen und zur Wiederherstellung eines prioritären Dienstes innerhalb einer akzeptierten Zeit verwenden kann. Dieses Versprechen enthält mindestens sechs Eigenschaften:

1. Umfang:Die Daten, Systemzustand, Konfigurationen, Identitätsspeicher, Schlüssel, Software und externen Abhängigkeiten, die eingeschlossen oder absichtlich ausgeschlossen sind.
2. Zeitpunkt:Das maximal akzeptable Alter der wiederhergestellten Daten, normalerweise als Recovery Point Objective ausgedrückt, und die Aufbewahrungshistorie, die für Korruption oder späte Entdeckung benötigt wird.
3. Isolation:Die physischen, logischen, administrativen und Anbieterausfälle, die nicht alle Kopien zusammen zerstören oder verändern können.
4. Zugriff:Die Anmeldeinformationen, Verschlüsselungsschlüssel, Kataloge, Werkzeuge, Netzwerkpfade und autorisierten Personen, die erforderlich sind, um die Kopie während einer Krise abzurufen.
5. Zeit:Die getestete Dauer, um Kapazität zu erhalten, Daten zu übertragen, Abhängigkeiten wieder aufzubauen, Transaktionen abzugleichen und eine Geschäftsfunktion in einen akzeptablen Zustand zurückzuversetzen.
6. Nachweis:Überwachung, dass das Backup abgeschlossen wurde, Integritätsprüfungen, stichprobenartige Wiederherstellungen, vollständige Serviceübungen und aufbewahrte Aufzeichnungen, die das Ergebnis zeigen.

Straßburg war in erster Linie ein Test der physischen Isolation und Wiederherstellungszeit, aber es legte alle sechs offen. Ein Festplattenabbild ohne DNS-Einträge, Geheimnisse, Bereitstellungscode oder Datenbankkonsistenz kann möglicherweise keine Anwendung starten. Eine entfernte Kopie, die mit Schlüsseln verschlüsselt ist, die nur über die ausgefallene Region verfügbar sind, kann haltbar und unbrauchbar sein. Ein Multi-Terabyte-Archiv, dessen Abruf Tage dauert, kann ein Zwölf-Stunden-Geschäftsziel verfehlen.

Ein Backup, das in derselben Energie- und Branddomäne gespeichert ist, kann bis zu dem Ereignis, das es abdecken sollte, perfekt aktuell sein.

Die französische Datenschutzbehörde CNIL formuliert die physische Lektion jetzt klar in ihrer Backup-Sicherheitsleitlinie (Link): Halten Sie mindestens eine Kopie an einem geografisch getrennten Standort, isolieren Sie mindestens eine Kopie offline, schützen Sie Backups auf dem gleichen Sicherheitsniveau wie die Produktion und testen Sie Integrität und Wiederherstellung. CNILs Cloud-Sicherheitsleitlinie (Link) sagt Kunden, sie sollen überprüfen, ob ein Cloud-Anbieter Backup-Standorte hat, die von seinen Rechenzentren geografisch entfernt sind.

Diese Materialien von 2024 sind spätere Leitlinien, kein Beweis für die genaue vertragliche Pflicht für jeden OVH-Dienst im Jahr 2021. Sie sind ein klarer Maßstab für die gegenwärtige Praxis.

Der Fall Bati Courtage machte die Produktsprache folgenreich

Ein Kundenstreit gibt der Backup-Grenze rechtliche Spezifität. France Bati Courtage nutzte einen virtuellen Privatserver von OVH und eine kostenpflichtige automatisierte Backup-Option. Laut den Aufzeichnungen informierte OVH es im April 2021, dass das Backup ebenfalls vollständig und unwiderruflich zerstört worden sei, da die Kopien im selben Gebäude wie der primäre Server lagen. Der Kunde forderte Millionen von Euro für Datenverlust und angebliche nachgelagerte Geschäftsschäden.

Das Ergebnis änderte sich in der Berufung. In seinem Urteil vom 24. April 2025 (Link) hielt das Berufungsgericht Douai einen Vertragsbruch aufrecht, weil OVH dem Kunden nicht den Zugang zum abgeschlossenen Backup lassen und es für den Abruf aufbewahren konnte. Es bestätigte nicht die separate Forderung des Kunden, dass OVH schuldhaft gehandelt habe, weil es die Dienste nicht an geografisch isolierten Orten platziert habe.

Es bestätigte auch die frühere Feststellung, dass OVH in diesem Streit kein grobes Verschulden oder schwere Brandschutzverstöße begangen habe, wies OVHs höhere-Gewalt-Verteidigung zurück, bestätigte die relevanten Haftungsbeschränkungen und reduzierte die Zuerkennung auf 1.800,48 EUR.

Diese Entscheidung ist enger und lehrreicher als das weithin berichtete erstinstanzliche Urteil. Sie stellt nicht fest, dass jeder OVH-Backup-Vertrag ein Remote-Rechenzentrum versprach. Sie stellt keine allgemeine Regel auf, dass jedes Backup am selben Standort rechtlich mangelhaft ist. Sie zeigt jedoch, dass die Verantwortung nicht mit dem Argument „der Kunde war für die Backup-Politik zuständig“ abgetan werden kann, wenn der Kunde den Anbieter für die Durchführung eines Backups bezahlte und der Anbieter vertragliche Verpflichtungen bezüglich der resultierenden Kopie hatte.

Der Fall zeigt auch, warum Vertragsbezeichnungen eine Topologie dahinter benötigen. Begriffe wie „physisch isoliert“, „Infrastruktur“, „lokal“, „Region“ und „remote“ können unterschiedliche Bedeutungen haben. Ein separates Festplattenarray ist von einem Serverausfall isoliert. Ein separater Raum kann von einem Rack-Brand isoliert sein. Ein separates Gebäude kann einige Raumbereignisse überleben, aber nicht unbedingt eine Campus-Stromabschaltung oder Perimeter-Schließung. Eine separate Region ist stärker, vorausgesetzt die Regionen teilen keine Kontroll-, Konto-, Schlüssel- oder Netzwerkabhängigkeiten, die die Wiederherstellung blockieren.

Kunden sollten diese Grenzen nicht aus einem Marketing-Adjektiv ableiten müssen. Eine Dienstbeschreibung sollte die Ausfall-Domäne der Kopie nennen, ob der Standort standardmäßig oder optional ausgewählt ist, ob sich der Standort ändern kann, die Gefahren, die das Design überstehen soll, das Wiederherstellungsziel und die verbleibenden Pflichten des Kunden. Anbieter sollten die historische Version dieser Darstellungen aufbewahren, da die Schnittstelle und Dokumentation, die beim Kauf eines Dienstes verfügbar waren, später zentrale Beweise werden können.

Vertragliche Haftungsbeschränkung und betriebliche Rechenschaft weichen ebenfalls voneinander ab. Die Berufungszuerkennung war gering, weil das Gericht vereinbarte Beschränkungen anwendete, nachdem es die Ansprüche und Klauseln geprüft hatte. Eine Haftungsobergrenze macht dauerhaften Datenverlust nicht betrieblich akzeptabel, noch beweist ein großer angeblicher Verlust, dass der Anbieter diesen Betrag rechtlich schuldet. Verträge verteilen finanzielle Risiken. Sie stellen keine Informationen wieder her oder beweisen, dass eine Kontrolle angemessen ausgelegt war.

Geteilte Verantwortung muss spezifisch genug sein, um zu funktionieren

„Geteilte Verantwortung“ wird oft als höfliche Art verwendet zu sagen, dass beide Parteien Arbeit zu erledigen hatten. Wenn die Arbeit nicht benannt ist, verteilt der Begriff die Schuld nach einem Ausfall, anstatt Kontrollen vorher zuzuweisen. Straßburg unterstützt eine präzisere Trennung.

OVH besaß die Wahrscheinlichkeit, dass ein lokales elektrisches Ereignis zu einem Gebäudeverlust anwuchs. Es wählte das physische Design, die Branderkennung und -bekämpfung, die Brand abschnitte, die Versorgungsisolation, die Notfallverfahren, den Wartungsrahmen, die Wasserressourcen und die Beziehung zu öffentlichen Feuerwehrleuten. Kunden konnten keine Sprinkler in SBG2 installieren oder eine Notstromabschaltung einrichten. Das sind Anbieterkontrollen, auch wenn Kundenverträge Schadensersatz begrenzen.

OVH besaß auch die Wahrheit über seine Produkte. Nur der Anbieter konnte wissen, wo ein automatisiertes Backup landete, welche Dienste standardmäßig gesichert wurden, welche Regionen gemeinsame Systeme nutzten und wie sich die Steuerungsebene während des Verlusts von Straßburg verhielt. Er musste diese Eigenschaften genau genug beschreiben, damit ein Kunde eine Risikoentscheidung treffen konnte. Wo OVH den Backup-Dienst übernahm, besaß es die Leistung des versprochenen Dienstes und die Beweise über die resultierende Kopie.

Kunden besaßen das Folgenmodell. Ein Anbieter konnte ohne eine spezifische verwaltete Vereinbarung nicht wissen, ob ein kleiner virtueller Server eine austauschbare Testseite oder die einzige Kopie jahrelanger Geschäftsaufzeichnungen enthielt. Der Kunde musste Daten klassifizieren, Wiederherstellungsziele setzen, eine Architektur wählen, die den Auswirkungen angemessen ist, Kopien außerhalb der primären Ausfall-Domäne aufbewahren und den Wiederaufbau testen. Der Kauf von Infrastruktur übertrug nicht die Pflicht des Kunden zu entscheiden, wie lange das Geschäft seinen Verlust tolerieren konnte.

Die Grenze verschiebt sich mit dem Servicemodell. Bei unverwalteter Bare Metal oder Infrastructure as a Service besitzt der Kunde normalerweise anwendungskonsistentes Backup und Failover. Bei einer verwalteten Datenbank, einem gehosteten Mail-Produkt oder einem expliziten Backup-Dienst besitzt der Anbieter mehr von der Kopie, Aufbewahrung, Konsistenz und dem Wiederherstellungspfad. Ein Marktplatz-Wiederverkäufer oder Managed-Service-Provider fügt eine weitere Ebene hinzu: Er kann OVH auswählen, das Backup konfigurieren, die Resilienz gegenüber seinen eigenen Kunden darstellen und den einzigen administrativen Zugriff behalten.

Endkunden müssen diese Kette kennen.

Die französische Cybersicherheitsbehörde ANSSI macht in ihren aktuellen Backup-Grundlagen (Link) diese Pflichten zu praktischen Kontrollen. Sie fordern Recovery Point und Zeitziele, das 3-2-1-Muster, mindestens eine Offline- oder angemessen geschützte Off-Site-Kopie, regelmäßige Wiederherstellungstests, eine Wiederherstellungsreihenfolge und den Schutz von Installationsmedien und Anwendungskonfigurationen. Für ausgelagerte Backups hebt ANSSI den EU-Standort, das Replikationsverhalten des Anbieters, kundenkontrollierte Verschlüsselung und die Abrufzeit hervor.

Dies ist eine nützliche Erinnerung daran, dass physische Resilienz, Cyber-Isolation, Souveränität und Wiederherstellbarkeit gemeinsam gestaltet werden müssen.

Lokalität beantwortet mehrere verschiedene Fragen

OVHclouds europäische Identität war 2021 wichtig und ist es noch. Für Regierungen und regulierte Organisationen, die eine Alternative zu nicht-europäischen Hyperscalern suchen, kann ein französischer Anbieter, der europäische Rechenzentren betreibt, sinnvolle rechtliche, wirtschaftliche und betriebliche Vorteile bieten. Der Brand in Straßburg machte Datensouveränität nicht irrelevant. Er zeigte, dass Souveränität kein Ersatz für Verfügbarkeitstechnik ist.

„Wo sind die Daten?“ kann mindestens fünf Dinge bedeuten:

• Rechtlicher Standort:Welches Land hat die Datenschutz-, Offenlegungs-, Insolvenz- und Sektorregeln, die Speicherung, Verarbeitung und Zugriff regeln.
• Unternehmenskontrolle:Welche Muttergesellschaften, Administratoren, Unterauftragsverarbeiter und ausländischen rechtlichen Anforderungen können den Dienst beeinflussen.
• Physischer Standort:Welches Gebäude, Überschwemmungsgebiet, Stromnetz, Wasserversorgung, Campus und regionale Gefahr enthält jede Kopie.
• Logischer Standort:Welche Region, Zone, Konto, Mandant, Schlüsselsystem und Steuerungsebene müssen funktionieren, um die Daten abzurufen oder ein Failover durchzuführen.
• Betriebliche Entfernung:Wie viel Latenz, Bandbreite, Personal und Wiederherstellungszeit trennen die Produktion von ihren Benutzern und von der Wiederherstellungskopie.

Eine Richtlinie, die besagt „alle Daten müssen in Frankreich bleiben“, beantwortet einen Teil der ersten Frage und schränkt die dritte ein. Sie erfordert nicht, dass Produktion und Backup dasselbe Gebäude belegen. Frankreich enthält mehrere Ballungsräume und Cloud-Regionen. Eine Richtlinie, die EU-Speicherung vorschreibt, erlaubt noch mehr geografische Vielfalt, während sie einen EU-Rechtsrahmen beibehält. Ob das ausreicht, hängt vom Gesetz, Bedrohungsmodell, der Datensensitivität und dem Wiederherstellungsziel der Organisation ab.

Die Erklärung der Europäischen Kommission zu internationalen Übermittlungen (Link) verhindert auch eine gegensätzliche Vereinfachung: Die DSGVO erlegt keine absolute Regel auf, dass personenbezogene Daten niemals den Europäischen Wirtschaftsraum verlassen dürfen. Sie sieht Angemessenheitsbeschlüsse, Garantien und begrenzte Ausnahmen für Übermittlungen vor. Einige Organisationen verfolgen dennoch strengere Lokalitätsanforderungen aufgrund von Sektorgesetzen, öffentlicher Politik, vertraglichen Versprechungen oder der Gefahr ausländischer Gerichtsbarkeit.

ANSSIs SecNumCloud-Qualifikationsleitlinie (Link) zeigt das reichhaltigere Souveränitätsmodell. Sie adressiert den EU-Standort nicht nur für Kundendaten, sondern auch für Verwaltung, Überwachung, Backups, Verzeichnisse und technische Daten, während sie die Unternehmenskontrolle und die Gefahr von Nicht-EU-Recht berücksichtigt. Dieses Rahmenwerk ist die Kontrolle über Dienst und Daten, nicht nur der Längen- und Breitengrad einer Festplatte.

Die praktische Schlussfolgerung ist konstruktiv: Souveränität und Katastrophentrennung können sich gegenseitig verstärken. Eine französische öffentliche Stelle kann sensible Produktion in einer qualifizierten europäischen Umgebung halten, eine geografisch getrennte EU-Wiederherstellungskopie aufbewahren, kundenkontrollierte Verschlüsselung und Schlüssel verwenden und getestete Exportverfahren zu einer anderen genehmigten Umgebung unterhalten. Die Architektur kann mehr kosten und eine sorgfältige rechtliche Prüfung erfordern. Der Zielkonflikt sollte explizit sein, nicht hinter dem Wort „lokal“ versteckt.

Konzentration ist sowohl eine Anwendungseigenschaft als auch eine Markteigenschaft

Der Ausfall betraf Regierungsportale, Handel, Medien, Spiele und öffentliche Dienste, weil viele Organisationen einen Anbieter auswählten oder über einen Lieferanten erhielten. Dies ist Cloud-Konzentration auf der Marktebene. Es gab auch Konzentration innerhalb einzelner Anwendungen: Produktion, Backups, DNS, E-Mail, Verwaltung und Bereitstellungswerkzeuge konnten OVH oder Straßburg teilen, selbst wenn sie als separate Produkte erschienen.

Die beiden Formen erfordern unterschiedliche Behandlung. Regulierungsbehörden können die systemische Abhängigkeit von einer kleinen Gruppe von Cloud-Anbietern überwachen. Beschaffungsteams können ungeprüfte Anbieterkonzentration über Abteilungen hinweg vermeiden. Anwendungsbesitzer müssen die Abhängigkeiten abbilden, die bestimmen, ob ihr eigener Dienst wiederhergestellt werden kann. Ein Unternehmen kann drei Cloud-Anbieter in seinem Portfolio nutzen, während ein kritisches System immer noch keine unabhängige Kopie hat.

Ein anderes kann bei einem Anbieter bleiben, aber wirklich getrennte Regionen, exportierbare Backups, unabhängiges DNS und Offline-Wiederherstellungsmaterialien verwenden.

Die Finanzregulierung drückt diese verbleibende Kundenverantwortung zunehmend aus. Die Outsourcing-Leitlinien der Europäischen Bankenaufsichtsbehörde (EBA) von 2019 (Link) verlangen von beaufsichtigten Instituten, Outsourcing-Risiken zu steuern und in der Lage zu bleiben, die Aufsicht auszuüben, anstatt zu leeren Hüllen zu werden. Das spätere EU-Gesetz über die digitale operationale Resilienz (DORA) verlangt von beaufsichtigten Finanzunternehmen, Backup-, Wiederherstellungs- und Notfallvereinbarungen zu unterhalten und regelmäßig zu testen.

Seine Anforderungen in Artikel 12 (Link) umfassen physische und logische Trennung, wenn Unternehmen Backup-Daten mit ihren eigenen Systemen wiederherstellen. Diese Regeln haben definierte Anwendungsbereiche und sollten nicht rückwirkend auf jeden OVH-Kunden von 2021 projiziert werden. Sie zeigen die Richtung rechenschaftspflichtiger Praxis: Auslagerung lagert die Verantwortung des Leitungsorgans für die Kontinuität nicht aus.

Der detaillierte Umsetzungsrahmen von DORA geht noch weiter. Die delegierte Verordnung von 2024 zum IKT-Risikomanagement (Link) umfasst Szenarien mit teilweisem oder vollständigem Verlust von Räumlichkeiten und Rechenzentren, Ausfall von Dritten, Umschaltungen auf redundante Kapazitäten und weit verbreitete Stromausfälle. Straßburg ist genau die Art von kombiniertem physischen und Lieferantenereignis, das eine ernsthafte Übung modellieren sollte.

Ein Multi-Anbieter-Design kann einige Abhängigkeiten reduzieren, ist aber nicht automatisch überlegen. Es erhöht die Komplexität bei Identität, Vernetzung, Datenkonsistenz, Fähigkeiten, Beobachtbarkeit und Vorfallkoordination. Das korrekte Ziel ist portable, testbare Wiederherstellung für wichtige Funktionen, nicht ein architektonischer Slogan. Manchmal bedeutet das aktiven Dienst über unabhängige Zonen. Manchmal bedeutet es Warmkapazität in einer anderen Region. Manchmal erfüllt ein geschütztes Backup plus Infrastructure-as-Code und eine geübte Wiederherstellung den Geschäftsbedarf zu viel geringeren Kosten.

Wiederherstellung muss von der Kundenseite nachgewiesen werden

Anbieter-Wiederherstellung und Kundenwiederherstellung sind nicht dieselbe Uhr. OVH konnte ein Rechenzentrum als betriebsbereit erklären, wenn Strom, Netzwerk und ein großer Teil der Server verfügbar waren. Ein Kunde musste dennoch Dateisysteme, Datenbanken, Warteschlangen, Zertifikate, DNS, Integrationen und Geschäftstransaktionen validieren. Wenn der ursprüngliche Server zerstört war, musste der Kunde einen Ersatz bereitstellen, Daten abrufen, die Anwendung neu aufbauen und alles abgleichen, was nach der letzten nutzbaren Kopie passiert war.

Eine ausgereifte Wiederherstellungsübung beginnt mit einem angenommenen Verlust, nicht einer bequemen Exportfunktion. Das Team sollte so tun, als sei die primäre Region unzugänglich, normale Administratoren könnten sich nicht über ihren Identitätspfad anmelden und der Anbietersupport sei überlastet. Es sollte das Backup mit Anmeldeinformationen und Schlüsseln abrufen, die außerhalb der ausgefallenen Umgebung gespeichert sind, saubere Kapazität im genehmigten Ziel aufbauen, Abhängigkeiten in der dokumentierten Reihenfolge wiederherstellen, die Datenintegrität validieren, Benutzer umleiten und das Geschäftsergebnis messen.

Die Beweise sollten praktische Fragen beantworten. Was war der Zeitstempel der wiederhergestellten Datenbank? Welche Schreibvorgänge gingen verloren? Waren alle Objektspeicherversionen enthalten? Konnten Schlüssel wiederhergestellt werden, ohne die Zugriffskontrolle zu schwächen? Änderte sich DNS innerhalb der erwarteten Zeit? Akzeptierten externe Zahlungs-, E-Mail- und Identitätsanbieter die neuen Adressen? Wie lange dauerte es bis zur ersten sicheren Transaktion und wie lange bis zur vollen Kapazität? Wer genehmigte die Rückkehr und welcher Abgleich blieb?

Die Überwachung des Backups allein kann diese Fragen nicht beantworten. Ein grüner Job beweist, dass Software etwas auf ein Ziel geschrieben hat. Ein Integritätstest beweist, dass ausgewählte Daten gelesen werden können. Eine technische Wiederherstellung beweist, dass Systeme rekonstruiert werden können. Eine Serviceübung beweist, dass die Organisation ihre priorisierte Funktion unter dem angenommenen Ausfall erbringen kann. Jedes ist nützlich; keines sollte als das nächste ausgegeben werden.

Dies ist besonders wichtig für kleine Organisationen. Sie benötigen möglicherweise keineActive-Active-Infrastruktur oder eine dedizierte zweite Cloud. Sie brauchen einen proportionalen Ausweg. Ein kleines Unternehmen kann seine Datenbank und kritischen Dokumente in ein verschlüsseltes Ziel unter einem separaten Konto exportieren, seine Domain- und Bereitstellungs-Anmeldeinformationen unabhängig aufbewahren, einen sauberen Wiederaufbau dokumentieren und eine Beispielwiederherstellung testen. Die Kontrolle sollte den Kosten des Verlusts der Aufzeichnungen entsprechen, nicht dem monatlichen Preis des Servers.

OVHclouds Abhilfe adressierte die physische Kette

OVHs Antwort auf den BEA-RI beschrieb ein umfangreiches „Hyper Resilience“-Programm. Das Unternehmen gab an, die Erkennung zu verstärken, automatische Löschsysteme zu verallgemeinern, wo sie fehlten, Zonen und Brandabschnitte neu zu gestalten, den normalen Brandwiderstand von sechzig auf 120 Minuten zu erhöhen und Energie- und Batterieräume für neue Standorte und wo möglich an bestehenden außerhalb der Rechenzentrumsgebäude zu platzieren. Es plante ferngesteuerte Stromabschaltungen nach Zonen, damit Einsatzkräfte Gefahren isolieren können, ohne unbeeinträchtigte Bereiche unnötig abzuschalten.

Die Antwort sagte auch, dass lokale Feuerwehren innerhalb von vier Monaten nach dem Vorfall jeden OVH-Standort besuchten, Notfalldokumente und Stromabschaltverfahren überarbeitet wurden und eine neue Abteilung für Industrierisiken geschaffen wurde. In Straßburg installierte OVH in Zusammenarbeit mit der SIS67 einen privaten 120-Kubikmeter-Wassertank. Es hieß, alle Standorte hätten eine Brandrisikoanalyse erhalten und die Wirksamkeit würde durch eine Gefährdungsstudie bei Abschluss der Arbeiten gemessen. SBG5, eröffnet im Juli 2022, wurde als Beispiel für die neuen Standards präsentiert.

Diese Maßnahmen ordnen sich gut in die kausale und Ausbreitungskette der Untersuchung ein. Löschung adressiert frühes Wachstum. Stärkere Brandabschnitte adressieren vertikale und gebäudeübergreifende Ausbreitung. Externe Energieräume trennen Zündgefahren von Serverräumen. Zonengesteuerte Abschaltungen adressieren die Verzögerung und den Explosionsradius der elektrischen Isolation. Wasserspeicher adressiert die Erstangriffskapazität. Feuerwehrbesuche und Übungen adressieren Unkenntnis, Pläne und Führungsentscheidungen.

OVHclouds universelles Registrierungsdokument 2025 (Link) sagt, dass die Gruppe die Standortrisikokartierung während 2025 fortsetzt und beschreibt Hyper Resilience als Stärkung der Rechenzentrumssicherheit über regulatorische und Versichererempfehlungen hinaus. Es hält auch eine fortlaufende Rückstellung für die Folgen des Brandes in Straßburg fest, einschließlich Haftungsklagen. Dies ist ein Beweis für ein dauerhaftes Programm und eine finanzielle Behandlung, nicht für einen standortspezifischen unabhängigen Fertigstellungsnachweis.

Ein rechenschaftspflichtiger Abschluss würde qualifizierten Kunden und Prüfern eine Kontrollmatrix veröffentlichen oder bereitstellen: welche Standorte automatische Löschung in jedem relevanten Energie- und IT-Raum haben; welche 120-Minuten-Brandabschnitte haben; welche Batterieräume extern sind; welche Zonen ferngesteuerte Isolation haben; welche Wasserflussanforderungen getestet wurden; welche Feuerwehrübungen stattfanden; welche Feststellungen noch offen sind; und welche unabhängige Partei den Betrieb verifiziert hat. Eine politische Verpflichtung ist der Beginn der Abhilfe. Abdeckung und konfrontative Übung zeigen, ob es funktioniert.

Das Unternehmen verdient auch Anerkennung für die Aufrechterhaltung eines detaillierten öffentlichen Updatelogs während einer schwierigen Wiederherstellung, die Mobilisierung spezialisierter Reinigungs- und Wiederherstellungskapazitäten, den Ersatz von Infrastruktur, die Kommunikation produktspezifischer Fortschritte und die Veröffentlichung einer formellen Antwort auf die Sicherheitsempfehlungen. Transparenz ist nicht allein deshalb vollständig, weil Updates häufig sind, aber diese Aufzeichnungen ermöglichen es Kunden und Ermittlern, Entscheidungen zu rekonstruieren, die sonst verschwinden würden.

Das Produktdesign hat sich weiterentwickelt, aber die Konfiguration bestimmt immer noch die Resilienz

OVHclouds aktuelle Dokumentation ist expliziter in Bezug auf Ausfall-Domänen als die Sprache vor dem Brand, die im Bati Courtage-Streit sichtbar war. Ihr Leitfaden zu Bereitstellungsmodi (Link) unterscheidet Regionen mit einer Verfügbarkeitszone, Regionen mit drei Zonen und lokale Zonen. Es besagt, dass eine 1-AZ-Region anfällig für Ausfälle bleibt, die ein ganzes Rechenzentrum betreffen, während die 3-AZ-Architektur unabhängige Zonen für anspruchsvollere Produktions- und Disaster-Recovery-Fälle verwendet.

Die Übersicht des Unternehmens über Regionen und Verfügbarkeitszonen (Link) sagt ebenfalls, dass Kunden, die eine höhere Resilienz wünschen, eine unterstützte Multi-Zonen-Region auswählen und für mehrere Zonen auslegen sollten. Die Verben sind wichtig: Der Anbieter stellt Zonen zur Verfügung; der Kunde muss Ressourcen und Anwendungszustand über sie verteilen. Das bloße Starten in einer 3-AZ-Region stellt nicht sicher, dass eine virtuelle Maschine, eine Datenbank oder ein manuell platziertes Volume Zonen umfasst.

Aktuelle Instance-Backup-Dokumentation (Link) unterscheidet jetzt zwischen lokalen und entfernten Backups. Ein lokales Backup bleibt in derselben Region. Ein entferntes Backup erstellt eine Kopie in einer anderen ausgewählten Region und wird separat abgerechnet. Dies ist eine viel klarere Sprache zu Ausfall-Domänen. Es bewahrt auch eine explizite Kundenwahl, was bedeutet, dass Beschaffung und Konfiguration weiterhin Teil der Kontrolle sind.

Die aktuelle Dokumentation sollte nicht verwendet werden, um zu rekonstruieren, was jedem Kunden im März 2021 angeboten wurde. Sie ist relevant für die aktuelle Rechenschaftsfrage: Hat der Markt gelernt, Lokalität und Resilienz getrennt darzustellen? OVHcloud tut dies jetzt in diesen Produktleitfäden. Der nächste Sicherheitsschritt besteht darin, die Unterscheidung konsistent auf Produktseiten, Verträgen, Control-Panel-Voreinstellungen, APIs, Rechnungen und Support-Antworten zu gestalten, einschließlich Produkten, bei denen vom Anbieter verwaltete Backups anderen Regeln folgen.

Sicheres Design kann auch abgestufte Voreinstellungen verwenden. Ein kostengünstiger Entwicklungsservice kann sinnvollerweise ein lokales Backup als Voreinstellung verwenden, wenn die Schnittstelle es als Schutz vor Instance-Ausfall und nicht vor regionaler Katastrophe kennzeichnet. Eine Produktionsdatenbank oder ein Backup-gekennzeichnetes Produkt könnte vom Kunden verlangen, die Ausfall-Domäne zu bestätigen, eine Warnung anzeigen, wenn alle Kopien einen Standort teilen, und ein entferntes Ziel in derselben Rechtsregion anbieten. Das Ziel ist eine informierte Risikoakzeptanz, nicht die Erzwingung der teuersten Architektur für jede Workload.

Der Vorstand benötigt Nachweise über zwei Kontrollebenen hinweg

Der Brand in Straßburg durchquerte eine Anlagenkontrollebene und eine Kundenwiederherstellungskontrollebene. OVHclouds Vorstand und Risikoführung benötigen Sicherheit über beide. Brandschutztechnik kann nicht als Fußnote der Immobilien behandelt werden, und Backup-Produkte können nicht nur als Speicherumsatz behandelt werden.

Für die Anlagenebene sollte die Führung den maximal wahrscheinlichen Verlust an jedem Standort kennen, nicht nur die Geräteredundanz. Berichte sollten Löschabdeckung, Brandabschnittsintegrität, Energie-Raumtrennung, Erkennungsleistung, Notwasser, Stromtrennzeit, Feuerwehrvertrautheit, Wartungsausnahmen und überfällige Korrekturmaßnahmen zeigen. Übungen sollten annehmen, dass normale Kontrollen versagen und dass Feuerwehrleute sofortige, genaue Autorisierung zur Energieisolierung benötigen.

Für die Serviceebene sollte die Führung wissen, wie Produktausfall-Domänen dargestellt und getestet werden. Berichte sollten zeigen, wie viele Dienste, die mit Backup- oder Hochverfügbarkeitssprache vermarktet werden, jede Kopie an einem Standort oder in einer Region speichern; wie viele Kunden entfernten Schutz gewählt haben; Wiederherstellungserfolg nach Produkt und Maßstab; Schlüssel- und Identitätsabhängigkeiten; Verteilung der Wiederherstellungszeit; Dokumentationsdrift; und Beschwerden, die darauf hindeuten, dass Kunden den Standort missverstanden haben.

Der Vorstand sollte auch Ausnahmen erhalten, nicht nur Durchschnitte. Eine Backup-Job-Erfolgsrate von 99,99 Prozent kann mit Tausenden von Kopien in einer physischen Domäne koexistieren. Ein globaler Löschprozentsatz kann ein altes, dicht bebautes Gebäude verbergen. Eine durchschnittliche Wiederherstellungszeit kann die größten und folgenreichsten Datensätze verbergen. Tail Exposure gehört in die Governance, weil Straßburg ein Tail Event mit konzentrierten Auswirkungen war.

Unabhängige Herausforderung sollte ein Kundenversprechen bis ganz nach unten verfolgen. Wählen Sie einen als gesichert verkauften Dienst aus. Notieren Sie, was die Schnittstelle und der Vertrag sagen. Lokalisieren Sie jede Kopie und ihre Kontrollmetadaten. Entfernen Sie den primären Standort aus der Übung. Verweigern Sie normale Identitäts- und Supportpfade. Stellen Sie in einem Ziel wieder her, das die Lokalitätsregeln des Kunden erfüllt. Vergleichen Sie die gemessenen Ergebnisse mit dem versprochenen Wiederherstellungsziel.

Jeder Bruch ist eine handhabbare Lücke, unabhängig davon, ob sie dem Produkt, der Infrastruktur, dem Support oder dem Kunden gehört.

Was Kunden verlangen sollten, bevor sie einen Dienst als resilient bezeichnen

Organisationen benötigen keinen privaten Zugang zu jedem Rechenzentrumsplan. Sie benötigen Antworten, die detailliert genug sind, um zu entscheiden, ob ein Dienst zu den Auswirkungen eines Ausfalls passt. Die folgenden Fragen verwandeln die Lehren aus Straßburg in Beschaffungsnachweise:

Die Antworten sollten auf das genaue Produkt bezogen sein. Ein Corporate-Resilience-Bericht eines Anbieters beschreibt möglicherweise nicht das Budget-VPS, den lokalen Snapshot oder die verwaltete Datenbank, die gekauft wird. Zertifizierungen können nützliche Kontrollen etablieren, können aber Bereichsausschlüsse haben. Eine Verfügbarkeits-Service-Level-Vereinbarung bietet eine Abhilfe, nachdem ein Schwellenwert unterschritten wurde; sie beschreibt nicht von sich aus die Datenhaltbarkeit oder garantiert eine Wiederherstellung.

Kunden sollten auch die Konzentration unterhalb von Wiederverkäufernamen überprüfen. Ein verwalteter Backup-Anbieter kann sein Repository in derselben OVH-Region wie die Produktion speichern. Eine sekundäre Hosting-Marke kann OVH im Hintergrund nutzen. DNS, E-Mail, Quellcode, Geheimnisse und Vorfallkommunikation können alle den Anbieter teilen. Vielfalt wird durch Überlebenspfade gemessen, nicht durch Rechnungsanzahl.

Schließlich muss ein Kunde entscheiden, wie viel Verlust akzeptabel ist. Null Datenverlust und nahezu null Ausfallzeiten bei regionalen Katastrophen erfordern kontinuierliche Replikation, Anwendungsdesign, Kapazität und Betriebstests, die teuer sein können. Ein wöchentliches Offline-Backup kann für ein statisches Archiv ausreichend und für Transaktionen katastrophal sein. Rechenschaft verlangt nicht überall die gleiche Kontrolle. Sie verlangt eine bewusste Beziehung zwischen Auswirkung, versprochener Wiederherstellung, Architektur und Nachweis.

Das bleibende Signal

Der Brand in Straßburg war nicht nur eine unglückliche Zündung, gefolgt von einer Erinnerung, Backups zu machen. Er war eine Demonstration, wie Abstraktionen unter physischem Stress versagen. Separate Gebäude bildeten einen einzigen Notfallstandort. Gesunde Server wurden zusammen mit beschädigten unverfügbar. Ein abgeschlossenes Backup konnte mit der Produktion verschwinden. Ein europäischer Standort, der Souveränität und Latenz diente, konnte zu einer Konzentration von Brandrisiko werden. Ein Ersatzserver konnte die Infrastruktur wiederherstellen, ohne das Geschäft des Kunden wiederherzustellen.

Die öffentliche Aufzeichnung enthält auch bedeutende Verbesserungen. Erkennung und Nachtpersonal schützten Leben. Feuerwehrleute und das Löschboot EUROPA begrenzten die Ausbreitung. OVH führte eine schwierige, transparente Wiederherstellung durch, akzeptierte die BEA-RI-Empfehlungen in operativer Hinsicht und startete ein breites physisches Resilienzprogramm. Seine aktuelle Produktdokumentation unterscheidet klarer zwischen lokalem und entferntem Backup sowie zwischen Einzelzonen- und Mehrzonenbereitstellung. Dies sind keine kosmetischen Änderungen.

Der verbleibende Rechenschaftsstandard ist Nachweis über die Zeit. OVH sollte zeigen können, dass die nach dem Brand identifizierten physischen Kontrollen an relevanten Standorten installiert, gewartet und geübt werden; dass die Produktsprache echten Ausfall-Domänen entspricht; und dass die verwaltete Wiederherstellung funktioniert, wenn eine Region und ihre normalen Kontrollpfade fehlen. Kunden sollten zeigen können, dass kritische Daten eine nutzbare Kopie außerhalb der primären Gefahr innerhalb genehmigter rechtlicher Grenzen haben und dass ihre Mitarbeiter sie innerhalb des Geschäftsziels wiederherstellen können.

Kein Cloud-Anbieter kann versprechen, dass ein Gebäude niemals brennt. Kein Kunde kann jede Abhängigkeit beseitigen. Das glaubwürdige Versprechen ist enger: Ein vorhersehbares physisches Ereignis wird nicht stillschweigend Produktion, Wiederherstellung und die Mittel zum Verständnis des Verlorenen verbrauchen; Lokalitätsentscheidungen werden sowohl hinsichtlich der Gerichtsbarkeit als auch der Gefahr explizit sein; und das Wort „Backup“ wird durch den einzigen Nachweis gestützt, der letztendlich zählt: eine erfolgreiche Wiederherstellung unter den Bedingungen, für die die Kopie gekauft wurde.