Disaster Recovery
DR-Standortauswahl
Ein Disaster-Recovery-Standort muss weit genug entfernt sein, um keine gemeinsame Katastrophe zu teilen, und nah genug für den benötigten Replikationsmodus. Diese zwei Bedingungen — plus die Facilities, die auf dem Kandidatenmarkt tatsächlich vorhanden sind — bestimmen die Auswahlliste, bevor es mit Anbietern ins Gespräch geht. Das Tool unten führt alle drei gegen echte Daten auf: gemessene Round-Trip-Zeiten zwischen 14 Märkten und den 1629-Facility-Katalog.
DR-Paar-Finder
Wählen Sie Ihren primären Markt. Kandidaten werden nach Round-Trip-Zeit sortiert, mit dem Replikationsmodus, den jede Entfernung unterstützt.
| DR-Kandidat | RTT | Unterstützte Replikation | Facilities im Markt |
|---|
RTT-Werte sind veröffentlichte Cloud-Inter-Region-Messungen (Azure, cloudping.co) — Quellen in der Latenz-Matrix. Faserstrecken zwischen Colocation-Facilities folgen ähnlichen Routen; überprüfen Sie das genaue Paar mit den Operatoren, bevor Sie sich auf einen RPO festlegen.
Replikationsmodus wird durch die Physik bestimmt
Licht in Glasfasern überwindet etwa 100 km pro Millisekunde Roundtrip-Zeit. Diese eine Zahl entscheidet die Architektur: Synchrone Replikation benötigt die Roundtrip-Zeit innerhalb des Schreib-Budgets der Anwendung, was die Distanz auf etwa 100 km begrenzt — und alles darüber ist asynchron, egal was die Speicherschicht verspricht.
| Modus | RTT-Budget | RPO | Was es bedeutet |
|---|---|---|---|
| Synchron | ≤ ~10 ms | Null | Jeder Schreibvorgang wird an beiden Standorten bestätigt, bevor die Anwendung fortfährt. Die Transaktionslatenz beinhaltet den Hin- und Rückweg, weshalb Entfernung zu einer Anwendungslast wird. |
| Quasi-synchron | ~10–25 ms | Sekunden | Schreibvorgänge werden kontinuierlich mit gelockerten Bestätigungen übertragen. Die praktische Wahl für Metropol-Paare wie Frankfurt–Amsterdam oder Singapur–Kuala Lumpur. |
| Asynchron | Beliebig | Minuten | Der DR-Standort hinkt um das Replikationsintervall hinterher. Die einzige Option über große Entfernungen – und ohnehin die beste Lösung für die meisten Arbeitslasten. |
Vier DR-Muster, ehrlich bepreist
Kosten werden als Anteil der Betriebskosten des Primärstandorts ausgedrückt. Das Muster entscheidet über RTO; der Replikationsmodus entscheidet über RPO; und die Kombination entscheidet über das Budget. Die meisten Infrastrukturen nutzen unterschiedliche Muster für verschiedene Workload-Ebenen – aktiv-aktiv für den Umsatzpfad, Sicherung und Wiederherstellung für alles, das einen Tag warten kann.
| Muster | RPO | RTO | Kosten vs. Primär | Wie es funktioniert |
|---|---|---|---|---|
| Sicherung und Wiederherstellung | Stunden–Tag | Tage | ~5% | Sicherungen außerhalb repliziert, Infrastruktur nur bei Katastrophe errichtet. Günstig, langsam, und die Wiederherstellung ist der Teil, den niemand getestet hat. |
| Minimales Standby | Minuten–Stunden | Stunden | ~10–20% | Kerndaten werden auf einen minimalen Footprint repliziert, der bei Failover hochgefahren wird. Einige Racks am DR-Standort führen die Datenbanken, Rechenkapazität wird bei Bedarf hinzugefügt. |
| Warmer Standby | Sekunden–Minuten | Minuten–Stunde | ~30–50% | Eine skalierte Kopie der Produktion läuft kontinuierlich. Failover ist eine Hochstufung, kein Aufbau. |
| Aktiv-Aktiv | ≈ Null | ≈ Null | 100%+ | Beide Standorte verarbeiten Traffic; der Verlust eines Standorts ist ein Kapazitätsereignis, kein Ausfall. Dies erfordert, dass die Anwendung dafür konzipiert ist – Nachrüstung ist ein Neuschreiben. |
Modellieren Sie die Kosten des Standby-Footprints mit dem Colocation-Kostenrechner zum Index-Tarif des Zielmarkts.
Was tatsächlich ausfällt
Die DR-Planung stellt sich oft Erdbeben vor. Das Incident Log zeigt, dass die realen Bedrohungen näher beim Stromzähler liegen: Stromversorgungsstörungen, USV-Brände, Kühlungsausfälle und Netzwerkhardware-Fehler. Ein DR-Standort im gleichen Stromnetz, in der gleichen Überschwemmungszone, hinter dem gleichen Carrier Hotel bietet kaum Schutz. Aktuelle Einträge:
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
Die DR-Standort-Checkliste
- Anderes Stromnetz als das primäre – überprüfen Sie die tatsächliche Umspannstation, nicht die Marketing-Aussage
- Außerhalb der Überschwemmungszone und des Erdbebengefährdungsgebiets des primären Standorts
- Unterschiedliche Faserrouten: Die beiden Standorte dürfen sich kein Carrier Hotel oder Kabellanding teilen
- RTT gemessen, nicht geschätzt – und im Budget Ihres gewählten Replikationsmodus
- Rechenzentrum mit Zertifizierung auf dem erwarteten Compliance-Niveau — siehe Zertifizierungsverzeichnis
- Kapazität vertraglich erweiterbar: Ein DR-Standort, den Sie bei einer echten Katastrophe nicht skalieren können, ist eine Dekoration
- Remote Hands mit vertraglich festgelegten Reaktionszeiten — bei regionalen Ereignissen müssen Sie nicht anreisen
- Failover von Ende zu Ende vor dem Go-Live getestet, dann jährlich — ein Plan ist keine Fähigkeit
Häufig gefragt
Wie weit sollten primäre und DR-Rechenzentren auseinander liegen?
Weit genug entfernt, um sich keine Katastrophe zu teilen, nah genug für Ihren Replikationsmodus. Das Minimum sind separate Stromnetze, separate Überschwemmungsgebiete und separate Carrier-Pfade – praktisch 50 km oder mehr. Synchrone Replikation begrenzt die Entfernung auf etwa 100 km (etwa 10 ms Round-Trip); asynchrone Replikation hebt diese Grenze ganz auf. Viele Regulierer im asiatisch-pazifischen Raum fordern DR außerhalb des Landes, was asynchrone Replikation erzwingt.
Was ist der Unterschied zwischen RPO und RTO?
RPO (Recovery Point Objective) ist die Menge an Daten, die Sie verlieren können, und wird durch den Replikationsmodus bestimmt. RTO (Recovery Time Objective) ist die Zeit, die Sie offline sein können, und wird durch das DR-Muster bestimmt – Backup-Restore erholt sich in Tagen, Active-Active in Sekunden. Die Kosten skalieren mit beiden: Das Straffen einer der beiden um eine Größenordnung verdoppelt das DR-Budget ungefähr.
Funktioniert synchrone Replikation zwischen Ländern?
Nur zwischen benachbarten Ländern. Singapore–Kuala Lumpur mit ~8 ms RTT unterstützt es; Frankfurt–Amsterdam mit ~11 ms ist grenzwertig. Alles über ~25 ms ist asynchrones Gebiet, unabhängig davon, was das Datenblatt des Speicheranbieters sagt – jeder Schreibvorgang würde die Round-Trip-Latenzen mit sich bringen, und das Anwendungsteam wird es vor dem DR-Team bemerken.
Was bringt Rechenzentren tatsächlich zum Stillstand?
Unser Incident-Log wird durch Stromereignisse dominiert (Stromversorgungsstörungen und USV-Ausfällen), Brände (Lithium-Ionen-Batterieräume treten wiederholt auf), Kühlausfälle und Netzwerk-Hardware-Fehler – nicht regionale Naturkatastrophen. Die praktische Folge: Ein DR-Standort in derselben Metropolregion im gleichen Stromnetz schützt vor fast keinem der Vorfälle, die auf Anlagenebene tatsächlich auftreten, während ein Standort ein Land weiter vor fast allen schützt.
Ist die Public Cloud ein gültiger DR-Standort für Colocation-Workloads?
Für Backup-Restore- und Pilot-Light-Muster ist dies oft der Fall — Sie zahlen für Standby-Kapazität nur, wenn sie läuft, was genau dem Cloud-Preismodell entspricht. Der Haken liegt in den Datenübertragungskosten beim Rückweg und der betrieblichen Lücke: Die Wiederherstellung einer Colocation-Infrastruktur in der Cloud erfordert, zwei Deployment-Ziele dauerhaft zu verwalten. Testen Sie die vollständige Wiederherstellung, nicht die Replikation.
Wie oft sollte DR getestet werden?
Ein vollständiger Failover mindestens jährlich, Komponenten-Wiederherstellungen vierteljährlich und nach jeder wesentlichen Infrastrukturänderung. Ein ungetesteter DR-Plan ist ein Dokument, keine Fähigkeit — und das Incident-Log zeigt, dass Ausfälle in genau den Mechanismen gehäuft auftreten (Stromübergänge, Kühlungsneustarts), die nur echte Tests prüfen.
DR-Markt auswählen?
Nennen Sie uns Ihren primären Standort, die benötigte RPO und das Compliance-Regime. Wir antworten mit Einrichtungen in praktikablen DR-Märkten, Benchmark-Preisen und den Fragen, die Sie jedem Betreiber stellen sollten.