Rechenzentren getroffen, Daten verloren: Warum die Cloud kein Backup ist

Mitte September 2026 hat Amazon Web Services eine Mitteilung veröffentlicht, wie es sie von einem der größten Cloud-Anbieter der Welt noch nicht gab: Nach mehr als sechs Monaten Wiederherstellungsarbeit gibt AWS die Rettung von Daten in Bahrain und in einem Teil seiner Infrastruktur in den Vereinigten Arabischen Emiraten auf. Was ausschließlich dort gespeichert war, ist für die Kunden nicht mehr erreichbar. Wer keine Kopie an einem anderen Ort hatte, bekommt diese Daten nicht zurück.

Auslöser war weder ein Softwarefehler noch ein Hackerangriff, sondern ein Krieg. Iranische Drohnen hatten Anfang März mehrere AWS-Rechenzentren am Persischen Golf getroffen: Es brannte, der Strom wurde abgeschaltet, das Löschwasser richtete weitere Schäden an. Bemerkenswert ist aber vor allem etwas anderes. Die betroffenen Cloud-Regionen waren genau so gebaut, wie man es sich für Ausfallsicherheit wünscht – mit jeweils drei räumlich getrennten Standorten. Wer sich allein darauf verlassen hat, dem hat das am Ende nichts genützt.

Für einen Mittelständler in Oberfranken oder im Großraum Nürnberg klingt das nach einer fernen Geschichte. Die Lehre dahinter ist es nicht: Daten in der Cloud sind nicht automatisch gesichert.

Was ist passiert?

Der Fall zieht sich über mehr als ein halbes Jahr. Die wichtigsten Stationen:

• Ende Februar 2026: Die USA und Israel greifen den Iran an. Der Iran antwortet mit Raketen- und Drohnenangriffen, unter anderem auf Ziele in mehreren Golfstaaten.
• 1. März: AWS meldet, dass „Objekte" ein Rechenzentrum in den Emiraten getroffen und Funken sowie einen Brand ausgelöst haben. Die Feuerwehr schaltet die Stromversorgung ab. Kurz darauf bestätigt AWS: Zwei Rechenzentren in den Emiraten wurden direkt von Drohnen getroffen, ein drittes in Bahrain durch einen Einschlag in der Nähe beschädigt. Zu den Gebäude- und Stromschäden kommen Wasserschäden durch die Brandbekämpfung. In der Region Emirate sind zwei von drei Zonen schwer beeinträchtigt; Banken, Zahlungsdienste und die Fahrdienst-App Careem melden Störungen.
• Anfang März: AWS rät seinen Kunden, ihre Daten zu sichern, Anwendungen in andere Regionen zu verlagern und ihre Notfallpläne zu prüfen. Die Reparatur werde wegen der physischen Schäden lange dauern.
• Ende März: AWS fordert die Kunden in Bahrain auf, ihre Systeme in andere Regionen umzuziehen.
• April: Nach weiteren Schäden ist die gesamte AWS-Region in Bahrain nicht mehr verfügbar.
• Juli: Die iranischen Revolutionsgarden behaupten, die Anlage in Bahrain erneut angegriffen zu haben – diesmal mit Marschflugkörpern. Unabhängig bestätigt ist das nicht.
• 15. September: AWS erklärt, man habe alle Möglichkeiten ausgeschöpft. Auf Ressourcen und Daten, die ausschließlich in der Region Bahrain oder in der Zone „mec1-az2" in den Emiraten lagen, könne der Zugriff nicht wiederhergestellt werden. An den beiden übrigen Zonen in den Emiraten wird weiter gearbeitet, zu Bahrain will AWS Anfang 2027 informieren.

Laut AWS haben die meisten betroffenen Kunden ihren Betrieb inzwischen in andere Regionen verlagert – mithilfe von Backups oder auf anderen Wegen. Genau darin liegt der Unterschied: Wer eine Kopie außerhalb der Region hatte, konnte neu starten. Wer keine hatte, hat seine Daten verloren.

