Wie funktioniert Disaster Recovery im Betrieb?

Ein ausgefallenes ERP, ein nicht erreichbarer Shop oder eine fehlerhafte Datenbankmigration ist kein theoretisches IT-Risiko. Nach kurzer Zeit entstehen Umsatzverluste, Lieferverzögerungen, Supportaufwand und Vertrauensschäden. Wie funktioniert Disaster Recovery also in der Praxis? Nicht durch ein einzelnes Backup, sondern durch einen technisch und organisatorisch vorbereiteten Wiederanlauf geschäftskritischer Systeme.

Disaster Recovery, kurz DR, beschreibt alle Maßnahmen, mit denen ein Unternehmen Anwendungen, Daten und Infrastruktur nach einem gravierenden Ausfall wiederherstellt. Das kann ein Ransomware-Angriff sein, ein Bedienfehler, ein fehlerhaftes Deployment, ein Cloud-Region-Ausfall oder ein Defekt im Rechenzentrum. Entscheidend ist nicht nur, ob Daten irgendwo gesichert sind. Entscheidend ist, ob die benötigten Systeme innerhalb einer fachlich vertretbaren Zeit wieder produktiv arbeiten.

Was Disaster Recovery von Backups unterscheidet

Backups sind ein Baustein von Disaster Recovery, aber kein vollständiges Wiederanlaufkonzept. Ein Datenbank-Dump beantwortet beispielsweise nicht, in welcher Reihenfolge Services hochgefahren werden, wo Zugangsdaten liegen, wie Netzwerke konfiguriert werden oder wie die Anwendung nach der Wiederherstellung geprüft wird.

Ein Disaster-Recovery-Konzept verbindet daher Daten, Infrastruktur, Anwendungen, Abhängigkeiten und Betriebsprozesse. Es definiert, wer im Ernstfall entscheidet, wer technische Schritte ausführt und wann Fachbereiche bestätigen, dass ein System wieder nutzbar ist. Besonders bei modernen Plattformen mit APIs, Kubernetes-Clustern, verwalteten Cloud-Diensten und mehreren Datenquellen reicht es nicht, einzelne Komponenten isoliert zu betrachten.

Die zentrale Frage lautet: Welcher Ausfall ist für welches Geschäftsszenario akzeptabel? Ein internes Reporting-System darf möglicherweise erst am nächsten Arbeitstag wieder laufen. Bei einer Bestellplattform, einer Produktionsschnittstelle oder einem Kundenportal gelten häufig deutlich strengere Anforderungen.

Wie funktioniert Disaster Recovery? Die zwei entscheidenden Zielwerte

Damit Wiederherstellung planbar wird, arbeiten Unternehmen mit zwei Kennzahlen: Recovery Time Objective, kurz RTO, und Recovery Point Objective, kurz RPO.

Das RTO legt fest, wie lange ein Service maximal ausfallen darf. Bei einem RTO von vier Stunden muss die vollständige Wiederherstellung inklusive Funktionsprüfung innerhalb dieses Zeitfensters möglich sein. Das RPO beschreibt dagegen den maximal tolerierbaren Datenverlust. Ein RPO von 15 Minuten bedeutet, dass im schlechtesten Fall Änderungen der vergangenen Viertelstunde fehlen dürfen.

Diese Werte sind keine technischen Wunschgrößen. Sie müssen aus Geschäftsprozessen abgeleitet werden. Wer ein RTO von wenigen Minuten fordert, benötigt meist redundante Architektur, automatisierte Umschaltung und kontinuierliche Datenreplikation. Das kostet mehr als eine tägliche Sicherung mit manuellem Wiederanlauf. Umgekehrt ist ein überzogenes Schutzniveau wirtschaftlich wenig sinnvoll, wenn der betroffene Prozess auch mehrere Stunden pausieren kann.

Die Kunst besteht darin, Anforderungen zu priorisieren. Nicht jede Anwendung braucht denselben Schutz. Ein belastbares Konzept ordnet Systeme nach Geschäftskritikalität ein und investiert dort, wo ein Ausfall tatsächlich hohe Schäden verursacht.

