Disaster Recovery für Unternehmen: DR-Plan, RTO und RPO verständlich erklärt (Stand: Juli 2026)

Stand: Juli 2026. Ein Stromausfall im Rechenzentrum, ein verschlüsselter Virtualisierungshost oder eine fehlerhafte Software-Aktualisierung kann zentrale Geschäftsprozesse innerhalb weniger Minuten stoppen. Ein Backup ist dann unverzichtbar - aber es beantwortet noch nicht, welches System zuerst wieder anlaufen muss, wer die Entscheidung trifft und wie Anwendungen, Identitäten, Netzwerk und Daten in einer funktionierenden Reihenfolge zurückkehren. Genau diese Lücke schließt Disaster Recovery (DR).

Der folgende Leitfaden richtet sich an mittelständische Unternehmen, die einen realistischen Disaster-Recovery-Plan aufbauen oder einen vorhandenen Notfallplan prüfen möchten. Er erklärt RTO und RPO, zeigt die Unterschiede zwischen Hot, Warm und Cold Site und ordnet Cloud DR sowie Disaster Recovery as a Service (DRaaS) ein. Wenn Sie parallel Ihre Datensicherung prüfen möchten, finden Sie auf unserer Seite zu Managed Backup und Disaster Recovery die technische Grundlage.

Was ist Disaster Recovery?

Disaster Recovery umfasst die technischen und organisatorischen Maßnahmen, mit denen ein Unternehmen seine IT nach einem schwerwiegenden Ausfall kontrolliert wiederherstellt. Das Ziel ist nicht, jede Störung zu verhindern. Das Ziel ist, die Auswirkungen vorhersehbar zu begrenzen und kritische Prozesse innerhalb vereinbarter Zeitfenster wieder arbeitsfähig zu machen.

Ein DR-Konzept betrachtet deshalb mehr als Dateien und Datenbanken. Es berücksichtigt unter anderem Virtualisierung, Netzwerk, DNS, Verzeichnisdienste, Zugänge, Zertifikate, Fachanwendungen, Kommunikationssysteme, externe Dienstleister und die Personen, die im Notfall Entscheidungen treffen. Fällt beispielsweise Active Directory aus, nutzt ein vorhandenes ERP-Backup wenig, solange sich Mitarbeitende nicht anmelden können. Fällt die Firewall-Konfiguration, kann die wiederhergestellte Anwendung trotzdem nicht sicher veröffentlicht werden.

Disaster Recovery, Backup und Business Continuity

Die Bereiche greifen ineinander. Backup liefert die Daten, Disaster Recovery stellt Systeme wieder her, und Business Continuity hält die wichtigsten Geschäftsprozesse bis zum Normalbetrieb aufrecht. Wer nur einen dieser Bausteine plant, lässt kritische Abhängigkeiten offen.

RTO und RPO: die zwei wichtigsten DR-Ziele

RTO (Recovery Time Objective) ist die maximal akzeptable Zeit bis zum Wiederanlauf. RPO (Recovery Point Objective) ist der maximal tolerierbare Datenverlust, ausgedrückt als Zeitraum. Ein RTO von vier Stunden bedeutet: Der Prozess soll spätestens vier Stunden nach Ausfall wieder nutzbar sein. Ein RPO von einer Stunde bedeutet: Im schlechtesten zulässigen Fall fehlen die Änderungen der letzten Stunde.

RTO und RPO sollten pro Geschäftsprozess und Anwendung festgelegt werden. Ein öffentliches Bestellportal kann ein RTO von einer Stunde benötigen, während ein Archivsystem möglicherweise einen Werktag ausfallen darf. Die Finanzbuchhaltung verträgt vielleicht ein RPO von vier Stunden; eine laufende Produktionssteuerung deutlich weniger. Je kürzer die Ziele, desto höher sind in der Regel Aufwand und Kosten für Replikation, Ersatzkapazität und Automatisierung.

Business-Impact-Analyse statt Wunschwerte

Die Werte entstehen aus einer Business-Impact-Analyse (BIA). Dafür beantworten Fachbereich und IT gemeinsam vier Fragen:

1. Welche Prozesse erzeugen bei Ausfall sofort Umsatzverlust, Vertragsrisiken oder Sicherheitsprobleme?
2. Welche Anwendungen, Identitäten, Datenbanken und Schnittstellen benötigt jeder Prozess?
3. Wie hoch ist der wirtschaftliche Schaden nach einer, vier, acht und 24 Stunden?
4. Welche Datenänderungen lassen sich rekonstruieren - und welche nicht?

Das Ergebnis ist eine priorisierte Wiederanlaufreihenfolge. Diese Reihenfolge ist häufig wertvoller als eine lange Liste einzelner Server, weil sie technische Abhängigkeiten an den Geschäftszielen ausrichtet.

