---
title: "Disaster Recovery und Business Continuity"
description: "RTO und RPO für Cloud-Workloads definieren, DR-Szenarien klassifizieren und eine getestete Business-Continuity-Strategie auf STACKIT etablieren — für regulierte Branchen und KRITIS-nahe Umgebungen."
sidebar:
order: 10
label: "Disaster Recovery"
source_url: "https://framework.stackit.cloud/de/adoption/adapting-operating-models/disaster-recovery/"
source_file: "docs/de/adoption/adapting-operating-models/disaster-recovery.mdx"
---
## Worum es geht
Disaster Recovery ist die Disziplin, die niemand praktiziert — bis sie muss. Dann kostet jede Entscheidung, die früher hätte getroffen werden können, Geld und Vertrauen.
Für die meisten Organisationen ist die Cloud-Migration der Moment, in dem DR-Anforderungen zum ersten Mal schriftlich definiert werden. Das ist die Chance: klar, verhältnismäßig und getestet.
## RTO und RPO — die beiden grundlegenden Fragen
Jedes System hat eine implizite Wiederherstellungszeit und einen akzeptablen Schwellenwert für Datenverlust. Die meisten Organisationen kennen diese Zahlen nicht — und zahlen den Preis dafür, wenn ein Vorfall eintritt.
**Recovery Time Objective (RTO):** Wie lange darf ein System nach einem Ausfall nicht verfügbar sein? Eine RTO von 4 Stunden bedeutet: Nach spätestens 4 Stunden muss das System wieder funktionsfähig sein.
**Recovery Point Objective (RPO):** Wie viel Datenverlust ist akzeptabel? Ein RPO von 1 Stunde bedeutet: Maximal dürfen die letzten 60 Minuten Daten verloren gehen.
**Die wichtige Regel:** Je aggressiver RTO und RPO, desto höher die laufenden Kosten. Eine RTO von 15 Minuten bei einem RPO von 5 Minuten erfordert Hot-Standby-Umgebungen. Eine RTO von 24 Stunden bei einem RPO von 12 Stunden kann durch tägliche Sicherungen und manuelle Prozesse eingehalten werden.
Die richtige Antwort ist: verhältnismäßig, nicht maximalistisch.
## Vier Tier-Klassen für Cloud-Workloads
### Tier 1 — Mission Critical (RTO < 1 h, RPO < 15 min)
Systeme, deren Ausfall unmittelbar zu Umsatzeinbußen, regulatorischen Konsequenzen oder Sicherheitsrisiken führt. Beispiele: Zahlungsverkehrssysteme, Kernbankensysteme, industrielle Produktionssteuerung.
### Tier 2 — Business Critical (RTO < 4 h, RPO < 1 h)
Systeme, die innerhalb weniger Stunden wiederhergestellt werden müssen, deren Ausfall aber kurzfristig tolerierbar ist. Beispiele: ERP-Systeme, CRM, interne Portale.
### Tier 3 — Business Important (RTO < 24 h, RPO < 4 h)
Systeme, die innerhalb eines Arbeitstages wiederhergestellt werden können. Beispiele: Berichtssysteme, Sekundärdatenbanken, produktionsnahe Testsysteme.
### Tier 4 — Standard (RTO < 72 h, RPO < 24 h)
Systeme ohne unmittelbare Business-Kritikalität. Beispiele: Entwicklungsumgebungen, Archivsysteme, sekundäre Analytics-Tools.
## DR und Compliance — Erwartungen der Aufsichtsbehörden
Für regulierte Branchen ist DR keine freiwillige Best Practice, sondern eine regulatorische Anforderung.
**BAIT (Banken):** Erfordert dokumentierte Notfallpläne, regelmäßige Tests und Ausfallszenarien für alle wesentlichen IT-Systeme. Wiederherstellungsziele müssen von der Geschäftsleitung freigegeben werden.
**KRITIS (kritische Infrastruktur):** Verpflichtet KRITIS-Betreiber zum Business Continuity Management nach BSI IT-Grundschutz bzw. ISO 22301. DR-Tests sind verpflichtend; Ergebnisse sind zu dokumentieren.
**DSGVO:** Art. 32 erfordert die Fähigkeit, die Verfügbarkeit von personenbezogenen Daten nach einem Vorfall wiederherzustellen. Ein RPO von mehr als 24 Stunden für DSGVO-relevante Systeme ist nur schwer zu begründen.
**DORA (Digital Operational Resilience Act, ab Januar 2025):** Verpflichtet Finanzinstitute zu einem umfassenden IKT-Risikomanagement mit expliziten BCM-Anforderungen und verpflichtenden Resilienz-Tests.
**STACKIT als Partner:** STACKIT betreibt in Deutschland Rechenzentren mit ISO-27001- und SOC-2-Zertifizierung. Die Datenresidenz in de-01/de-02 stellt sicher, dass Backup-Daten Deutschland nicht verlassen — ein entscheidender Vorteil für regulierte Industrien.
## DR-Tests — warum sie selten stattfinden und wie man das ändert
Der häufigste DR-Fehler ist, den Plan nie zu testen. DR-Tests werden regelmäßig verschoben, weil die Produktionsumgebung als zu kritisch gilt, um ein simuliertes Failover zu riskieren, weil keine klare Verantwortlichkeit für DR-Tests besteht und weil Tests als Aufwand ohne direkten Nutzen angesehen werden.
**Die Lösung:** DR-Tests als regelmäßiges Engineering-Ritual verankern, nicht als Ausnahmeereignis.
Vier Testformate in aufsteigender Intensität:
**1. Tabletop-Übung (jährlich, geringer Aufwand):** Das Team bearbeitet gemeinsam ein Ausfallszenario — am Whiteboard. Keine Systeme werden berührt. Identifiziert Lücken in Prozessen und Verantwortlichkeiten.
**2. Komponententest (quartalsweise):** Ein bestimmter Backup- oder Failover-Mechanismus wird in der Staging-Umgebung getestet. Dauer: einige Stunden.
**3. Teil-Failover-Test (halbjährlich):** Ein nicht produktionskritisches System wird tatsächlich auf den Standby-Standort geschaltet. Misst die tatsächliche RTO. Dauer: ein halber Tag.
**4. Vollständige DR-Übung (jährlich):** Vollständige Simulation eines Rechenzentrumsausfalls für alle Tier-1- und Tier-2-Systeme. Erfordert Planung und Abstimmung mit Stakeholdern. Liefert die echten Nachweise für die Aufsichtsbehörden.
## Verantwortlichkeiten im DR-Betrieb
Verabschiedet RTO/RPO-Ziele, fungiert im Notfall als Eskalationsinstanz, gibt DR-Tests frei und
berichtet Ergebnisse an Vorstand und Aufsichtsbehörden.
Implementiert und wartet die DR-Infrastruktur, führt Komponententests durch, dokumentiert
Wiederherstellungsverfahren.
Klassifizieren ihre Systeme in Tier-Klassen, definieren applikationsspezifische
Wiederherstellungsschritte, nehmen an Tabletop-Übungen teil.
Gewährleistet die Verfügbarkeit der Cloud-Infrastruktur gemäß SLA, stellt
Zone-zu-Zone-Replikation bereit, liefert Audit-Logs für behördliche Nachweise.
## Umsetzungsschritte
1. **Inventur und Klassifizierung aller Systeme** — Tier-Zuordnung für jeden Workload, dokumentiert und durch die Sparte bestätigt.
2. **RTO-/RPO-Ziele durch Vorstand oder CIO genehmigen lassen** — Keine IT-Entscheidung, sondern eine Business-Entscheidung mit Auswirkungen auf die Kosten.
3. **DR-Architektur pro Tier umsetzen** — Vom einfachen Backup im Object Storage bis zum Hot Standby in der zweiten STACKIT-Zone.
4. **Wiederherstellungsverfahren dokumentieren** — Als Runbook, nicht als Konzept. Konkrete Schritte, die im Notfall ohne weitere Rückfragen ausgeführt werden können.
5. **Die erste Tabletop-Übung durchführen** — Innerhalb von 30 Tagen nach Produktivsetzung. Ergebnis: eine Liste der offenen Punkte mit Eigentümer und Termin.
6. **Einen DR-Testkalender etablieren und pflegen** — Quartalsweise Komponententests, halbjährlich partielles Failover, jährlich vollständige Übung.