Georedundanz: wie weit der Ausweichstandort für Disaster Recovery vom primären Rechenzentrum entfernt sein sollte

Wie weit ein Ausweichstandort entfernt sein sollte

Ein Ausweichstandort für Disaster Recovery sollte so weit vom primären Rechenzentrum entfernt sein, dass kein einzelner Brand, kein Hochwasser, kein Ausfall des Stromnetzes und kein regionales Ereignis beide außer Betrieb setzen kann, und zugleich nah genug für den Replikationsmodus, den sein Wiederherstellungspunkt erfordert. Die NIS2-Durchführungsverordnung (EU) 2024/2690 nennt keine Zahl und verlangt Sicherungskopien an Orten, die sich „in ausreichend großer Entfernung befinden, um Schäden durch einen Notfall am Hauptstandort zu vermeiden“ (Anhang, Punkt 4.2.2 Buchstabe c). Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt mindestens 200 km zwischen georedundanten Rechenzentren, wie die Normungsorganisation DKE 2019 und das Beratungsunternehmen ComConsult 2025 berichteten.

Die Obergrenze setzt der Replikationsmodus, und die Hersteller geben sie meist als Round-Trip-Time (RTT) an. Synchrone Replikation, bei der ein Schreibvorgang erst abgeschlossen ist, wenn er an beiden Standorten vorliegt, wird bis zu einigen Millisekunden unterstützt; Broadcom erlaubt zwischen den beiden Datenstandorten eines vSAN Stretched Clusters höchstens 5 ms RTT. Asynchrone Replikation bestätigt jeden Schreibvorgang lokal und funktioniert deshalb auch zwischen Ländern.

Brauchen einige Systeme einen Wiederherstellungspunkt von null, arbeiten Sie mit zwei Entfernungen: einem synchronen Standortpaar auf Metro-Distanz für diese Systeme und einer asynchronen Kopie, die für den Fall einer regionalen Katastrophe weit genug entfernt ist. Ist ein Datenverlust von Minuten hinnehmbar, deckt ein entfernter asynchroner Standort allein sowohl den Verlust des Primärstandorts als auch eine regionale Katastrophe ab.

Risiken, die zwei Standorte je nach Entfernung teilen

Da jede Art von Ereignis ihre eigene Reichweite hat, gehen Sie von dem aus, was die beiden Standorte gemeinsam haben. Gebäude auf einem Campus teilen meist die Stromeinspeisung, die Zufahrtswege, den Betreiber und das Personal. Als am 10. März 2021 am Standort Straßburg von OVHcloud ein Brand ausbrach, konnte die Feuerwehr laut der Darstellung des Betreibers erst eingreifen, „nachdem die Stromversorgung für den gesamten Standort einschließlich aller vier Rechenzentren abgeschaltet worden war“.

Standorte in einem Land teilen meist ein Übertragungsnetz, und benachbarte Netze können gemeinsam ausfallen. ENTSO-E berichtet, dass am 28. April 2025 „die Stromsysteme des spanischen Festlands und Portugals einen vollständigen Blackout erlitten“; Standorte in zwei Ländern, Hunderte Kilometer voneinander entfernt, verloren also gemeinsam die Netzversorgung, während das übrige europäische Stromsystem keine nennenswerte Störung erfuhr. Hochwasser folgt einem Fluss durch sein Tal, und Glasfaser ist bei jeder Entfernung ein gemeinsames Risiko, wenn die Leitungen beider Standorte durch denselben Kabelkanal oder dieselbe Vermittlungsstelle eines Carriers laufen. Punkt 4.2.4 der Verordnung zählt auch das Personal zu den Ressourcen, für die eine zumindest teilweise Redundanz vorzusehen ist.

Gegen logische Schäden schützt Entfernung nicht, denn die Replikation kopiert alles, was geschrieben wurde, verschlüsselte oder beschädigte Daten eingeschlossen, an den zweiten Standort, die synchrone Replikation sofort. Der Schutz davor erfordert Wiederherstellungspunkte aus der Zeit vor dem Schaden, die sich weder ändern noch löschen lassen; diese behandelt unser Artikel dazu, wovor unveränderliche Backups schützen.

