Backups zählen erst, wenn die Wiederherstellung geübt ist

Ein Backup beruhigt schnell. Es gibt einen Haken im Kontrollsystem, eine grüne Meldung im Dashboard und vielleicht sogar einen täglichen Report. Für den IT-Betrieb ist das aber nur die halbe Wahrheit. Entscheidend ist nicht, ob irgendwo Daten kopiert wurden. Entscheidend ist, ob ein kritischer Service nach einem Fehler, einem Fehlupdate, einem Angriff oder einem versehentlichen Löschen wirklich wieder arbeitsfähig wird.

Genau hier liegt der Unterschied zwischen Datensicherung und Betriebsfähigkeit. Ein Backup ist eine Kopie. Wiederherstellung ist ein Ablauf mit Prioritäten, Zuständigkeiten, Zeitdruck, Abhängigkeiten und Kommunikation. Wer nur die Kopie prüft, merkt oft erst im Ernstfall, dass Anwendungen, Identitäten, Berechtigungen, Schnittstellen oder externe Provider nicht im gleichen Tempo zurückkommen.

Der grüne Backup-Report beantwortet die falsche Frage

Backup-Reports prüfen häufig, ob ein Job gelaufen ist. Das ist wichtig, aber zu eng. Sie sagen selten, ob die gesicherten Daten vollständig sind, ob sie zur passenden Anwendungsversion gehören, ob Schlüssel und Zertifikate vorhanden sind, ob Abhängigkeiten bekannt sind und ob die Wiederherstellung in der erforderlichen Zeit gelingt. Ein grüner Job kann deshalb eine gefährliche Scheinsicherheit erzeugen.

Für den Servicebetrieb zählt eine andere Frage. Welcher Geschäftsprozess steht wieder zur Verfügung, wenn diese Sicherung zurückgespielt wird. Bei einem Ticketsystem reicht zum Beispiel nicht die Datenbank allein. Es braucht Benutzerzugänge, Mailanbindung, Anhänge, Automatisierungen, Schnittstellen, Rollen, aktuelle Konfiguration und eine klare Information an Service Desk und Anwender. Erst dann ist der Service wirklich zurück.

Zeitziele müssen aus dem Geschäft kommen

In technischen Gesprächen fallen schnell Kürzel wie RTO und RPO. RTO beschreibt, wie lange die Wiederherstellung dauern darf. RPO beschreibt, wie viel Datenverlust höchstens akzeptabel ist. Diese Werte dürfen nicht allein im Infrastrukturteam entstehen. Sie müssen aus der Bedeutung des Services für Kunden, Fachbereiche, Lieferketten, Compliance und interne Arbeitsfähigkeit abgeleitet werden.

Wenn ein System für Rechnungen, Kundenkommunikation oder Schichtplanung wichtig ist, kann eine Wiederherstellung am nächsten Tag zu spät sein. Wenn ein Archivsystem selten genutzt wird, kann ein längerer Zeitraum akzeptabel sein. ITSM muss diese Unterschiede sichtbar machen. Sonst werden alle Services gleich behandelt, obwohl sie im Ernstfall sehr unterschiedliche Folgen haben.

Wiederherstellungstests zeigen versteckte Abhängigkeiten

Ein echter Restore-Test ist unbequem, gerade deshalb ist er wertvoll. Er zeigt, welche Dokumentation veraltet ist, welche Zugänge fehlen, welche Skripte nur auf dem alten Server laufen, welche Firewall-Regeln vergessen wurden und welche Person noch exklusives Wissen besitzt. Diese Erkenntnisse sind kein Scheitern des Tests. Sie sind der eigentliche Nutzen.

Gute Tests beginnen nicht mit dem größten Katastrophenszenario. Ein einzelner Service, eine definierte Datenmenge, ein begrenztes Testfenster und ein klarer Beobachtungsbogen reichen für den Anfang. Wichtig ist, dass nicht nur Technik misst. Auch der Service Desk, ein Fachbereich und eine verantwortliche Person aus dem Betrieb sollten prüfen, ob der zurückgeholte Service verständlich, nutzbar und kommunizierbar ist.

