Drei Rechenzentren in vier Tagen: warum Daten verteilt gespeichert werden müssen

Was passiert ist

In der Nacht zum 8. Oktober 2026 fiel das Rechenzentrum von Yandex in Sassowo (Gebiet Rjasan) nach einem Drohnenangriff und einem Brand vollständig aus. Am Morgen des 9. Oktober wurden mehrere Module des Rechenzentrums in Kaluga beschädigt. In der Nacht zum 11. Oktober musste auch das Rechenzentrum in Wladimir abgeschaltet werden. Drei Standorte in vier Tagen – und zwei davon waren eigene Verfügbarkeitszonen der Yandex Cloud.

Die Folgen reichten weit über Yandex hinaus. Betroffen waren nach Berichten rund 64.000 Kunden der Yandex Cloud und 84 Cloud-Dienste, darunter virtuelle Server, Objektspeicher, verwaltete Datenbanken und Kubernetes. Dazu kamen eigene Dienste wie Suche, Mail, Karten, Taxi, Bezahldienst und der Cloud-Speicher Yandex Disk. Datenbanken liefen nur noch lesend, Objektspeicher war lesbar, aber nicht zuverlässig beschreibbar. Yandex selbst nannte den Betriebsmodus „Notbetrieb“, bezeichnete die verbliebene Konfiguration als „instabil“ und empfahl seinen Kunden, eigene Notfallpläne zu aktivieren. Ob dabei Daten endgültig verloren gegangen sind, war zum Zeitpunkt dieses Artikels nicht bekannt. Fachleute rechnen für den Wiederaufbau mit Wochen bis Monaten, weil Server und Speichersysteme erst beschafft werden müssen.

Drei Zonen sind keine drei Leben

Große Clouds teilen eine Region in mehrere Verfügbarkeitszonen: getrennte Gebäude mit eigener Stromversorgung und Kühlung. Fällt eine Zone aus, übernehmen die anderen. Genau so ist auch die Yandex Cloud gebaut. Die Dokumentation verspricht, dass Dienste den Ausfall einer Zone überstehen. Am 8. Oktober hat das funktioniert.

Viele verteilte Systeme arbeiten aber mit Mehrheitsentscheidungen: Von drei Kopien einer Datenbank oder drei Steuerknoten eines Kubernetes-Clusters müssen mindestens zwei erreichbar sein, sonst darf keiner mehr schreiben. Wer zwei von drei Zonen verliert, verliert dieses Quorum. Das System bleibt im Lesemodus stehen oder fällt ganz aus, bis ein Mensch eingreift.

Die eigentliche Lehre ist deshalb nicht „Rechenzentren können ausfallen“. Das wusste jeder. Die Lehre ist: Mehrere Rechenzentren desselben Anbieters, in derselben Region und unter derselben Steuerung fallen nicht unabhängig voneinander aus. Ein Stromnetz, ein Konflikt, ein Hochwasser, ein Fehler im zentralen Management oder ein Angriff auf die Verwaltungsebene kann alle gleichzeitig treffen. Fachleute nennen das korrelierte Ausfälle. Sie sind der Grund, warum das Bundesamt für Sicherheit in der Informationstechnik (BSI) für georedundante Rechenzentren einen Abstand von in der Regel mindestens 200 Kilometern empfiehlt.

Verteilte Speicherung: wie sie funktioniert

Es gibt zwei Grundverfahren, Daten so zu speichern, dass der Verlust einzelner Standorte nichts ausmacht.

Replikation. Jede Datei liegt mehrfach vollständig vor, zum Beispiel dreimal an drei Orten. Das ist einfach und schnell, kostet aber das Dreifache an Speicher. Und es schützt nur, wenn die drei Orte wirklich unabhängig sind.

Erasure Coding. Eine Datei wird in Teile zerlegt und um Prüfteile ergänzt, ähnlich wie bei RAID 5 oder 6, nur über viele Standorte. Bei einem Verfahren „k aus n“ genügen beliebige k von n Teilen, um die Datei wiederherzustellen. Ein Beispiel aus der Praxis: Der Dienst Storj zerlegt jede Datei in 80 Teile, von denen 29 ausreichen. Es können also mehr als die Hälfte der Speicherorte gleichzeitig ausfallen, und der Speicherbedarf liegt trotzdem nur beim knapp Dreifachen. Aus unserer Arbeit an RAID-Systemen kennen wir die Kehrseite: Ist die Zuordnung der Teile verloren, sind auch vollständige Teile wertlos. Die Metadaten müssen genauso verteilt und gesichert sein wie die Daten selbst.

