Ein ausgefallener Shop am Montagmorgen, ein verschlüsselter Fileserver oder ein nicht erreichbares Telefoniesystem: Für ein mittelständisches Unternehmen wird ein IT-Vorfall schnell zum Geschäftsrisiko. Eine durchdachte Disaster Recovery Planung legt deshalb vor dem Ernstfall fest, wie Systeme, Daten und Arbeitsabläufe wieder verfügbar werden. Sie schafft keine absolute Sicherheit, aber sie ersetzt Improvisation durch klare Entscheidungen, Zuständigkeiten und technisch belastbare Prozesse.

Warum Backups allein keine Wiederanlaufstrategie sind

Ein Backup beantwortet eine wichtige Frage: Sind die Daten noch vorhanden? Disaster Recovery geht weiter und beantwortet auch: Welche Systeme müssen in welcher Reihenfolge wieder laufen? Wo stehen die Ersatzressourcen bereit? Wer trifft im Störungsfall Entscheidungen, und wie kommuniziert das Unternehmen mit Mitarbeitenden, Kunden und Dienstleistern?

Gerade in gewachsenen IT-Landschaften hängen Anwendungen voneinander ab. Der Webshop benötigt beispielsweise Datenbank, Zahlungsanbindung, DNS, E-Mail-Benachrichtigungen und Netzwerkzugang. Wird nur ein einzelner Server wiederhergestellt, heißt das noch nicht, dass der Geschäftsprozess funktioniert. Gute Planung betrachtet daher die gesamte Leistungskette statt nur einzelne Geräte oder virtuelle Maschinen.

Auch die Ursache eines Ausfalls entscheidet über das Vorgehen. Ein Hardwaredefekt, ein fehlerhaftes Update, ein Stromausfall, ein Cyberangriff oder ein menschlicher Fehler verlangen unterschiedliche Maßnahmen. Wer diese Szenarien vorab bewertet, kann die richtigen technischen und organisatorischen Vorkehrungen treffen.

Mit der Disaster Recovery Planung die Prioritäten klären

Am Anfang steht nicht die Auswahl einer Backup-Software, sondern eine ehrliche Bestandsaufnahme. Welche IT-Services sichern Umsatz, Lieferfähigkeit, Kommunikation oder gesetzliche Pflichten? Welche Anwendungen dürfen mehrere Stunden ausfallen, und bei welchen würden bereits wenige Minuten spürbare Schäden verursachen?

Dafür bietet sich eine Business-Impact-Analyse an. Sie ordnet Systeme nach ihrer geschäftlichen Bedeutung und macht Abhängigkeiten sichtbar. Neben Servern und Anwendungen gehören dazu Datenbanken, Netzwerkkomponenten, Identitätsdienste, Domains, Zertifikate, Schnittstellen, Cloud-Dienste und Telefonie. Häufig wird erst in dieser Phase deutlich, dass wichtige Zugänge bei einzelnen Personen liegen oder Dokumentationen fehlen.

Zwei Kennzahlen geben der Planung eine klare Richtung:

• Recovery Time Objective (RTO): Wie lange darf ein Service höchstens ausfallen, bevor der Schaden nicht mehr akzeptabel ist?
• Recovery Point Objective (RPO): Wie viel Datenverlust ist im äußersten Fall vertretbar?

Ein Webshop mit laufenden Bestellungen benötigt oft ein deutlich niedrigeres RPO als ein internes Archivsystem. Eine zentrale Warenwirtschaft kann ein kürzeres RTO verlangen als ein Testsystem. Diese Unterschiede sind sinnvoll, denn eine identische Hochverfügbarkeitsarchitektur für jede Anwendung wäre meist unnötig teuer. Entscheidend ist, dass die Anforderungen fachlich begründet, schriftlich festgehalten und regelmäßig überprüft werden.

Realistische Szenarien definieren

Planen Sie nicht nur für den vollständigen Ausfall eines Rechenzentrums. Wahrscheinlicher sind einzelne Störungen: eine versehentlich gelöschte Datenbank, defekte Storage-Komponenten, ein kompromittiertes Administratorkonto oder eine fehlerhafte Konfiguration nach einem Release. Ergänzend sollten Sie ein schweres Szenario abbilden, etwa den Verlust eines Standorts oder einen Ransomware-Angriff.

Für jedes Szenario braucht es eine kurze, verständliche Handlungsanweisung. Sie sollte Auslöser, Sofortmaßnahmen, Eskalationswege, Wiederherstellungsreihenfolge und Abnahmekriterien enthalten. Ein Plan, der nur aus einem allgemeinen Satz wie „Backup einspielen“ besteht, hilft nachts unter Zeitdruck nicht weiter.

Die technische Grundlage: getrennt, dokumentiert, überprüfbar

Eine wirksame Wiederanlaufstrategie verbindet mehrere Ebenen. Erstens müssen Daten gesichert werden. Zweitens müssen diese Sicherungen gegen Manipulation und unbefugten Zugriff geschützt sein. Drittens muss ausreichend Infrastruktur vorhanden sein, um kritische Dienste innerhalb der vereinbarten Zeit wieder zu starten.

Bewährt ist das 3-2-1-Prinzip: mindestens drei Kopien der Daten, auf zwei unterschiedlichen Speichermedien, davon eine Kopie außerhalb des primären Standorts. Für kritische Daten sollte zusätzlich geprüft werden, ob eine unveränderbare Sicherung sinnvoll ist. Sie kann bei Ransomware helfen, wenn Angreifer versuchen, auch Backup-Bestände zu löschen oder zu verschlüsseln.