Hot Site, Warm Site oder Cold Site?

Die klassische DR-Planung unterscheidet drei Bereitschaftsstufen. Sie beschreiben, wie viel Ersatzinfrastruktur vor einem Ausfall vorbereitet wird.

Hot Site: kurzer Wiederanlauf, hoher Aufwand

Eine Hot Site hält Infrastruktur und Daten an einem zweiten Standort nahezu betriebsbereit. Systeme werden fortlaufend repliziert und können automatisiert oder nach kurzer Freigabe übernehmen. Das eignet sich für Prozesse mit sehr kurzem RTO, verursacht aber laufende Kosten für Rechenleistung, Lizenzen, Netzwerk und Tests. Wichtig: Replikation ersetzt kein unveränderbares Backup. Verschlüsselte oder versehentlich gelöschte Daten können sonst direkt zum zweiten Standort übertragen werden.

Warm Site: der häufige Mittelweg

Eine Warm Site stellt Kerninfrastruktur, Netzwerk und Grundkonfiguration bereit, während Anwendungen und aktuelle Daten im Notfall aus Replikation oder Backup aktiviert werden. Der Wiederanlauf dauert eher Stunden als Minuten. Für viele KMU ist das ein tragfähiger Kompromiss zwischen Kosten und Betriebsfähigkeit, sofern die Aktivierung dokumentiert und regelmäßig getestet wird.

Cold Site: günstig, aber mehr Aufbauzeit

Eine Cold Site bietet Standort, Konnektivität und gegebenenfalls Hardware, hält die produktive Umgebung jedoch nicht vollständig vor. Systeme müssen aus Infrastructure-as-Code, Installationsmedien und Backups neu aufgebaut werden. Das senkt laufende Kosten, verlängert aber das RTO. Eine Cold Site funktioniert nur dann zuverlässig, wenn Konfigurationen, Schlüssel, Installationsquellen und Abhängigkeiten vollständig dokumentiert und außerhalb der ausgefallenen Umgebung verfügbar sind.

Cloud Disaster Recovery und DRaaS

Cloud DR nutzt Cloud- oder Rechenzentrumsressourcen als Ersatzstandort. Virtuelle Maschinen, Datenbanken oder Anwendungen werden repliziert und erst im Notfall in der benötigten Größe gestartet. Lösungen wie Azure Site Recovery oder Veeam-basierte Replikation können Teil eines solchen Konzepts sein. Die Produktauswahl sollte aber erst nach RTO, RPO, Datenstandort und Abhängigkeitsanalyse erfolgen - nicht umgekehrt.

Disaster Recovery as a Service (DRaaS) ergänzt die Technik um einen gemanagten Prozess. Ein Dienstleister überwacht Replikation und Sicherungen, pflegt Runbooks, koordiniert Tests und unterstützt den Wiederanlauf mit definierten Reaktionszeiten. Für Unternehmen ohne eigenes Infrastrukturteam reduziert das die operative Last. Der Vertrag muss eindeutig regeln:

• welche Systeme und Daten vom Service erfasst sind,
• welche RTO- und RPO-Ziele gelten,
• wer einen Failover freigeben darf,
• wo Daten und Schlüssel gespeichert werden,
• wie regelmäßige Tests dokumentiert werden und
• wie ein Rückwechsel in die Primärumgebung abläuft.

Ein DRaaS-Angebot ohne getestetes Runbook ist lediglich Infrastruktur. Erst der abgestimmte Ablauf macht daraus einen belastbaren Wiederanlaufservice.

Disaster-Recovery-Plan in sieben Schritten

1. Geltungsbereich und Verantwortliche festlegen

Bestimmen Sie einen fachlichen Notfallverantwortlichen, einen technischen Koordinator und Stellvertretungen. Dokumentieren Sie, wer einen Notfall ausruft, wer externe Dienstleister aktiviert und wer den wiederhergestellten Betrieb freigibt.

2. Systeme und Abhängigkeiten erfassen

Erstellen Sie eine Übersicht über Anwendungen, Datenbanken, Identitäten, Netzwerke, Zertifikate, Schnittstellen und SaaS-Dienste. Markieren Sie technische Voraussetzungen. Ein Ticketsystem benötigt beispielsweise DNS, Identitätsdienst, Mailversand und häufig mehrere Datenbanken.

3. RTO, RPO und Reihenfolge definieren

Leiten Sie die Ziele aus der Business-Impact-Analyse ab. Gruppieren Sie Systeme in Wiederanlaufwellen: zuerst Basisdienste und Sicherheit, dann umsatzkritische Anwendungen, anschließend unterstützende Systeme.

4. Wiederherstellungswege dokumentieren