Die Bausteine eines funktionierenden Wiederanlaufs

Ein wirksames DR-Konzept beginnt mit einer Abhängigkeitsanalyse. Eine Webanwendung kann erst sinnvoll starten, wenn Datenbank, Identitätsdienst, DNS, Secrets, Netzwerkregeln und externe Schnittstellen verfügbar sind. Werden diese Abhängigkeiten übersehen, sieht ein Service im Monitoring vielleicht gesund aus, bleibt für Anwender aber unbrauchbar.

Danach folgt die Wahl der passenden Wiederherstellungsstrategie. Für weniger kritische Systeme kann ein Backup in einer getrennten Umgebung genügen. Die Infrastruktur wird bei Bedarf neu bereitgestellt und die Daten werden zurückgespielt. Das ist kosteneffizient, erreicht jedoch meist kein sehr kurzes RTO.

Für kritische Plattformen kommen Replikation und vorbereitete Ausweichumgebungen infrage. Datenbanken replizieren Daten in eine zweite Zone oder Region, Anwendungen werden in mehreren Verfügbarkeitszonen betrieben und der Traffic wird bei einem Ausfall umgeleitet. Eine vollständig aktive zweite Umgebung reduziert Wiederanlaufzeiten weiter, erhöht aber Komplexität, Betriebsaufwand und laufende Cloud-Kosten.

Unabhängig von der Variante müssen vier Dinge verlässlich vorhanden sein:

• aktuelle und verschlüsselte Datensicherungen, die getrennt von der Primärumgebung gespeichert werden
• reproduzierbare Infrastrukturdefinitionen, etwa über Infrastructure as Code
• dokumentierte und möglichst automatisierte Runbooks für Wiederherstellung und Umschaltung
• klare Verantwortlichkeiten, Kommunikationswege und fachliche Abnahmekriterien

Gerade Infrastructure as Code verändert die Qualität der Wiederherstellung deutlich. Statt Server, Netzwerke, Berechtigungen und Cluster-Konfigurationen unter Zeitdruck manuell nachzubauen, wird eine versionierte, geprüfte Zielumgebung automatisiert bereitgestellt. Das senkt Fehlerrisiken und macht den Prozess nachvollziehbar.

Von der Störung zur Wiederherstellung: der Ablauf im Ernstfall

Disaster Recovery startet nicht erst mit dem ersten Restore-Befehl. Den Anfang macht die Erkennung. Monitoring und Observability müssen zeigen, ob ein Ausfall lokal begrenzt ist, ob Datenintegrität gefährdet ist oder ob eine größere Störung vorliegt. Ein vorschnelles Failover kann Schäden verstärken, etwa wenn fehlerhafte Daten in die Ausweichumgebung repliziert werden.

Nach der Bewertung aktiviert das verantwortliche Team den definierten Notfallprozess. Zunächst wird der Schaden eingegrenzt: kompromittierte Zugänge sperren, fehlerhafte Deployments stoppen, betroffene Systeme isolieren oder Schreibzugriffe unterbrechen. Erst dann erfolgt die Wiederherstellung nach dem vorgesehenen Verfahren.

Je nach Architektur werden Backups auf einen geprüften Zeitpunkt zurückgespielt, Datenbank-Replikate hochgestuft oder Workloads in einer zweiten Umgebung gestartet. DNS-Einträge, Load Balancer und Zugangskontrollen müssen dabei ebenso berücksichtigt werden wie Zertifikate, Secrets und Konfigurationswerte. Bei containerisierten Anwendungen gehört auch die Wiederherstellung der Persistent Volumes und der Deployment-Konfigurationen dazu.

Der technische Start ist jedoch nicht das Ende. Teams prüfen Integrität, zentrale Geschäftsprozesse, Schnittstellen, Berechtigungen und Performance. Kann ein Kunde bestellen? Werden Aufträge korrekt übertragen? Sind Zahlungsstatus und Lagerbestände konsistent? Erst diese fachliche Validierung macht aus einem hochgefahrenen System einen wiederhergestellten Service.