Der zweite Standort muss nicht immer dieselbe Architektur wie die Produktionsumgebung vorhalten. Je nach RTO kann eine kalte Reserve genügen, bei der Serverkapazitäten erst im Ereignisfall bereitgestellt werden. Für zeitkritische Systeme kommen vorgehaltene virtuelle Ressourcen, Replikation oder eine aktiv betriebene Ausweichumgebung infrage. Je schneller der Wiederanlauf sein soll, desto höher sind in der Regel Kosten, Betriebsaufwand und Komplexität.

Für deutsche KMU sind zudem Standort, Datenschutz und Vertragsklarheit relevant. Datenhaltung in deutschen Rechenzentren, nachvollziehbare Zugriffsrechte und klar geregelte Verantwortlichkeiten erleichtern die sichere Betriebsführung. GS Webservices unterstützt Unternehmen dabei mit betreuter Server-, Cloud- und Colocation-Infrastruktur, die sich an individuellen Verfügbarkeits- und Sicherheitsanforderungen ausrichten lässt.

Nicht nur Daten, sondern Betriebswissen sichern

Viele Wiederherstellungen scheitern nicht an fehlenden Sicherungen, sondern an fehlendem Wissen. Zugangsdaten, Netzpläne, IP-Adressbereiche, Firewall-Regeln, Lizenzinformationen, Wiederherstellungsschlüssel und Ansprechpartner müssen geschützt, aktuell und für berechtigte Personen erreichbar sein. Besonders kritisch ist es, wenn nur ein Administrator weiß, wie ein zentrales System gestartet oder eine Domain umgestellt wird.

Dokumentation muss dabei handlungsfähig sein. Ein ausführliches Infrastrukturhandbuch ist wertvoll, ersetzt aber keine konkrete Runbook-Anleitung für den Ernstfall. Die verantwortliche Person sollte innerhalb weniger Minuten erkennen können, welche Schritte zuerst erfolgen, wo aktuelle Sicherungen liegen und wann externe Unterstützung einzubeziehen ist.

Rollen und Kommunikation entscheiden über wertvolle Minuten

Ein technischer Plan ohne klare Verantwortlichkeiten bleibt unvollständig. Benennen Sie einen Incident Lead, technische Verantwortliche für einzelne Plattformen und eine Person für die interne und externe Kommunikation. Für kleine Teams können mehrere Rollen bei einer Person liegen. Wichtig ist lediglich, dass Stellvertretungen festgelegt sind und Kontaktdaten nicht ausschließlich im ausgefallenen System gespeichert werden.

Die Kommunikation sollte vorbereitet, aber nicht automatisiert und unpersönlich sein. Mitarbeitende brauchen klare Informationen dazu, welche Systeme verfügbar sind und welche Übergangslösungen gelten. Kunden erwarten bei betroffenen Leistungen eine verlässliche Statusmeldung mit nachvollziehbarem nächsten Update-Zeitpunkt. Spekulationen über Ursachen oder Zeiträume, die technisch noch nicht abgesichert sind, sollten vermieden werden.

Auch Dienstleister und Provider gehören in den Eskalationsplan. Halten Sie Vertrags- und Supportdaten, vereinbarte Reaktionszeiten sowie notwendige Freigabewege bereit. Wer im Notfall erst prüfen muss, wer Änderungen an DNS, Firewalls oder Servern beauftragen darf, verliert unnötig Zeit.

Testen macht aus Planung eine funktionierende Fähigkeit

Eine Sicherung ist erst dann vertrauenswürdig, wenn ihre Wiederherstellung getestet wurde. Gleiches gilt für den gesamten Disaster-Recovery-Plan. Regelmäßige Tests zeigen, ob RTO und RPO tatsächlich erreichbar sind, ob Abhängigkeiten übersehen wurden und ob die Dokumentation unter realistischen Bedingungen verständlich bleibt.

Nicht jeder Test muss einen vollständigen Failover umfassen. Ein sinnvoller Rhythmus kombiniert verschiedene Formate: technische Restore-Tests einzelner Datenbestände, Planspiele für Kommunikations- und Eskalationswege sowie kontrollierte Wiederanläufe kritischer Systeme. Mindestens einmal jährlich sollte ein umfassender Test für die wichtigsten Geschäftsprozesse erfolgen. Bei größeren Änderungen an Infrastruktur, Anwendungen oder Verantwortlichkeiten ist ein zusätzlicher Test sinnvoll.

Dokumentieren Sie Ergebnisse ehrlich. Wurde das Ziel verfehlt, ist das kein Zeichen einer schlechten Planung, sondern ein wertvoller Befund. Daraus folgen konkrete Verbesserungen: kürzere Sicherungsintervalle, angepasste Kapazitäten, präzisere Runbooks oder zusätzliche Schulungen. Ein Plan bleibt nur dann verlässlich, wenn er mit der IT-Landschaft mitwächst.

Die ersten Schritte für Unternehmen mit Nachholbedarf

Wenn bislang kein belastbarer Plan existiert, sollte das Projekt nicht mit einem maximal komplexen Zielbild starten. Beginnen Sie mit den drei bis fünf geschäftskritischsten Services. Prüfen Sie für diese Systeme die letzte erfolgreiche Sicherung, die Wiederherstellbarkeit, die Abhängigkeiten und die Ansprechpartner. Legen Sie anschließend RTO und RPO fest und führen Sie einen dokumentierten Wiederherstellungstest durch.

Auf dieser Basis lässt sich die Planung schrittweise erweitern. Das schafft schnell Transparenz, reduziert akute Risiken und verhindert, dass ein umfangreiches Konzept ohne praktische Wirkung in der Ablage verschwindet. Der beste Zeitpunkt für einen Wiederherstellungstest ist nicht nach dem ersten echten Ausfall, sondern an einem planbaren Tag mit den richtigen Personen am Tisch.