Unsere Einteilung. RTT-Grenzen: Dokumentation von Broadcom und NetApp (August bis Oktober 2026); Ereignis im Stromnetz: ENTSO-E (aktualisiert am 20. März 2026); Stromabschaltung auf dem Campus: Darstellung von OVHcloud zum Brand in Straßburg (2021).

Was EU-Regeln, das BSI und NIST zur Entfernung sagen

Der Anhang der Durchführungsverordnung (EU) 2024/2690 konkretisiert die NIS2-Maßnahmen für die in ihrem Artikel 1 genannten Anbieter und verlangt, dass sie ihre Sicherungspläne auf der Grundlage ihrer eigenen Risikobewertung festlegen. Die Leitlinie der ENISA vom Juni 2025 führt „Failover-Standorte in anderen Regionen“ unter den Wiederherstellungsmaßnahmen auf. Ob die Verordnung oder das nationale Gesetz zur Umsetzung von NIS2 Ihr Unternehmen bindet, ist von Ihrer Rechtsabteilung zu bewerten.

Von den Quellen in der Tabelle unten nennt nur das BSI eine Entfernung. Seine „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“, erstmals Ende 2018 veröffentlicht, empfahlen einen Mindestabstand von ca. 200 km zwischen Rechenzentren, die einander Georedundanz geben. Ein deutlich geringerer Abstand erforderte eine schriftliche Begründung und eine Risikoanalyse, und 100 km waren die Untergrenze, so der Wortlaut, den das deutsche Normungsgremium DKE/GK 719 im März 2019 zitierte. Das Gremium entgegnete, eine Risikobewertung sei grundsätzlich festen Vorgaben für Abstände vorzuziehen, und die Rechenzentrumsnorm EN 50600 verzichte bewusst auf die Nennung von Zahlen.

Version 2.0 folgte im Oktober 2019. Die aktuelle Version 2.1 vom 18. Dezember 2024 heißt „Kriterien für die Standortwahl von Rechenzentren“ und ergänzt Abschnitte zu Kommunikationswegen und -verbindungen sowie zu den rechtlichen Rahmenbedingungen. Die Zusammenfassung dieser Version durch ComConsult (März 2025) nennt 200 km als Mindestabstand und 100 km als Untergrenze, wenn sich im begründeten Einzelfall ein geringerer Abstand nicht vermeiden lässt. Es handelt sich um die Empfehlung einer nationalen Behörde, nicht um eine EU-Vorschrift. NIST SP 800-34 Rev. 1 verlangt einen Ausweichstandort in einem Gebiet, das „wahrscheinlich nicht von derselben Gefahr beeinträchtigt wird“, ausgewählt unter Berücksichtigung der Zeit, die Personal und Ausrüstung bis dorthin brauchen.

Durchführungsverordnung (EU) 2024/2690, Anhang; ENISA Technical Implementation Guidance v1.0 (26. Juni 2025); Versionsdaten des BSI von den Seiten des BSI, Zahlen für Version 2.1 aus der Zusammenfassung von ComConsult (5. März 2025); Stellungnahme des DKE/GK 719 (20. März 2019); NIST SP 800-34 Rev. 1 (Mai 2010).

Latenzgrenzen für synchrone Replikation

Synchrone Replikation beschreibt der „Data Center High Availability Clusters Design Guide“ von Cisco so: „Alle Daten werden in das lokale Speicherarray und in das entfernte Array geschrieben, bevor die I/O-Operation als abgeschlossen gilt oder dem Host bestätigt wird.“ Jeder Schreibvorgang wartet auf mindestens einen Round Trip, ein Fibre-Channel-Schreibvorgang ohne Write Acceleration auf zwei. Derselbe Leitfaden beziffert die Latenz des Lichts in der Glasfaser auf „ungefähr 5 µs pro Kilometer“, also etwa 1 ms Round Trip je 100 km Trasse. NetApp plant die Verbindungen für MetroCluster IP nach derselben Regel: „Sie müssen 1 ms je 100 km einplanen.“ Die Glasfasertrasse ist nie kürzer als die Luftlinie, und jeder Switch, jeder Router, jedes DWDM-System und jede Firewall fügt Latenz hinzu; in den Worten von NetApp: „Jedes Gerät, das zur Latenz beiträgt, muss berücksichtigt werden.“