Schreiben Sie konkrete Runbooks. Gute Anweisungen enthalten Voraussetzungen, Zugänge, Befehle, Prüfschritte, erwartete Ergebnisse, Abbruchkriterien und den nächsten Verantwortlichen. Speichern Sie die Dokumentation so, dass sie auch bei Ausfall der eigenen Plattform erreichbar bleibt.

5. Kommunikation vorbereiten

Definieren Sie interne und externe Meldewege. Vorlagen für Mitarbeitende, Kunden, Lieferanten und gegebenenfalls Behörden verhindern widersprüchliche Informationen. Notfallkontakte dürfen nicht ausschließlich im ausgefallenen E-Mail-System liegen.

6. Wiederanlauf testen

Beginnen Sie mit Restore-Tests einzelner Datensätze und Anwendungen. Danach folgen technische Teiltests und schließlich ein vollständiger Wiederanlauf in einer isolierten Umgebung. Messen Sie die tatsächliche Dauer und prüfen Sie Datenintegrität, Anmeldung, Schnittstellen und Fachprozesse.

7. Erkenntnisse nachführen

Jeder Test und jeder reale Vorfall verändert den Plan. Aktualisieren Sie Ansprechpartner, Abhängigkeiten, Laufzeiten und Runbooks. Ein DR-Plan mit veralteten Zugangsdaten oder ausgeschiedenen Verantwortlichen vermittelt nur Scheinsicherheit.

Ransomware: Wiederherstellung ohne Rückkehr des Angreifers

Nach einem Ransomware-Vorfall reicht ein schneller Restore nicht. Vor der Wiederinbetriebnahme muss geklärt sein, wie der Angreifer eingedrungen ist, welche Konten betroffen sind und ob die Sicherung bereits kompromittiert wurde. Die Wiederherstellung erfolgt idealerweise in einer isolierten Umgebung. Zugangsdaten und Schlüssel werden erneuert, Systeme gepatcht und erst nach Sicherheitsprüfung verbunden.

Unveränderbare Sicherungen, getrennte Administrationskonten und eine dokumentierte Incident-Response-Struktur reduzieren das Risiko einer erneuten Verschlüsselung. Für Linux- und Virtualisierungsumgebungen sollte der DR-Plan außerdem die Härtung und reproduzierbare Bereitstellung der Basisplattform berücksichtigen; dazu passt unser Angebot für Linux-Server und Managed Infrastructure.

Compliance: DSGVO, NIS2 und ISO 27001

Disaster Recovery ist auch ein Nachweisthema. Datenschutz und Informationssicherheit verlangen angemessene technische und organisatorische Maßnahmen, deren Umfang vom konkreten Risiko abhängt. ISO 27001 adressiert unter anderem die ICT-Bereitschaft für Business Continuity. NIS2 kann je nach Branche und Einordnung zusätzliche Anforderungen an Risikomanagement, Kontinuität und Vorfallprozesse auslösen.

Ein prüfbares DR-Konzept dokumentiert deshalb Entscheidungen, Tests, Abweichungen und Verbesserungen. Es hält fest, welche Daten an welchem Standort verarbeitet werden, welche Dienstleister beteiligt sind und wie Zugriffe geschützt werden. Die konkrete rechtliche Bewertung sollte mit Datenschutz- und Compliance-Verantwortlichen erfolgen; Technik und Dokumentation müssen anschließend denselben Stand abbilden.

Wie oft sollte Disaster Recovery getestet werden?

Ein vollständiger Wiederanlauftest pro Jahr ist ein sinnvoller Mindesttakt. Kritische Teilkomponenten sollten häufiger geprüft werden. Zusätzlich ist ein Test nach größeren Änderungen notwendig - etwa nach einem Plattformwechsel, einer Netzwerkumstellung, neuen Identitätsdiensten oder einer wesentlichen Personaländerung.

Disaster Recovery für KMU: pragmatisch starten

Ein belastbarer Plan muss nicht mit einer teuren Hot Site beginnen. Der erste sinnvolle Schritt ist eine priorisierte Systemliste mit RTO, RPO, Verantwortlichen und geprüften Backups. Danach werden die kritischsten Abhängigkeiten in ein Runbook überführt und in einer isolierten Umgebung getestet. Erst die gemessenen Ergebnisse zeigen, wo Replikation, Cloud DR oder DRaaS wirtschaftlich notwendig sind.

Bytes Commerce verbindet Backup, Infrastruktur und IT-Sicherheit zu einem getesteten Wiederanlaufkonzept. Wir erfassen Ihre Abhängigkeiten, definieren realistische Ziele, erstellen Runbooks und begleiten Recovery-Tests mit klaren Ergebnissen. Ausgangspunkt ist ein strukturiertes Erstgespräch zu Geschäftsprozessen, vorhandener Infrastruktur und akzeptablen Ausfallzeiten.