Bestimmen Sie die kritischen Prozesse sowie die Ziele für Wiederherstellungszeit und Wiederherstellungspunkt, erfassen Sie alle Abhängigkeiten, erstellen Sie unabhängige Backups und ein präzises Runbook. Üben Sie die Wiederherstellung regelmäßig in einer isolierten Umgebung, prüfen Sie die Datenintegrität und die Zugänge und kommunizieren Sie nach einem Vorfall kontrolliert, schalten Sie geordnet um und werten Sie die Erkenntnisse aus.
Disaster Recovery betrifft Situationen, in denen ein normaler Neustart oder das Ausrollen einer Korrektur nicht ausreicht. Dabei kann es um beschädigte Daten, eine nicht verfügbare Region, eine fehlerhafte Konfiguration, den Verlust eines Kontos oder einen umfangreicheren Sicherheitsvorfall gehen. Das bloße Vorhandensein einer Datensicherung bedeutet nicht, dass sich die Anwendung in der Reihenfolge, Zeit und Qualität wiederherstellen lässt, die das Unternehmen benötigt.
Ein Disaster-Recovery-Plan verbindet geschäftliche Prioritäten mit der technischen Realität. Er legt fest, welche Fähigkeiten zuerst wiederhergestellt werden, welcher Verlust aktueller Daten akzeptabel ist, wer entscheidet und wie die korrekte Funktion des Dienstes überprüft wird. Er muss Identitäten, Secrets, externe Integrationen, Domains, Kommunikationskanäle und Menschen umfassen, nicht nur die Datenbank und den Anwendungscode.
Übersetzen Sie die Auswirkungen eines Ausfalls in Wiederherstellungsziele
Ermitteln Sie zuerst, welche Tätigkeiten für Nutzer und intern zeitkritisch sind. Anmeldung, Auftragsannahme und ein historischer Report müssen nicht dieselbe Priorität haben. Das Recovery Time Objective beschreibt die Zielzeit bis zur Wiederherstellung der Funktionsfähigkeit, das Recovery Point Objective den akzeptablen Zeitpunkt, auf den die Daten wiederhergestellt werden. Die Werte ergeben sich aus den Auswirkungen und Möglichkeiten, nicht aus einer universellen Vorlage.
Unterscheiden Sie einen minimalen Notbetrieb von der vollständigen Wiederherstellung. Ein Unternehmen muss möglicherweise zuerst neue Anfragen sicher entgegennehmen und erst später weniger wichtige Berichte bereitstellen. Ordnen Sie jedem Ziel einen Verantwortlichen und eine Prüfmethode zu. Wenn eine Anforderung nicht zur Architektur oder zum Budget passt, lösen Sie den Konflikt vor einem Vorfall und dokumentieren Sie das Restrisiko offen.
Erfassen Sie Komponenten und versteckte Abhängigkeiten
Die Bestandsaufnahme umfasst Anwendung, Datenbank, Dateien, Warteschlangen, Suchindex, Konfiguration, DNS, Zertifikate, Identitäten, Geheimnisse und Monitoring. Geben Sie für jeden Punkt an, wie er erstellt, gesichert und wiederhergestellt wird und welche Berechtigung dafür nötig ist. Ein externer Anbieter mag verfügbar sein, doch Ihr Konto, Ihr Webhook oder eine freigegebene Adresse funktionieren nach der Wiederherstellung möglicherweise nicht.
Legen Sie die Reihenfolge fest. Eine vor der Datenbank gestartete Anwendung kann fehlerhafte Aufgaben erzeugen, eine Integration vor der Wiederherstellung der Secrets wiederum die Warteschlange überlasten. Als Code definierte Infrastruktur hilft bei der Wiederherstellung der Umgebung, benötigt aber ein geschütztes Repository und einen Zugang außerhalb des kompromittierten Kontos. Kritische Kontakte und Dokumentation dürfen nicht nur über das System verfügbar sein, das Sie gerade wiederherstellen.
- Daten, Dateien und zustandsbehaftete Dienste
- Konten, Berechtigungen, Zertifikate und Secrets
- Domains, Netzwerk und externe Integrationen
- Monitoring, Dokumentation und Kommunikationskontakte
Planen Sie Backups als Teil der Wiederherstellung
Eine Datensicherung braucht einen festgelegten Umfang, eine Frequenz, Verschlüsselung, eine Aufbewahrungsdauer und eine Trennung von der primären Umgebung. Schützen Sie sie vor demselben Fehler oder derselben Kompromittierung, die die Produktion trifft. Prüfen Sie den Abschluss und die Lesbarkeit, nicht nur den Start des Jobs. Mehrere Wiederherstellungspunkte helfen, wenn eine Beschädigung erst nach einiger Zeit entdeckt wird.
Eine wiederhergestellte Datenbank muss zur Version der Anwendung und der Schemamigrationen passen. Dateien, Suchindex und Events in der Queue können von einem anderen Zeitpunkt stammen, daher regelt der Plan ihren Abgleich. Verwenden Sie sensible Backups nicht ohne angemessenen Schutz für gewöhnliche Tests. Die sichere Löschung am Ende ihrer Lebensdauer gehört zum selben Prozess.
Schreiben Sie ein Runbook und führen Sie einen Wiederherstellungstest durch
Ein Runbook enthält Auslösebedingungen, Entscheidungsrollen, genaue Schritte, erforderliche Zugänge, Prüfungen und Punkte, an denen der Ablauf gestoppt werden kann. Halten Sie Befehle und Links bei den jeweiligen Komponenten. Rechnen Sie damit, dass der Hauptadministrator nicht erreichbar sein könnte. Fügen Sie sensible Werte nicht direkt in das Dokument ein; beschreiben Sie stattdessen einen sicheren Weg, sie zu erhalten.
Der Test soll den Dienst in einer isolierten Umgebung aus einem realen Sicherungstyp wiederherstellen. Messen Sie den Ablauf für die interne Planung, prüfen Sie aber vor allem Anmeldung, Kernprozesse, Berechtigungen, Datenkonsistenz und Anbindungen. Ein fehlgeschlagener Test ist eine nützliche Erkenntnis, wenn er zur Korrektur des Verfahrens führt. Eine Planspiel-Diskussion ersetzt keine technische Wiederherstellung, überprüft aber Entscheidungsfindung und Kommunikation.
Steuern Sie Incident, Rollback und nachträgliche Überprüfung
Führen Sie während eines Vorfalls ein einziges verlässliches Protokoll der Entscheidungen, Verantwortlichen und des Status. Die Kommunikation mit den Nutzern soll sachlich sein und keine Zeitangaben versprechen, die das Team nicht belegen kann. Prüfen Sie vor der Wiederaufnahme des Betriebs Sicherheit, Integrität und die Bereitschaft des Supports. Ein wiederhergestellter Dienst kann vorübergehend mit Einschränkungen laufen, die sichtbar benannt und überwacht werden müssen.
Gleichen Sie nach der Stabilisierung die im Ersatzmodus entstandenen Ereignisse ab, stellen Sie Schutzmechanismen wieder her und prüfen Sie ungewöhnliche Zugriffe. Die anschließende Nachbetrachtung trennt Ursache, Auswirkungen und Schwächen der Wiederherstellung. Aktualisieren Sie Runbook, Architektur, Kontakte und Schulungen. Ein Plan ist nur so lange gültig, wie er dem heutigen Dienst entspricht und das Team ihn umsetzen kann.
Häufige Fragen
Ist Disaster Recovery dasselbe wie Hochverfügbarkeit?
Nein. Hochverfügbarkeit begrenzt die Auswirkungen gewöhnlicher Störungen, während Disaster Recovery die Wiederherstellung nach einem schwerwiegenden Ereignis behandelt. Beide können sich ergänzen, haben aber unterschiedliche Szenarien, Entscheidungen und Tests.
Reicht es, regelmäßig zu prüfen, ob ein Backup erstellt wurde?
Nein. Die Lesbarkeit muss geprüft und eine Wiederherstellung einschließlich Anwendung, Zugängen und Abhängigkeiten durchgeführt werden. Eine erfolgreich erstellte Backup-Datei bestätigt weder konsistente Daten noch einen funktionierenden Nutzerprozess.
Wie oft sollte die Wiederherstellung einer Webanwendung getestet werden?
Das Intervall ergibt sich aus dem Risiko, der Änderungshäufigkeit und den angestrebten Zielen. Wiederholen Sie den Test auch nach einer wesentlichen Änderung der Architektur, des Anbieters, des Datenmodells oder des verantwortlichen Teams.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