Beide Verfahren lassen sich im eigenen Haus betreiben. Ceph ist das verbreitetste Open-Source-System dafür und läuft bei Forschungseinrichtungen, Hostern und Unternehmen über mehrere Standorte hinweg. Objektspeicher wie MinIO oder OpenStack Swift arbeiten ebenfalls mit Erasure Coding und Replikation zwischen Standorten.

Dezentrale Speichernetze

Einen Schritt weiter gehen Projekte, bei denen kein einzelner Betreiber mehr die Rechenzentren stellt. Tausende unabhängige Anbieter in vielen Ländern stellen Festplatten bereit, ein Protokoll verteilt die Daten und prüft regelmäßig, ob sie noch vorhanden sind.

• IPFS (InterPlanetary File System) adressiert Dateien nicht nach ihrem Speicherort, sondern nach ihrem Inhalt: Die Adresse ist ein Prüfwert der Datei. Jeder Knoten, der die Datei hat, kann sie ausliefern. IPFS selbst garantiert keine dauerhafte Speicherung, ist aber die Grundlage vieler anderer Projekte.
• Filecoin baut darauf einen Markt für Speicherplatz. Anbieter müssen kryptografisch nachweisen, dass sie eine eigene Kopie angelegt haben (Proof of Replication) und dass sie diese über die Zeit behalten (Proof of Spacetime). Seit Ende 2025 arbeitet das Projekt unter dem Namen Filecoin Onchain Cloud an Diensten, die sich wie ein klassischer Cloud-Speicher nutzen lassen.
• Storj richtet sich an Unternehmen, die einen S3-kompatiblen Objektspeicher suchen, und setzt auf das oben beschriebene Erasure Coding über weltweit verteilte Knoten. Daten werden vor dem Hochladen verschlüsselt.
• Arweave verfolgt einen anderen Ansatz: einmal bezahlen, dauerhaft speichern. Ein Teil der Gebühr fließt in einen Fonds, aus dem die Speicherung über sehr lange Zeit finanziert werden soll. Genutzt wird es vor allem für Archive und Daten, die nicht verändert werden dürfen.
• Walrus, entwickelt von Mysten Labs und seit 2025 in Betrieb, ist auf große Dateien spezialisiert und kommt mit einem Speicheraufwand von rund dem Viereinhalbfachen aus, obwohl es viele gleichzeitige Ausfälle verkraftet.
• Sia ist eines der ältesten Projekte dieser Art und verbindet Mieter und Anbieter von Speicherplatz über Verträge auf einer Blockchain.

Verteiltes Rechnen

Daten zu retten nützt wenig, wenn die Anwendungen, die sie brauchen, nicht laufen. Auch beim Rechnen gibt es verteilte Ansätze.

• BOINC von der University of California, Berkeley, verteilt seit 2002 wissenschaftliche Rechenaufgaben auf Rechner von Freiwilligen in aller Welt – ein frühes Beispiel dafür, dass verteiltes Rechnen im großen Maßstab funktioniert.
• Akash Network ist ein offener Markt für Rechenleistung: Container und GPU-Lasten laufen bei unabhängigen Anbietern statt bei einem einzelnen Cloud-Konzern.
• Golem verbindet ebenfalls Anbieter und Nutzer freier Rechenkapazität, etwa für Rendering und Berechnungen.
• Kubernetes über mehrere Clouds ist der pragmatische Weg vieler Unternehmen: dieselbe Anwendung läuft in zwei unabhängigen Clouds oder in Cloud und eigenem Rechenzentrum, und der Verkehr wird bei einem Ausfall umgeleitet.
• European Edge Continuum: Im Februar 2026 haben Deutsche Telekom, Orange, Telefónica, TIM und Vodafone eine gemeinsame Edge-Cloud vorgestellt, über die Anwendungen auf der Infrastruktur aller fünf Netzbetreiber laufen können. Sie baut auf dem EU-Förderprogramm IPCEI-CIS auf, das eine europäische Cloud-Edge-Infrastruktur schaffen soll.

Vorteile – und die Grenzen

