Betrieb resilient vorbereiten
Backup und Wiederanlauf unterscheiden
Ein Backup ist eine Datenkopie; ein Wiederanlauf umfasst zusätzlich Systeme, Konfigurationen, Zugänge, Abhängigkeiten, Reihenfolge und die geprüfte Rückkehr zu einer nutzbaren Leistung.
Veröffentlicht und redaktionell geprüft: 20. September 2026 · Autor: Augustin Fouché
Drei unterschiedliche Ergebnisse benennen
Backup bezeichnet zunächst die gesicherte Kopie bestimmter Daten. Wiederherstellung bedeutet, Daten oder Systeme in einen definierten Zustand zurückzubringen. Wiederanlauf meint, eine benötigte Ressource oder Leistung wieder betriebsfähig bereitzustellen. Der BSI-Standard 200-4 behandelt Datensicherung und Wiederanlauf im größeren Zusammenhang des Business Continuity Management. Artikel 21 der NIS-2-Richtlinie nennt für die von ihr erfassten Einrichtungen die Aufrechterhaltung des Betriebs, Backup-Management und Wiederherstellung nach einem Notfall. Eine erfolgreiche Sicherungsmeldung beweist daher noch nicht, dass eine Fachanwendung rechtzeitig und korrekt genutzt werden kann. Dokumentieren Sie für jeden Umfang, welches Ergebnis tatsächlich geprüft wurde.
Beleggrundlage: BSI-Standard 200-4: Business Continuity Management, Version 1.0 (Mai 2023) · Richtlinie (EU) 2022/2555 (NIS 2)
Sicherungsumfang und Wiederherstellungsziel abgleichen
Listen Sie Datenbestände, Konfigurationen, Schlüssel, Verzeichnisse und Abhängigkeiten auf, die für eine konkrete Leistung gebraucht werden. Ordnen Sie jedem Element Sicherungsrhythmus, Aufbewahrungsort, verantwortliche Rolle und vorgesehenes Wiederherstellungsziel zu. Prüfen Sie, ob neu hinzugekommene Komponenten tatsächlich erfasst sind. Diese Inventur ist eine redaktionelle Kontrollmethode; Auswahl, Verschlüsselung und technische Architektur gehören in die Hände zuständiger Fachpersonen. Speichern Sie keine Zugangsdaten in der öffentlichen Liste. Offene Lücken werden mit Eigentümer und Termin geführt, nicht durch die allgemeine Aussage vollständig gesichert verdeckt.
Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.
RTO und tolerierten Datenverlust getrennt betrachten
Die Recovery Time Objective (RTO) beschreibt nach dem BSI-Standard 200-4 ein zeitliches Wiederanlaufziel; sie beantwortet nicht automatisch, welcher Datenverlust fachlich toleriert werden kann. Ein System kann schnell starten und dennoch relevante Änderungen verlieren, während eine vollständige Kopie umgekehrt zu langsam einspielbar sein kann. Definieren Sie daher den benötigten Datenstand separat und belegen Sie diese Annahme fachlich. Diese Seite setzt keine angemessenen Werte fest. Ziele müssen aus Business-Impact-Analyse, Abhängigkeiten und verfügbaren Verfahren abgeleitet und durch passend geplante Tests oder Übungen überprüft werden.
Beleggrundlage: BSI-Standard 200-4: Business Continuity Management, Version 1.0 (Mai 2023)
Eine Wiederherstellung isoliert prüfen
Wählen Sie einen repräsentativen, freigegebenen Datenbestand und eine sichere Testumgebung. Protokollieren Sie Startzeit, verwendete Sicherung, Schritte, Fehlermeldungen, erreichten Datenstand und Validierung durch den Fachbereich. Ein Test darf Produktivdaten nicht unnötig vervielfältigen oder Schutzkontrollen umgehen. Wenn keine geeignete Umgebung vorhanden ist, planen zuständige Fachstellen eine risikoangemessene Alternative. Brechen Sie bei unerwarteten Auswirkungen ab und folgen Sie dem internen Eskalationsweg. Ein erfolgreicher Einzeltest gilt nur für den dokumentierten Umfang; er beweist nicht automatisch die Wiederherstellbarkeit aller Systeme.
Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.
Vom technischen Erfolg zur nutzbaren Leistung testen
Nach der Rücksicherung führt eine autorisierte Fachperson einen klar definierten Geschäftsvorgang aus. Dabei werden Schnittstellen, Berechtigungen, Zeitbezug und Ausgabe geprüft. Danach folgt die kontrollierte Rückkehr in den Ausgangszustand der Testumgebung. Das Protokoll nennt Abweichungen und verhindert, dass ein grüner technischer Status ungeprüft als betrieblicher Wiederanlauf ausgegeben wird. Überarbeiten Sie Plan, Reihenfolge oder Sicherungsumfang anhand der Befunde und testen Sie die geänderte Stelle erneut. Weder ein Backup noch eine Übung garantiert Schutz vor jedem Ausfall; beide liefern begrenzte Nachweise für einen bekannten Stand.
Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.
Fehlerbefunde bis zum Retest verfolgen
Jeder Befund erhält eine eindeutige Beschreibung, betroffene Sicherung, Auswirkung und verantwortliche Bearbeitungsrolle. Schließen Sie ihn nicht allein aufgrund einer Konfigurationsänderung. Wiederholen Sie den zuvor fehlgeschlagenen Schritt mit vergleichbaren Bedingungen und bewahren Sie das neue Ergebnis zusammen mit dem ursprünglichen Protokoll auf. Falls eine Korrektur das Ziel oder den Umfang verändert, wird dies als neue Annahme ausgewiesen. So bleibt erkennbar, ob die Wiederherstellbarkeit verbessert oder lediglich anders definiert wurde. Ein regelmäßiger Bericht nennt auch überfällige Retests und nicht mehr unterstützte Sicherungen. Abgelöste Medien oder Verfahren werden kontrolliert aus dem aktiven Plan entfernt, damit niemand im Notfall auf eine historisch erfolgreiche, heute aber unbrauchbare Kopie vertraut. Der nächste Prüftermin wird zusammen mit dem verantwortlichen Bereich im Befund festgehalten.
Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.
Quellen und Prüfstand
- BSI-Standard 200-4: Business Continuity Management, Version 1.0 (Mai 2023) — Bundesamt für Sicherheit in der Informationstechnik, geprüft am 20. September 2026.
- Richtlinie (EU) 2022/2555 (NIS 2) — Europäische Union, geprüft am 20. September 2026.
Die Inhalte beschreiben allgemeine Organisations- und Digitalisierungsprinzipien; sie ersetzen keine Sicherheits-, Rechts- oder Datenschutzprüfung im Unternehmen.
Im Zusammenhang weiterlesen
- Wiederanlauf praktisch testen — Ein Wiederanlauftest prüft nicht nur, ob Technik startet, sondern ob eine priorisierte Leistung mit den vorgesehenen Personen, Daten und Kontrollen nutzbar zurückkehrt.
- Geschäftskritische Abläufe erkennen — Kritikalität entsteht nicht aus Lautstärke oder Gewohnheit, sondern aus den Folgen einer Unterbrechung über die Zeit und den Abhängigkeiten, die eine Leistung erst ermöglichen.
- Datenquelle und Dateneigner festlegen — Eine belastbare Datenverantwortung verbindet die maßgebliche Quelle mit Definition, Qualitätsentscheidung und Eskalationsweg.