Drei Standorte – und trotzdem nicht geschützt?

Um den Fall einzuordnen, lohnt ein kurzer Blick auf den Aufbau der großen Clouds. AWS betreibt derzeit 39 sogenannte Regionen mit zusammen 124 Availability Zones. Eine solche Zone ist ein eigenständiger Standort aus einem oder mehreren Rechenzentren, mit eigener Stromversorgung, Kühlung und Netzanbindung. Microsoft Azure und Google Cloud sind nach demselben Prinzip aufgebaut.

Die Idee dahinter ist gut: Fällt eine Zone aus, etwa durch einen Stromausfall, einen Brand oder einen technischen Defekt, laufen entsprechend eingerichtete Anwendungen in den anderen Zonen weiter. Gegen die typischen Störungen des IT-Alltags ist das ein sehr wirksamer Schutz. Zwei Einschränkungen werden dabei allerdings gern übersehen:

• Drei Zonen bedeuten nicht drei Kopien. Ob Daten tatsächlich über mehrere Zonen verteilt werden, hängt vom jeweiligen Dienst ab – und davon, wie der Kunde seine Umgebung eingerichtet hat. Wer einen virtuellen Server samt Festplatte in einer einzigen Zone betreibt, hat genau einen Standort, auch wenn die Region drei hätte.
• Die Zonen einer Region liegen nah beieinander. Laut AWS sind sie viele Kilometer voneinander entfernt, aber alle innerhalb von 100 Kilometern. Das genügt gegen einen Brand oder einen örtlichen Stromausfall. Gegen ein Ereignis, das eine ganze Region trifft – einen Krieg, eine großflächige Naturkatastrophe, einen tagelangen Blackout –, genügt es nicht.

AWS räumt das in seiner Erklärung zu Bahrain bemerkenswert offen ein: Die Schäden hätten sich über mehrere Zonen erstreckt und „überstiegen, wofür unsere regionalen und Multi-AZ-Dienste ausgelegt sind". Harshwardhan Choudhary von der ABN AMRO Clearing Bank hatte schon im März auf den Punkt gebracht, was daraus folgt: Die Verteilung auf mehrere Zonen sei keine Notfallvorsorge. Sie schütze vor Hardwareausfällen, nicht vor einem Angriff auf mehrere Standorte in derselben Stadt. Oder kürzer: Redundanz innerhalb einer Region schützt nicht vor dem Verlust der ganzen Region.

Hochverfügbarkeit, Backup, Notfallplan: drei verschiedene Dinge

Der Fall zeigt, wie oft drei Begriffe in einen Topf geworfen werden, die ganz unterschiedliche Fragen beantworten:

• Hochverfügbarkeit beantwortet die Frage: Läuft mein System weiter, wenn ein Teil ausfällt? Gespiegelte Server, mehrere Zonen, doppelte Leitungen. Ziel ist, Ausfallzeiten zu vermeiden.
• Backup beantwortet die Frage: Bekomme ich meine Daten zurück, wenn sie gelöscht, beschädigt oder verschlüsselt wurden? Dafür braucht es eine unabhängige Kopie – mit älteren Ständen, an einem anderen Ort, getrennt vom Original.
• Notfallwiederherstellung (Disaster Recovery) beantwortet die Frage: Wie und wie schnell bin ich wieder arbeitsfähig, wenn ein ganzer Standort ausfällt? Dazu gehören ein dokumentierter Plan, festgelegte Wiederanlaufzeiten und ein Ort, an dem der Betrieb weiterlaufen kann.

Eine Cloud-Region mit drei Zonen ist in erster Linie ein Werkzeug für Hochverfügbarkeit. Ein Backup ist sie nicht. Dasselbe gilt für vieles, was im Büroalltag als „Cloud-Sicherung" durchgeht: Synchronisation ist kein Backup. Wird ein Ordner über OneDrive, SharePoint oder Dropbox abgeglichen, landet jede Änderung sofort überall – auch das versehentliche Löschen und auch die Verschlüsselung durch Ransomware. Ein Spiegel gibt Fehler getreu weiter.