Tests entscheiden, ob der Plan belastbar ist

Ein nicht getesteter Disaster-Recovery-Plan ist eine Annahme, keine Absicherung. Backups können unvollständig sein, Zugriffsschlüssel fehlen, Automatisierungen durch Änderungen veraltet sein oder Wiederherstellungszeiten deutlich länger dauern als geplant. Das fällt selten im normalen Tagesbetrieb auf.

Regelmäßige Restore-Tests prüfen zunächst, ob Daten lesbar und vollständig wiederherstellbar sind. Noch wertvoller sind kontrollierte Failover-Übungen: Teams simulieren den Ausfall einer Datenbank, eines Clusters oder einer Cloud-Region und messen, ob RTO und RPO tatsächlich eingehalten werden. Dabei werden technische Lücken ebenso sichtbar wie unklare Entscheidungswege.

Die Testfrequenz hängt von Risiko, Änderungsdynamik und regulatorischen Anforderungen ab. Plattformen mit häufigen Releases oder vielen Infrastrukturänderungen sollten ihre Runbooks und Automatisierungen deutlich öfter prüfen als weitgehend statische Systeme. Nach jeder Übung gehören Erkenntnisse zurück in Architektur, Dokumentation und Betriebsabläufe.

Häufige Schwachstellen in mittelständischen IT-Landschaften

In der Praxis scheitert Disaster Recovery selten an fehlenden Werkzeugen. Häufig fehlen Prioritäten und ein durchgängiger Blick auf den Betrieb. Es existieren Backups, aber keine dokumentierten Wiederanlaufzeiten. Oder eine Anwendung ist redundant, während eine einzelne Datenbank, ein Identity Provider oder ein externes SaaS-System zum Ausfallpunkt wird.

Ein weiterer Fehler ist die Vermischung von Hochverfügbarkeit und Disaster Recovery. Hochverfügbarkeit fängt typische Einzelstörungen ab, etwa den Ausfall einer Instanz oder Verfügbarkeitszone. Disaster Recovery adressiert größere Schäden: korrumpierte Daten, verlorene Accounts, Sicherheitsvorfälle oder den Ausfall einer ganzen Region. Beides ist sinnvoll, aber beides löst unterschiedliche Probleme.

Auch Ransomware verändert die Anforderungen. Wenn Angreifer produktive Daten und erreichbare Backups verschlüsseln oder löschen können, hilft selbst eine schnelle Replikation nicht weiter. Benötigt werden getrennte Zugriffsrechte, unveränderbare Sicherungen, definierte Aufbewahrungsfristen und getestete Wiederherstellung in einer sauberen Umgebung.

Disaster Recovery als Teil des produktionsreifen Betriebs

Ein guter DR-Ansatz wird nicht einmalig für ein Audit geschrieben und dann abgelegt. Er ist Teil von Architekturentscheidungen, CI/CD-Prozessen, Sicherheitskonzepten und täglichem Betrieb. Jede neue Datenabhängigkeit, jede geänderte Berechtigung und jeder neue Cloud-Service kann den Wiederanlauf beeinflussen.

Für Unternehmen mit begrenzten internen Spezialressourcen ist eine klare operative Verantwortung besonders wertvoll. devRocks verbindet dabei Architektur, Automatisierung, Observability und Betrieb so, dass Wiederherstellbarkeit nicht nachträglich ergänzt werden muss, sondern von Beginn an mitgeplant wird.

Der sinnvollste nächste Schritt ist kein möglichst großes Notfallhandbuch. Beginnen Sie mit den zwei oder drei Prozessen, deren Ausfall Ihr Geschäft unmittelbar trifft, definieren Sie realistische RTO- und RPO-Werte und testen Sie die Wiederherstellung unter echten Bedingungen. Erst wenn ein Team den Ablauf nachweisbar beherrscht, wird aus Vorsorge belastbare Handlungsfähigkeit.