---
title: "Redundanz statt Sicherung"
date: 2026-10-15T00:05:00Z
draft: false
image: "2026-10-15-redundanz-statt-sicherung.jpg"
formate: ["anti-pattern"]
themen: ["resilienz-vorfall", "lieferkette"]
tags: ["wiederanlauf", "verantwortungsgrenzen", "abhaengigkeit-lock-in"]
keywords: ["AWS", "OVHcloud", "me-south-1", "Shared Responsibility", "Availability Zone", "ISO 27001", "Cour d'appel de Douai"]
description: "Drei Kopien beim selben Anbieter sind eine Kopie. Ersatz gibt es in Höhe des Entgelts, nicht in Höhe des Schadens."
---

## 🔍 Was beobachte ich?

Wenn ich in Audits nach der Sicherung der Daten frage, die in der Cloud liegen, kommen zwei Antworten. Die eine lautet „Das macht der Anbieter“, die andere „Die Daten liegen dreifach“. Meist folgt ein Bild aus der Konsole: drei Verfügbarkeitszonen, alles grün. Frage ich weiter, wo die Kopie liegt, die ein anderes Konto, einen anderen Standort oder einen anderen Anbieter hat, zeigt jemand auf ein Speicherziel im selben Konto. Für die Beteiligten ist die Frage damit beantwortet. In der Risikoanalyse gilt der Datenverlust als abgedeckt.

## 🎯 Was soll eigentlich erreicht werden?

Erreicht werden soll Verfügbarkeit ohne eigenes Rechenzentrum. Die Überlegung stimmt: Ein Hyperscaler betreibt Stromversorgung, Kühlung und Replikation besser als die meisten Organisationen, und er tut es über mehrere Zonen hinweg. ISO 27001 A.8.13 verlangt Sicherungen und regelmäßige Tests – Arbeit, die eine kleine IT-Mannschaft selten zuverlässig leistet. Sie einzukaufen ist eine vernünftige Entscheidung.

## ⚠️ Warum funktioniert das nicht?

Redundanz und Sicherung beantworten verschiedene Fragen. Redundanz hält den Betrieb aufrecht, wenn ein Teil ausfällt; sie setzt voraus, dass die Kopien unabhängig voneinander versagen. Eine Sicherung beantwortet die Frage, woher die Daten wiederkommen, wenn alle Kopien zugleich verschwinden – gelöscht, verschlüsselt oder zerstört. Das Modell der geteilten Verantwortung zieht die Grenze genau hier: Der Anbieter betreibt die Infrastruktur, der Kunde entscheidet, wo seine Daten liegen und wie oft. Wer alle Kopien auf der Seite des Anbieters anordnet, hat die Verantwortung nicht geteilt, sondern verwechselt. Er übernimmt dabei eine Annahme, die niemand geprüft hat: dass die drei Zonen wirklich unabhängig voneinander ausfallen.

Mitte September 2026 erklärte AWS die Daten, die ausschließlich in seiner Region Bahrain lagen, für endgültig verloren, dazu die einer von drei Zonen in den Vereinigten Arabischen Emiraten. Iranische Drohnen hatten im Frühjahr mehrere Anlagen getroffen; der Schaden erstreckte sich über mehrere Verfügbarkeitszonen und überstieg das, was die regionalen Dienste aushalten sollen. Wer rechtzeitig in eine andere Region kopiert hatte, fing dort neu an. Wer innerhalb der Region gesichert hatte, hat nichts mehr. Fünf Jahre zuvor brannte in Straßburg ein Rechenzentrum von OVH ab. Ein Kunde, der dort die automatische Sicherung gebucht hatte, klagte, weil Produktion und Sicherung im selben Gebäude standen, und bekam erstinstanzlich 100.000 Euro zugesprochen. Die Cour d'appel de Douai kürzte den Betrag im April 2025 auf 1.800,48 Euro, die vertragliche Obergrenze in Höhe des Entgelts der letzten sechs Monate. Höhere Gewalt ließ das Gericht nicht gelten, die Haftungsbegrenzung schon. Dass die Sicherung im selben Gebäude lag, war nach dem Urteil kein Vertragsbruch: „Physisch getrennt“ verlange keine Entfernung, nur eine eigene Infrastruktur. Eine Sicherung an einem anderen Standort hatte OVH im Angebot. Damit steht die Grenze fest: Der Anbieter haftet, aber nur bis zur Höhe des Entgelts. Für den Fortbestand der Daten bleibt der Kunde zuständig.

## 💡 Was funktioniert besser?

Als Sicherung taugt eine Kopie erst, wenn sie einer anderen Gefahr ausgesetzt ist als das Original. Drei Fragen klären das. Liegt sie außerhalb der Region, besser außerhalb des Anbieters? Hängt sie an einem anderen Konto als der Produktivbetrieb? Lässt sie sich zurückspielen, ohne die ausgefallene Umgebung dafür zu brauchen? Dreimal ja, dann ist es eine Sicherung. Einmal nein, dann ist es eine weitere Kopie desselben Risikos.

 Den Anfang macht eine Tabelle für die drei Datenbestände, ohne die das Geschäft stillsteht: in welcher Region, unter welchem Konto und bei welchem Anbieter jede Kopie liegt. Wo jede Kopie in allen drei Spalten dasselbe zeigt wie das Original, ist der Befund klar, bevor ihn jemand bewertet. Dazu gehört der Wiederanlauf: Wer die Daten zurückholt, hat noch keine laufenden Systeme – Schlüssel, Konfiguration und Zugänge gehören mit gesichert.

Billig ist das nicht. Eine Kopie außerhalb kostet Speicher, Egress-Gebühren und Übung. Deshalb braucht es sie nicht für alles, sondern für das, was den Geschäftsbetrieb erhält; wofür genau, sagt die Kritikalitätsbewertung, die ohnehin im ISMS steht. Und eine zweite Region beim selben Anbieter ist der halbe Schritt. Sie hilft gegen Feuer und Krieg, nicht gegen ein gesperrtes Konto oder eine gekündigte Vertragsbeziehung.

## 📚🔍
- heise: Iran-Krieg: Alle AWS-Daten in Bahrain sind zerstört [https://www.heise.de/news/Iran-Krieg-Alle-AWS-Daten-in-Bahrain-sind-zerstoert-11454487.html](https://www.heise.de/news/Iran-Krieg-Alle-AWS-Daten-in-Bahrain-sind-zerstoert-11454487.html)
- Help Net Security: Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE [https://www.helpnetsecurity.com/2026/09/17/aws-middle-east-outage-permanent-data-loss-bahrain-uae/](https://www.helpnetsecurity.com/2026/09/17/aws-middle-east-outage-permanent-data-loss-bahrain-uae/)
- AWS Shared Responsibility Model [https://aws.amazon.com/compliance/shared-responsibility-model/](https://aws.amazon.com/compliance/shared-responsibility-model/)
- Silicon.fr: Incendie OVHcloud – la force majeure rejetée en Cour d'appel [https://www.silicon.fr/Thematique/business-1367/Breves/incendie-ovhcloud-force-majeure-rejetee-cour-appel-475454.htm](https://www.silicon.fr/Thematique/business-1367/Breves/incendie-ovhcloud-force-majeure-rejetee-cour-appel-475454.htm)
- ISO/IEC 27001:2022, A.8.13 – Information Backup [https://www.iso.org/standard/27001](https://www.iso.org/standard/27001) 🔒