Wer ist verantwortlich? Nicht der Anbieter.

Man könnte AWS vorwerfen, sein Versprechen gebrochen zu haben. Das greift zu kurz. Alle großen Cloud-Anbieter arbeiten nach dem Modell der geteilten Verantwortung (Shared Responsibility Model): Der Anbieter ist für die Infrastruktur zuständig – Gebäude, Strom, Hardware, Netz. Für die Daten, ihre Sicherung und die Frage, ob irgendwo eine zweite Kopie existiert, ist der Kunde verantwortlich. AWS rät in seiner Dokumentation seit Jahren, Backups in eine andere Region zu kopieren, und hat das im März noch einmal ausdrücklich empfohlen. Zugesagt war hohe Verfügbarkeit – nicht, dass Daten in einer einzigen Region jedes denkbare Ereignis überstehen.

Dass diese Verteilung der Verantwortung nicht nur im Kleingedruckten steht, zeigt ein Fall aus Europa. Im März 2021 brannte in Straßburg ein Rechenzentrum des französischen Anbieters OVHcloud vollständig aus. Ein Kunde, dessen Sicherungskopien im selben Gebäude lagen wie seine Server, verklagte den Anbieter. In erster Instanz bekam er rund 100.000 Euro Schadensersatz zugesprochen. Das Berufungsgericht in Douai reduzierte die Summe im April 2025 auf rund 1.800 Euro, die vertragliche Haftungsgrenze. Die Begründung: Nichts im Vertrag habe den Anbieter verpflichtet, die Sicherungen an einem zweiten, weit entfernten Standort aufzubewahren. Eine echte Notfallvorsorge hätte der Kunde eigens vereinbaren müssen.

Auch finanziell ist die Bilanz ernüchternd. AWS hat seinen Kunden in der Region Emirate die nutzungsabhängigen Gebühren für März erlassen. Das ist anständig – aber eine Gutschrift bringt keine Daten zurück. Die Verfügbarkeitszusagen der großen Anbieter sehen bei Ausfällen in aller Regel Gutschriften vor. Verlorene Daten ersetzen sie nicht.

Was hat das mit Ihrem Unternehmen zu tun?

Kaum ein mittelständischer Betrieb in der Region hat eine AWS-Region in Bahrain gebucht. Relevant ist der Fall trotzdem – aus drei Gründen:

• Sie nutzen die großen Clouds, oft ohne es zu wissen. Buchhaltung, Warenwirtschaft, Webshop, CRM, Branchensoftware, Online-Terminbuchung: Viele Dienste laufen im Hintergrund auf AWS, Azure oder Google Cloud. Hat Ihr Anbieter keine Ausweichstrategie, trifft Sie ein solcher Ausfall, ohne dass Sie je erfahren hätten, wo Ihre Daten eigentlich liegen.
• Krieg ist die Ausnahme – Datenverlust nicht. Der Auslöser in Bahrain war extrem, der Mechanismus ist es nicht. Brand, Wasserschaden, Stromausfall, defekte Hardware, Ransomware, ein gesperrtes Konto, ein versehentlich gelöschter Ordner oder ein Anbieter, der aufgibt: Das Ergebnis ist jedes Mal dasselbe, wenn es nur eine einzige Kopie gab.
• Auch Microsoft 365 ist kein Backup. Microsoft betreibt seine Rechenzentren hochverfügbar, doch für Ihre Daten gilt dasselbe Modell der geteilten Verantwortung wie bei AWS. Gelöschte oder verschlüsselte E-Mails, Dateien und Teams-Inhalte sind nach Ablauf der Aufbewahrungsfristen weg. Welche weiteren Lücken wir in Microsoft-365-Umgebungen immer wieder sehen, lesen Sie in Microsoft 365 richtig absichern – die häufigsten Schwachstellen.

