FACHBEITRAG · 12. MAI 2026
IT-Sicherheit: Wiederherstellung praktisch testen statt nur Backups zählen
INSIGHT · 12. MAY 2026
IT security: Test recovery in practice instead of merely counting backups
Eine erfolgreiche Sicherungsmeldung beantwortet noch nicht die Frage, ob ein wichtiger Geschäftsprozess nach einem Ausfall wieder funktioniert. Zur Datensicherung gehören deshalb eine geordnete Wiederherstellung und regelmäßig erprobte Abläufe.
Mit den wichtigen Prozessen beginnen
Für die Vorbereitung ist zu klären, welche Anwendungen zuerst benötigt werden und welche Abhängigkeiten bestehen. Neben Nutzdaten können Konfigurationen, Identitätsdienste, Netzwerkverbindungen und geeignete Installationsstände erforderlich sein. Diese Zusammenhänge bestimmen die Reihenfolge des Wiederanlaufs.
Die Fachbereiche sollten benennen, wie lange eine Unterbrechung tragbar ist und welcher Datenverlust höchstens akzeptiert werden kann. Daraus lassen sich Anforderungen an Sicherungsintervalle und Wiederherstellungszeiten ableiten. Ob diese erreichbar sind, zeigt ein geplanter Test.
Sicherung und laufenden Betrieb trennen
Ein Angriff auf Produktivsysteme kann auch erreichbare Sicherungen betreffen. Schutzmaßnahmen für Backup-Daten und getrennte Berechtigungen sind deshalb Teil des Konzepts. Die konkrete technische Ausgestaltung muss zur Umgebung und zum Risiko passen.
Backups ersetzen dabei keine vorbeugende IT-Sicherheit. Sie können die Folgen eines Datenverlusts begrenzen, verhindern aber nicht automatisch den Diebstahl oder die Veröffentlichung vertraulicher Informationen.
Einen vollständigen Test dokumentieren
Eine Erprobung sollte in einer geeigneten, abgestimmten Umgebung stattfinden. Geprüft werden die Wiederherstellung ausgewählter Systeme, die benötigte Zeit und ein fachlicher Funktionstest. Festgestellte Lücken erhalten Verantwortliche und einen Termin zur Bearbeitung.
Auch Erreichbarkeit, Vertretung und Notfallkommunikation gehören dazu. Ein technisch mögliches Verfahren hilft wenig, wenn im Ernstfall Zugänge fehlen oder niemand die nächsten Schritte kennt. Nach wesentlichen Änderungen an Anwendungen oder Infrastruktur sollte die Planung erneut geprüft werden.
Fachlicher Kern: RPO und RTO beantworten unterschiedliche Fragen
Das Recovery Point Objective, kurz RPO, beschreibt, auf welchen Datenstand nach einer Unterbrechung zurückgegriffen werden können muss. Daraus ergibt sich, welcher zeitliche Datenverlust noch tragbar ist. Das Recovery Time Objective, kurz RTO, betrifft dagegen die vorgesehene Zeitspanne für die Wiederherstellung.
Ein fiktives Beispiel: Ein stündlich gesicherter Datenbestand kann zum Ziel eines höchstens einstündigen Datenverlusts passen. Daraus folgt jedoch nicht, dass die Anwendung innerhalb einer Stunde wieder einsatzfähig ist. Datenrücksicherung, Konfiguration, Abhängigkeiten und fachliche Prüfung benötigen zusätzliche Zeit. Beide Ziele müssen getrennt definiert und im Test überprüft werden.
A successful backup notification does not answer whether an important business process will work again after an outage. Backups therefore need structured recovery and regularly rehearsed procedures.
Start with the important processes
Preparation must establish which applications are needed first and which dependencies exist. In addition to user data, configurations, identity services, network connections and suitable installation versions may be required. These relationships determine the restart sequence.
Business teams should specify how long an interruption is tolerable and the maximum acceptable data loss. Requirements for backup intervals and recovery times can be derived from this. A planned test shows whether they are achievable.
Separate backups from live operations
An attack on production systems can also affect reachable backups. Protection for backup data and separate permissions are therefore part of the concept. The specific technical design must fit the environment and the risk.
Backups do not replace preventive IT security. They can limit the consequences of data loss but do not automatically prevent theft or publication of confidential information.
Document a complete test
A trial should take place in a suitable, agreed environment. It checks the restoration of selected systems, the time required and a business-level functional test. Identified gaps are assigned an owner and a date for action.
Availability of contacts, cover arrangements and emergency communication also matter. A technically feasible procedure offers little help if access is missing in an emergency or nobody knows the next steps. Planning should be reviewed after significant application or infrastructure changes.
Technical principle: RPO and RTO answer different questions
The Recovery Point Objective, or RPO, describes the data point to which recovery must be possible after an interruption. It therefore determines the tolerable period of data loss. The Recovery Time Objective, or RTO, concerns the intended recovery time span.
A fictional example: An hourly backup may fit a target of no more than one hour of data loss. This does not mean the application will be operational again within an hour. Restoring data, configuration, dependencies and business-level checks require additional time. Both objectives must be defined separately and verified in testing.