Ein Rechenzentrum brennt – und plötzlich ist die IT-Infrastruktur eines Unternehmens buchstäblich in Flammen aufgegangen. Was klingt wie ein extremes Szenario, ist in der Realität mehrfach passiert: Der OVH-Brand 2021 in Straßburg vernichtete Tausende von Servern und traf Unternehmen weltweit unvorbereitet. Was tust du, wenn es dir passiert?
- Ein Rechenzentrumsbrand ist ein Worst-Case-Szenario, für das ein durchdachter Disaster-Recovery-Plan (DRP) existieren muss
- Die ersten Stunden nach dem Ausfall sind entscheidend: Kommunikation, Bestandsaufnahme und Failover-Aktivierung müssen sofort anlaufen
- Ohne Offsite-Backups oder Cloud-Replikation gibt es keine Wiederherstellung – alles, was nur im betroffenen RZ lag, ist verloren
- Versicherungsschutz und Meldepflichten müssen sofort beachtet werden
- Langfristig: Multisite-Strategien und Cloud-Hybrid-Ansätze schützen vor einem Single Point of Failure
Was passiert beim Rechenzentrumsbrand?
Ein Brand im Rechenzentrum ist nicht gleich ein Brand. Die Bandbreite reicht von einem einzelnen Server, der überhitzt und gelöscht wird, bis zum Vollbrand ganzer Hallen – wie im Fall von OVH in Straßburg, wo im März 2021 ein kompletter Gebäudekomplex abbrannte und rund 3,6 Millionen Webseiten für Stunden oder dauerhaft offline gingen.
Die unmittelbaren Schäden gehen oft weit über die Hardware hinaus: Löschwasser zerstört weitere Systeme, Ruß und Rauchgase beschädigen Elektronik in angrenzenden Bereichen, und das gesamte RZ muss gesperrt werden, bis die Brandursache offiziell geklärt ist. Ein schneller Neustart vor Ort ist in solchen Fällen ausgeschlossen.
Die ersten Stunden: Sofortmaßnahmen
1. Krisenstab aktivieren
Der erste Schritt ist nicht technisch – er ist organisatorisch. Ruf den Krisenstab zusammen: IT-Leitung, Geschäftsführung, Kommunikationsverantwortliche. Klär sofort, wer nach außen kommuniziert und wer intern die Lage koordiniert. Ohne klare Verantwortlichkeiten entsteht Chaos.
2. Schadensumfang feststellen
Was genau ist betroffen? Alle Server? Nur ein Teil? Welche Systeme sind ausgefallen, welche laufen noch? Trenn dabei schnell, was intern betroffen ist (eigene Hardware), und was beim Provider liegt (gemietete Dienste, Cloud-Instanzen). Diese Unterscheidung bestimmt, welche Wiederherstellungsschritte du in welcher Reihenfolge gehst.
3. Failover-Plan aktivieren
Existiert ein Disaster-Recovery-Plan, ist jetzt der Moment, ihn zu aktivieren. Kritische Systeme auf den DR-Standort oder in die Cloud umschalten. Wer einen Cold-Standby-Standort hat, beginnt mit dem Hochfahren. Wer Hot-Standby oder kontinuierliche Replikation betreibt, hat im besten Fall schon automatischen Failover.
4. Kommunikation nach außen
Kunden, Partner und – je nach Branche – Behörden müssen informiert werden. Sei dabei ehrlich und konkret: Was ist betroffen, was läuft noch, wann ist mit einer Wiederherstellung zu rechnen? Vage Aussagen oder Schweigen schaden dem Vertrauen mehr als ein offenes „Wir haben ein Problem und arbeiten daran“.
Wiederherstellung: Welche Szenarien gibt es?
Szenario A: Offsite-Backup vorhanden
Wenn aktuelle Backups außerhalb des betroffenen Rechenzentrums existieren – auf einem zweiten Standort, in der Cloud oder auf Bandmedien an einem anderen Ort – ist die Wiederherstellung möglich. Die Dauer hängt von der Backup-Aktualität (RPO), der Zielplattform und der verfügbaren Bandbreite ab.
Szenario B: Cloud-Replikation aktiv
Wer kontinuierliche Replikation in die Cloud oder auf einen zweiten Standort betrieb, hat den Vorteil minimaler Datenverluste. Die Systeme können dort hochgefahren werden, während das primäre RZ ausfällt. Das ist das beste Szenario – und es setzt voraus, dass Replikation vor dem Brand bereits eingerichtet war.
Szenario C: Kein Offsite-Backup
Das ist das schlimmste Szenario: Alle Daten lagen nur im betroffenen RZ. Forensische Datenrettung aus beschädigten Servern ist theoretisch möglich, aber teuer, zeitintensiv und mit ungewissem Ergebnis. In den meisten Fällen sind die Daten unwiederbringlich verloren. Dieser Fall ist kein Pech – er ist das Ergebnis einer unzureichenden Backup-Strategie.
Versicherung und Meldepflichten
Ein Rechenzentrumsbrand löst mehrere Pflichten aus:
Cyber-Versicherung informieren. Viele Cyber-Versicherungspolicen decken auch physische Schäden an IT-Infrastruktur ab – aber nur, wenn der Schaden innerhalb der Meldefristen gemeldet wird. Prüf deine Police und informiere deinen Versicherer sofort.
DSGVO-Meldepflicht. Wenn personenbezogene Daten durch den Brand verloren gegangen oder in falsche Hände geraten sind, greift die 72-Stunden-Meldepflicht gegenüber der zuständigen Datenschutzbehörde. Diese Frist läuft ab dem Zeitpunkt, an dem du von der Datenpanne erfährst.
Behörden und Vertragspartner. Je nach Branche (Finanzdienstleister, Gesundheitswesen, KRITIS) gibt es weitere Meldepflichten. Prüf das parallel zur technischen Wiederherstellung.
Langfristige Schutzmaßnahmen
Nach dem Brand ist vor dem nächsten Ausfall. Die Lehren aus einem solchen Ereignis – ob selbst erlebt oder am Beispiel anderer – sollten in konkrete Maßnahmen münden:
- Multisite-Strategie: Kritische Systeme nie nur an einem Standort. Zwei aktive Rechenzentren mit Lastverteilung schützen vor einem Single Point of Failure.
- Cloud-Hybrid: On-Premise-Infrastruktur mit Cloud-Backup oder Cloud-Failover kombinieren. Der Cloud-Standort ist physisch unabhängig.
- 3-2-1-Backup konsequent umsetzen: Mindestens eine Kopie offsite, mindestens ein Backup auf einem anderen Medientyp.
- DR-Plan testen: Ein ungetesteter Plan ist wertlos. Führe mindestens jährlich eine DR-Übung durch, bei der der Failover tatsächlich aktiviert wird.
- RZ-Dienstleister prüfen: Frag bei deinem Provider nach Brandschutzkonzept, Löschanlagen (Gaslöschanlagen sind für Server besser als Wasser), Redundanzkonzept und SLA für Wiederherstellungszeiten.
Fazit
Wenn das Rechenzentrum brennt, entscheiden die Wochen vor dem Brand über den Ausgang. Wer ein Offsite-Backup hat, eine Cloud-Replikation aktiv betreibt und einen getesteten DR-Plan in der Schublade hat, wird das Ereignis als teures, aber beherrschbares Problem überstehen. Wer das nicht hat, riskiert den Verlust von allem.
Der OVH-Brand war ein Weckruf für die Branche. Nutze ihn als Anlass, deine eigene DR-Strategie zu überprüfen – bevor du selbst in der Situation steckst.
FAQ
Hat OVH Kunden entschädigt?
OVH hat nach dem Brand 2021 Gutschriften für betroffene Kunden bereitgestellt – aber keine Entschädigung für Datenverluste, die durch fehlende Kundenbackups entstanden sind. Die Verantwortung für eigene Backups liegt grundsätzlich beim Kunden, auch bei Managed-Hosting-Angeboten.
Wie lange dauert eine Wiederherstellung nach einem RZ-Brand?
Das variiert enorm. Mit aktiver Cloud-Replikation: Stunden. Mit Offsite-Backup ohne Standby-Hardware: Tage. Mit Cold-Standby und großem Datenvolumen: Wochen. Ohne Offsite-Backup: unbestimmt oder gar nicht.
Welche Brandschutzsysteme sind für Rechenzentren geeignet?
Gaslöschanlagen (z.B. auf Basis von FM-200, Novec 1230 oder Inertgasen) sind für Rechenzentren besser geeignet als Wassersprinkler, da sie keine Folgeschäden an der Elektronik verursachen. Seriöse RZ-Anbieter haben diese Systeme standardmäßig installiert.
Muss ich Kunden über einen RZ-Brand informieren?
Wenn personenbezogene Daten von Kunden betroffen sind, ja – sowohl gegenüber der Datenschutzbehörde (72 Stunden) als auch gegenüber den betroffenen Personen (falls hohes Risiko). Unabhängig davon ist offene Kommunikation aus Vertrauensgründen fast immer die bessere Strategie.