Für Unternehmen, die unter die NIS2-Richtlinie fallen, ist das Thema zudem keine Kür: Die Richtlinie nennt Backup-Management und Notfallwiederherstellung ausdrücklich unter den Pflichtmaßnahmen. Was sonst noch dazugehört, steht in NIS2: Was Unternehmen jetzt wissen und tun müssen.

Die 3-2-1-Regel ist aktueller denn je

Die gute Nachricht: Gegen genau dieses Risiko gibt es eine bewährte Faustregel. Die 3-2-1-Regel verlangt drei Kopien Ihrer wichtigen Daten auf mindestens zwei unterschiedlichen Speichern, davon eine an einem anderen Ort. Heute wird sie meist zur 3-2-1-1-0-Regel erweitert: zusätzlich eine Kopie, die offline oder unveränderbar gespeichert ist und sich deshalb auch von Ransomware oder über ein gekapertes Administratorkonto nicht löschen lässt – und null Fehler beim regelmäßigen Wiederherstellungstest.

Für die Lehre aus Bahrain ist ein Punkt entscheidend: Die Cloud darf eine dieser Kopien sein – aber nie die einzige. Und die Kopie „an einem anderen Ort" muss wirklich unabhängig sein: anderer Standort, im Idealfall ein anderer Anbieter oder zumindest eine andere Region, getrennte Zugangsdaten. Die Grundlagen haben wir in Die 3-2-1-Regel: So schützen Sie Ihre Unternehmensdaten wirklich zusammengefasst.

Was Sie jetzt konkret tun sollten

• Wissen, wo Ihre Daten liegen. Erstellen Sie eine Übersicht aller Systeme und Cloud-Dienste – vom eigenen Server über Microsoft 365 bis zur Branchensoftware – mit Anbieter, Land und Region. Was nicht auf dieser Liste steht, wird im Ernstfall auch nicht wiederhergestellt.
• Die Anbieter fragen. Wird gesichert? Wo liegen die Sicherungen – in derselben Region oder getrennt davon? Wie lange werden sie aufbewahrt? Und können Sie Ihre Daten jederzeit vollständig exportieren? Die Antworten gehören in Ihre IT-Dokumentation.
• Eine unabhängige Kopie der wichtigen Daten. Für Microsoft 365, Cloud-Anwendungen und eigene Server gilt dasselbe: mindestens eine Kopie außerhalb des Systems, das sie schützen soll – bei einem zweiten Anbieter, im eigenen Haus oder in einem zweiten Rechenzentrum.
• Multi-AZ ist nicht Multi-Region. Wer eigene Systeme bei AWS, Azure oder Google betreibt, sollte prüfen, ob die Anwendungen tatsächlich über mehrere Zonen verteilt sind und ob die Backups in eine zweite Region kopiert werden. Das kostet mehr und macht die Umgebung komplexer – Bahrain zeigt, wogegen man sich damit absichert.
• Datensouveränität und Ausfallsicherheit zusammen denken. Sollen Ihre Daten Deutschland oder die EU nicht verlassen, ist das kein Widerspruch. Es bedeutet nur, dass die zweite Kopie an einem zweiten, räumlich getrennten Standort innerhalb dieser Grenzen liegen muss.
• Eine Kopie unveränderbar oder offline halten. Gegen Ransomware und gekaperte Konten hilft nur eine Sicherung, die sich nachträglich weder löschen noch verschlüsseln lässt.
• Die Wiederherstellung testen, nicht nur die Sicherung. Ein grünes Häkchen in der Backup-Software sagt nur, dass gesichert wurde. Ob die Rücksicherung funktioniert und wie lange sie dauert, zeigt erst der Test.
• Den Totalausfall eines Dienstes durchspielen. Was passiert, wenn Ihre wichtigste Cloud-Anwendung morgen dauerhaft weg ist? Wer entscheidet über den Umzug, in welcher Reihenfolge wird wiederhergestellt, wer informiert Kunden und Mitarbeiter? Das gehört in einen dokumentierten Notfallplan – warum dieser in vielen Betrieben fehlt, lesen Sie in IT-Dokumentation: Warum sie oft fehlt und was das kostet.
• Verträge prüfen, bevor Sie sie brauchen. Der OVH-Fall zeigt: Was nicht im Vertrag steht, schuldet der Anbieter im Zweifel nicht. Haftungsgrenzen, Sicherungsleistungen und Exportmöglichkeiten sollten Sie kennen, bevor etwas passiert.