Verteilte Systeme haben klare Vorteile. Es gibt keinen einzelnen Ort, dessen Verlust alles lahmlegt. Kein einzelner Anbieter kann den Zugang sperren oder abschalten. Und bei Ende-zu-Ende-Verschlüsselung sieht ein einzelner Speicherknoten nur unlesbare Bruchstücke.

Es gibt aber auch Grenzen, die man kennen sollte:

• Geschwindigkeit. Daten aus vielen Teilen zusammenzusetzen dauert länger als ein Zugriff im selben Rechenzentrum. Für Datenbanken mit vielen kleinen Schreibzugriffen sind öffentliche dezentrale Netze kaum geeignet.
• Datenschutz. Bei öffentlichen Netzen weiß man oft nicht, in welchem Land die Teile liegen. Für personenbezogene Daten nach DSGVO ist das ein Problem – Verschlüsselung vor dem Hochladen ist dann Pflicht, und für viele Unternehmen bleibt ein eigenes, verteiltes System in der EU der sicherere Weg.
• Wirtschaftliche Risiken. Viele dezentrale Netze bezahlen ihre Anbieter in eigenen Kryptowährungen. Fällt der Kurs, steigen Anbieter aus. Ein Projekt ist nur so beständig wie sein Geschäftsmodell.
• Komplexität. Ein verteiltes System muss getestet werden. Wer nie geprüft hat, ob die Wiederherstellung aus der zweiten Region tatsächlich funktioniert, hat im Ernstfall nur eine Annahme.

Warum das für die Informationssicherheit entscheidend ist

Informationssicherheit wird oft auf Vertraulichkeit reduziert: Niemand Unbefugtes soll Daten lesen. Gleichrangig sind aber Integrität und Verfügbarkeit. Der Fall Yandex zeigt, dass Verfügbarkeit nicht nur durch Hacker bedroht wird, sondern durch Strom, Feuer, Wasser und Konflikte – und dass ein Angreifer, der die Konzentration kennt, mit wenigen Treffern sehr viel erreicht.

Die europäische NIS2-Richtlinie verpflichtet viele Unternehmen ausdrücklich zu Notfallplanung, Backup-Management und Wiederherstellung. Das bloße „Wir sind in der Cloud“ erfüllt diese Pflicht nicht. Entscheidend ist, ob eine Kopie der Daten an einem Ort liegt, der von demselben Ereignis nicht getroffen werden kann.

Was Unternehmen jetzt prüfen sollten

1. Wo liegen die Kopien wirklich? Nicht „in drei Zonen“, sondern: in welchen Gebäuden, wie weit voneinander entfernt, bei welchem Anbieter.
2. 3-2-1-1-Regel. Drei Kopien, auf zwei verschiedenen Medien, eine davon an einem anderen Ort, eine davon offline oder unveränderbar – zum Beispiel auf Band oder auf einer abgezogenen Festplatte im Tresor.
3. Einen zweiten Anbieter einplanen. Mindestens die Sicherungen sollten außerhalb der Cloud liegen, in der die Produktivdaten laufen.
4. Den Ernstfall üben. Einmal im Jahr eine vollständige Wiederherstellung an einem anderen Ort durchspielen und die Zeit messen.
5. Schlüssel und Zugänge sichern. Ohne Passwörter, Verschlüsselungsschlüssel und Zugriff auf die Verwaltung nützt auch die beste Kopie nichts.

Wenn trotzdem alles weg ist

Auch wenn Rechenzentren brennen, sind die Daten auf den Festplatten und SSDs nicht automatisch verloren. Laufwerke nach Brand-, Lösch- und Wasserschäden landen regelmäßig in unserem Labor, ebenso Server und Speichersysteme, deren Verbund nicht mehr startet. Ob und was sich retten lässt, hängt von der Temperatur, dem Löschmittel und der Zeit bis zur Bergung ab. Wichtig ist, beschädigte Laufwerke nicht wieder einzuschalten und die Reihenfolge der Laufwerke in einem Verbund zu dokumentieren. Wie wir dabei vorgehen, steht auf unserer Seite zur Datenrettung von RAID, NAS und Servern.

Quellen: Statusmeldungen der Yandex Cloud (Vorfall 2136), Berichte von Habr, BleepingComputer, The Moscow Times und TKS.ru vom 8. bis 12. Oktober 2026; Projektdokumentationen von Storj, Filecoin, Arweave und Walrus; Pressemitteilung der Deutschen Telekom vom 23. Februar 2026.