Nach unserer Rechnung schafft ein Datenbank-Log, das einen Block nach dem anderen schreibt und dabei jedes Mal 5 ms auf den anderen Standort wartet, höchstens 200 Schreibvorgänge pro Sekunde, noch bevor die Latenz seines eigenen Speichers hinzukommt. Bei 1 ms liegt die Obergrenze bei 1.000.

Die Dokumentation von Broadcom zu VCF 9.1 (aktualisiert am 5. Oktober 2026) hält fest, dass die beiden Datenstandorte eines vSAN Stretched Clusters „eine Netzwerklatenz von höchstens fünf Millisekunden (5 ms) Round Trip (RTT) haben müssen“. Die Dokumentation zu VCF 9.0 und vSAN 8.0 nennt dieselben 5 ms. NetApp verlangt für SnapMirror active sync eine RTT zwischen den Clustern von weniger als 10 ms. Da dies Höchstwerte der Produkte sind, messen Sie die RTT auf Ihrer Verbindung unter Last und testen Sie die Schreiblatenz Ihrer am stärksten ausgelasteten Datenbank, bevor Sie sich auf einen Standort festlegen.

Beide Produkte nutzen außerdem einen dritten Ort. vSAN platziert einen Witness-Host „an einem dritten Standort“ als Tie-Breaker, mit weniger als 200 ms RTT zu den Datenstandorten. NetApp verlangt den ONTAP Mediator „in einer dritten Fehlerdomäne, getrennt von den beiden ONTAP-Clustern“. Die Einzelheiten stehen in unserem Artikel zu den Anforderungen an einen vSAN Stretched Cluster.

Asynchrone Replikation über große Entfernungen

Bei asynchroner Replikation, so der Leitfaden von Cisco, „werden die Daten in das entfernte Array repliziert, nachdem die I/O-Operation dem Host als abgeschlossen bestätigt wurde“; die Entfernung bremst die Anwendung also nicht mehr. Die Dokumentation von Broadcom zu vSphere Replication 9.0 nennt „keine feste Anforderung“ an die WAN-Latenz zwischen den Rechenzentren, warnt aber, dass Latenz sowie Pakete, die in falscher Reihenfolge ankommen oder verworfen werden, den Replikationsdurchsatz senken und RPO-Verletzungen verursachen können.

An einem entfernten Standort hängt der Wiederherstellungspunkt von der Bandbreite im Verhältnis zur Änderungsrate ab. Das Replikat ist so alt wie die letzte abgeschlossene Übertragung; die Verbindung muss also alles übertragen, was sich innerhalb eines Intervalls geändert hat, bevor das nächste beginnt. Dieselbe Dokumentation bemisst die Verbindung nach „der Datenänderungsrate innerhalb des RPO-Zeitraums“ und geht davon aus, dass nur etwa 70 Prozent einer Verbindung für die Replikation zur Verfügung stehen. Messen Sie die Änderungsrate jedes Systems über mehrere Tage, Monatsabschluss und Datenbankwartung eingeschlossen.

Unser Service Cloud Disaster Recovery repliziert virtuelle Maschinen mit Veeam ab einem 15-Minuten-Intervall. Beschreiben Sie die Systeme, die Sie replizieren würden, und ihre Wiederherstellungsziele im Formular unten.

Ein Ausweichstandort in einem anderen EU-Land

Ein Standort in einem anderen Mitgliedstaat liegt im Netz eines anderen Übertragungsnetzbetreibers und oft in einem anderen Flusseinzugsgebiet und Wettersystem; damit fallen viele physische Ereignisse von der Liste der gemeinsamen Risiken, wenn auch nicht jeder Ausfall des Stromnetzes. Meist bedeutet er auch eine längere Glasfasertrasse, und 1.000 km Trasse fügen jedem Round Trip mindestens 10 ms hinzu, jenseits der oben genannten Grenzen für synchrone Replikation.

Für nicht personenbezogene Daten verbietet die Verordnung (EU) 2018/1807 Datenlokalisierungsauflagen, es sei denn, sie sind unter Wahrung des Grundsatzes der Verhältnismäßigkeit aus Gründen der öffentlichen Sicherheit gerechtfertigt. Ob personenbezogene Daten in den Replikaten, eine Branchenvorschrift oder ein Vertrag einschränken, wo die Kopien liegen dürfen, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

An einem gehosteten Standort arbeitet Ihr Team aus der Ferne, und ein VPN, das am Primärstandort endet, fällt mit diesem aus. Planen Sie einen Zugangsweg, der nicht vom Primärstandort abhängt, und nutzen Sie ihn bei jedem Failover-Test.