Ransomware macht alte Annahmen wertlos

Ransomware verändert die Backup-Frage. Wenn Angreifer lange im Netzwerk waren, kann nicht jede Sicherung automatisch als sauber gelten. CISA und internationale Sicherheitsbehörden betonen deshalb, wie wichtig offline oder getrennt geschützte Sicherungen, Wiederherstellungspläne und geübte Abläufe sind. Für den Betrieb heißt das. Der Restore darf nicht nur schnell sein. Er muss auch nachvollziehbar, sauber und kontrolliert erfolgen.

Das betrifft auch Rollen und Freigaben. Wer entscheidet, welcher Zeitpunkt wiederhergestellt wird. Wer prüft, ob Daten manipuliert wurden. Wer informiert Kunden oder interne Nutzer. Wer hält den Kontakt zu Security, Datenschutz, Rechtsabteilung und Management. Wenn diese Fragen erst während eines Angriffs geklärt werden, verliert der Betrieb wertvolle Zeit und riskiert falsche Zusagen.

Der Service Desk braucht mehr als eine Störungsmeldung

Nach einer Wiederherstellung ist der Service Desk oft die erste sichtbare Stelle für Nutzer. Er muss wissen, was wieder funktioniert, was noch eingeschränkt ist, welche Daten möglicherweise fehlen und welche Workarounds gelten. Ohne diese Information entsteht ein zweiter Schaden. Anwender bekommen widersprüchliche Antworten, Tickets werden doppelt eröffnet und Fachbereiche verlieren Vertrauen.

Deshalb gehört Kommunikation in jeden Restore-Test. Eine kurze Vorlage hilft. Betroffener Service, Ursache soweit bekannt, aktueller Zustand, erwartete Einschränkungen, nächste Aktualisierung und Ansprechpartner. Diese Vorlage muss vor dem Ernstfall existieren. Im Ausfall selbst sollte niemand mehr darüber diskutieren, wie eine verständliche Statusmeldung aufgebaut wird.

Eine einfache Prüfliste macht den Anfang

ITSM-Verantwortliche können mit wenigen Fragen starten. Welche zehn Services würden den größten Schaden verursachen, wenn sie morgen nicht verfügbar wären. Gibt es pro Service ein akzeptiertes Zeit- und Datenverlustziel. Wurde die Wiederherstellung im letzten Jahr praktisch getestet. Ist dokumentiert, welche Abhängigkeiten mit zurückkommen müssen. Weiß der Service Desk, wie er nach einem Restore kommuniziert. Gibt es eine Entscheidung, welche Sicherungen im Verdacht eines Angriffs verwendet werden dürfen.

Wenn eine Antwort offen bleibt, ist das kein Grund für Alarmismus. Es ist ein Arbeitsauftrag. Die Reihenfolge sollte pragmatisch sein. Erst die wichtigsten Services priorisieren, dann die Restore-Schritte dokumentieren, anschließend einen kleinen Test durchführen und danach die Lücken schließen. So wird aus Backup-Management ein Service-Resilience-Prozess.

Backups sind kein Archiv, sondern ein Versprechen

Ein Backup verspricht, dass der Betrieb nach einem Fehler nicht von vorne anfangen muss. Dieses Versprechen ist aber erst belastbar, wenn es geprobt wurde. Der Test zeigt, ob Daten, Systeme, Menschen und Kommunikation zusammenpassen. Er zwingt Organisationen, technische Sicherung mit Serviceverantwortung zu verbinden.

Die stärkste Frage lautet deshalb nicht, ob die letzte Sicherung erfolgreich war. Sie lautet, welcher Service damit in welcher Zeit für wen wieder nutzbar wird. Wer diese Frage beantworten und belegen kann, hat mehr als Speicherplatz gesichert. Er hat Vertrauen in den Betrieb geschaffen.

Quellen. CISA StopRansomware Guide. NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems. NCSC Guidance, Mitigating malware and ransomware attacks. IBM Think, Backup and disaster recovery.