Security & Compliance

Disaster Recovery (Notfallwiederherstellung)

Overview

Disaster Recovery (DR) ist der IT-Teil des Business Continuity Managements. Es geht um die Wiederherstellung nach einem Ausfall, nicht um dessen Vermeidung. Microsoft grenzt das sauber ab: Hochverfügbarkeit fängt alltägliche Störungen wie Hardwaredefekte oder Neustarts ab, Disaster Recovery plant für seltene, katastrophale Ereignisse wie Naturkatastrophen, schwere Bedienfehler oder große Sicherheitsvorfälle.

Typische Auslöser im Mittelstand sind Ransomware, Storage-Defekte, Brand oder Wasser im Serverraum und Fehlkonfigurationen. Backup und DR hängen zusammen, sind aber nicht dasselbe: Das Backup liefert die Daten, der DR-Plan beschreibt, wie daraus in welcher Reihenfolge wieder ein laufender Betrieb wird.

NIS2 und das BSIG verlangen Notfallwiederherstellung und Krisenmanagement als Teil des Risikomanagements, ISO/IEC 27001:2022 fordert IKT-Bereitschaft für Business Continuity (Anhang A 5.30).

How it works

Ein DR-Konzept wird pro System anhand von RPO (maximal tolerierbarer Datenverlust) und RTO (maximal tolerierbare Ausfallzeit) entworfen:

  1. Strategie wählen: Wiederherstellung aus dem Backup, Warm Standby mit regelmäßiger Replikation oder Hot Standby mit nahezu sofortigem Failover.
  2. Wiederanlaufreihenfolge festlegen, etwa Netzwerk, Active Directory und DNS, dann Datenbanken, dann Anwendungen.
  3. Rollen, Kontaktlisten, Kommunikationswege und Entscheidungsbefugnisse für das Ausrufen des Notfalls definieren.
  4. Den Rückweg (Failback) an den Hauptstandort beschreiben.
  5. Den Plan regelmäßig testen und die gemessenen Zeiten mit RTO und RPO vergleichen.

Technisch eingesetzt werden unter anderem Azure Site Recovery (Replikation von Hyper-V, VMware, physischen Servern und Azure-VMs), Hyper-V Replica in Windows Server sowie Replikationsfunktionen von Backup-Herstellern.

Benefits

  • Kalkulierbare Ausfallzeit, weil Reihenfolge und Zuständigkeiten vorab geklärt sind
  • Überleben eines Standortverlusts, wenn Systeme an einen zweiten Ort repliziert werden
  • Nachweise für NIS2, ISO 27001, TISAX und Cyberversicherer
  • Ruhigere Entscheidungen im Ernstfall durch erprobte, schriftliche Abläufe

Practical example

Ein Handelsunternehmen mit 120 Mitarbeitenden betreibt alle Hyper-V-Hosts an einem Standort. Für ERP und Dateiserver richtet es Hyper-V Replica an eine Zweigstelle ein und schreibt einen Plan mit Startreihenfolge und Kontaktlisten. Beim jährlichen DR-Test zeigt sich, dass die ERP-Anwendung ohne erreichbaren Domänencontroller und DNS nicht startet. Die IT ergänzt einen replizierten DC und korrigiert die Reihenfolge im Plan.

Things to keep in mind

  • Active Directory und DNS in der Startreihenfolge zuerst berücksichtigen, sonst starten abhängige Dienste nicht sauber
  • DR-Handbuch und Notfallzugangsdaten offline und außerhalb der betroffenen Umgebung ablegen
  • Lizenzen für Windows Server, SQL Server und Fachanwendungen in der DR-Umgebung klären
  • Den Failback von Beginn an einplanen, denn er ist oft aufwendiger als das Failover
  • Mindestens jährlich testen und Abweichungen von RTO und RPO dokumentieren

Conclusion

Disaster Recovery ist nur so gut wie der letzte Test. Entscheide anhand von RPO und RTO, wo sich Replikation lohnt und wo ein Restore aus dem Backup genügt.

Further reading

Related articles