Unser Fazit

Der Fall Bahrain ist außergewöhnlich. Dass ein Krieg die Infrastruktur eines der größten Cloud-Anbieter der Welt trifft, kommt nicht alle Tage vor. Die Lehre daraus ist dagegen ganz alltäglich: Eine Datei in der Cloud ist ausgelagert, nicht gesichert. Hochverfügbarkeit hält den Betrieb am Laufen, solange ein Teil ausfällt. Gegen den Verlust des Ganzen hilft nur eine unabhängige Kopie an einem anderen Ort.

Man muss AWS dabei kein Versagen vorwerfen. Das Unternehmen hat früh zur Sicherung und zum Umzug geraten und nie versprochen, dass Daten in einer einzigen Region jeden Angriff überstehen. Die Verantwortung für die eigenen Daten lässt sich eben nicht an einen Anbieter abgeben, ganz gleich, wie groß er ist. Die entscheidende Frage für Ihr Unternehmen lautet deshalb nicht, ob ein Rechenzentrum ausfallen kann – sondern ob Sie danach weiterarbeiten können.

So können wir Ihnen helfen

Genau hier setzen wir an: Wir sorgen dafür, dass Ihre Daten nicht an einem einzigen Ort hängen – ganz gleich, ob sie auf Ihrem Server, in Microsoft 365 oder in einer Cloud-Anwendung liegen. Mit einem Backup-Konzept, das Hochverfügbarkeit, Sicherung und Notfallplan sauber voneinander trennt und regelmäßig beweist, dass die Wiederherstellung funktioniert.

Quellen:
• heise & c't (YouTube) – „AWS gibt auf: Daten aus drei Rechenzentren nicht mehr erreichbar" (Redaktion & Video: Malte Kirchner, 16.09.2026), zum Video
• heise online / iX – „Iran-Krieg: Alle AWS-Daten in Bahrain sind zerstört" (Daniel AJ Sokolov, 15.09.2026), zum Beitrag
• heise online – „Zwei AWS-Rechenzentren direkt von Drohnen getroffen: Reparatur wird dauern" (Martin Holland, 03.03.2026), zum Beitrag
• DataCenter-Insider – „Brand nach Einschlag bei AWS, trifft der Iran jetzt auch Rechenzentren?" (Paula Breukel, 02.03.2026), zum Beitrag
• Reuters via Insurance Journal – „Amazon's AWS Facilities in Bahrain, UAE Still Not Restored From Iran War Damage" (16.09.2026), zum Beitrag
• InfoQ – „AWS Cannot Restore Data Held Only in Damaged Middle East Availability Zones" (Steef-Jan Wiggers, 21.09.2026), zum Beitrag
• InfoQ – „War in Iran Damages Multiple AWS Data Centers, Challenging Multi-AZ Assumptions" (Renato Losio, 18.03.2026), zum Beitrag
• The Register – „Iran says it's struck offline AWS facility in Bahrain ... again" (Brandon Vigliarolo, 21.07.2026), zum Beitrag
• Tech Policy Press – „The Legal and Policy Fallout from Data Center Strikes in the Middle East War" (Mahmoud Abuwasel, 12.03.2026), zum Beitrag
• LeMagIT – „Incendie de 2021 : OVHcloud gagne en appel face à Bâti Courtage" (Yann Serra, 30.04.2025), zum Beitrag
• Amazon Web Services – Regionen und Availability Zones, aws.amazon.com
Die Beiträge wurden inhaltlich eigenständig aufbereitet und für Unternehmen in Deutschland redaktionell eingeordnet.