Unser Ausweichstandort liegt in Baltnetas Tier-3-Rechenzentren in Litauen, geographisch von Ihrer Primärinfrastruktur getrennt, mit EU-Datenresidenz. Nennen Sie uns, wo Ihr Primärstandort liegt und welche Systeme Sie zuerst replizieren würden.

Was die Kosten der Georedundanz bestimmt

Der größte Teil der Kosten ergibt sich aus dem Replikationsmodus. Ein synchrones Standortpaar braucht eine zweite Ausstattung an Rechen- und Speicherkapazität, die ständig läuft, und bei den oben genannten Produkten einen dritten Ort für Witness oder Mediator. Seine Verbindungen müssen innerhalb der RTT-Grenze des Herstellers bleiben, vorzugsweise über zwei getrennte Glasfasertrassen. Ein asynchroner Standort braucht Kapazität und Lizenzen nur für die Systeme, die Sie dort starten würden, und eine nach der Änderungsrate bemessene Verbindung; das kann eine verschlüsselte Internetverbindung leisten. Beide brauchen regelmäßige Wiederherstellungstests, wie sie Punkt 4.2.6 der Verordnung verlangt.

Ein gehosteter Ausweichstandort ersetzt das zweite Rechenzentrum durch ein Abonnement für Kapazität, Replikation, Tests und Support. Was Sie in einem solchen Vertrag prüfen sollten, steht in unserer DRaaS-Checkliste vor der Unterschrift, und was jede Art von Standort bereithält, in unserem Vergleich von Hot Site, Warm Site und Cold Site.

Wie Sie die Entfernung für Ihre Systeme wählen

1. Listen Sie auf, was den Primärstandort stilllegen kann: seinen Fluss und seine Hochwasserzonen, das Umspannwerk und den Netzbetreiber, die ihn versorgen, die Carrier und Kabelkanäle seiner Leitungen, Industriebetriebe in der Nachbarschaft und den Wohnort seines Personals.
2. Legen Sie RPO und RTO für jede Systemstufe fest, wie in unserem Leitfaden zur Wahl von RPO und RTO beschrieben.
3. Suchen Sie für die Stufe, die einen Wiederherstellungspunkt von null braucht, einen zweiten Standort, dessen unter Last gemessene RTT in die Grenze Ihres Produkts passt, und prüfen Sie ihn gegen diese Liste.
4. Wählen Sie für alles andere einen asynchronen Standort, der keinen der Einträge dieser Liste teilt.
5. Bemessen Sie die Verbindung nach der Änderungsrate jedes Systems innerhalb seines RPO-Intervalls, mit Reserve für Spitzen.
6. Halten Sie schriftlich fest, warum die Entfernung ausreicht; die oben beschriebenen BSI-Kriterien verlangen unter 200 km eine Begründung.
7. Testen Sie den Failover und dokumentieren Sie die gemessene Wiederherstellungszeit im Vergleich zum RTO.

Was wir tun

Unser Service Cloud Disaster Recovery stellt Ihnen einen Ausweichstandort in Baltnetas Tier-3-Rechenzentren in Litauen (ISO 27001, PCI DSS) bereit, geographisch von Ihrer Primärinfrastruktur getrennt und mit EU-Datenresidenz. Virtuelle Maschinen werden mit Veeam ab einem 15-Minuten-Intervall via Veeam Cloud Connect repliziert, verwaltet aus Ihrer bestehenden Veeam-Konsole oder komplett auf unserer Seite; RPO und RTO sind im SLA fixiert. Unser Engineering-Partner Vixen.UNO entwickelt mit Ihnen die DR-Strategie, einschließlich der Katastrophenszenarien, gegen die Sie sich absichern, und führt planmäßige Failover-Tests in isolierter Umgebung durch, mit einem Bericht nach jedem Test. Braucht ein System einen RPO von null, ist das Aktiv-aktiv-Synchron-Clustering, eine andere Lösungs- und Budgetklasse, und das sagen wir im ersten Gespräch. Das erste Gespräch ist kostenlos. Den Service und unseren Umgang mit Ihren Daten beschreiben unsere Seiten Cloud Disaster Recovery und Sicherheit & Compliance.

FAQ