Bildquelle: Pexels / https://www.pexels.com/photo/325229/
Kurz gesagt Ein Backup beruhigt nur so lange, bis ein Service wirklich daraus zurückkommen muss. Für ITSM-Verantwortliche zählt deshalb nicht nur, ob Daten regelmäßig gesichert werden. Entscheidend ist, ob die Rücksicherung geübt, priorisiert, fachlich abgestimmt und im Störungsfall verständlich gesteuert wird.
CISA bündelt unter StopRansomware Hinweise zur Vorbereitung auf Erpressungsangriffe und zur Wiederherstellung nach solchen Vorfällen. Der Ransomware Guide von CISA und MS-ISAC empfiehlt unter anderem getestete Backups, getrennte Kopien und klare Wiederanlaufplanung. Das NIST Cybersecurity Framework ordnet Wiederherstellung ausdrücklich als eigene Sicherheitsfunktion ein. IBM beschreibt Disaster-Recovery-Tests als kontrollierte Prüfung, ob Wiederherstellungspläne, Systeme und Abläufe im Ernstfall wirklich tragfähig sind.
Ein Backup ist eine Sicherheitskopie von Daten oder Systemzuständen. Eine Rücksicherung ist der praktische Weg zurück in einen nutzbaren Betrieb. Genau dieser zweite Teil wird im Alltag leicht unterschätzt. Erst die Probe zeigt, ob Daten vollständig, erreichbar, sauber priorisiert und für den betroffenen Service rechtzeitig nutzbar sind.
Der grüne Sicherungsjob beantwortet nicht die wichtigste Frage
Viele Werkzeuge melden zuverlässig, ob eine Sicherung gelaufen ist. Diese Meldung ist nützlich, aber sie sagt noch nicht, ob ein Fachbereich nach einem Ausfall wieder arbeiten kann. Ein Job kann grün sein, obwohl die falschen Daten priorisiert wurden, ein Schlüssel fehlt, eine abhängige Datenbank nicht passt oder niemand weiß, wer den Wiederanlauf freigibt.
Aus Sicht des Service Managements beginnt die eigentliche Prüfung deshalb nach der Sicherung. Welcher Service hängt an welchem Datensatz? Welche Anwendung braucht zuerst eine lauffähige Umgebung? Welche Reihenfolge verhindert Folgefehler? Wer entscheidet, ob ein älterer Stand akzeptabel ist? Solche Fragen lassen sich nicht im ersten Krisenchat sauber klären. Sie gehören in vorbereitete Wiederanlaufpläne.
Rücksicherung ist eine Serviceentscheidung
Technisch betrachtet kann eine Rücksicherung ein Restore aus einem Backup-System sein. Operativ ist sie aber eine Serviceentscheidung. Ein Kundenportal, ein Ticketsystem, eine Produktionsschnittstelle und ein internes Reporting haben unterschiedliche Erwartungen an Datenalter, Ausfallzeit, Kommunikation und Testtiefe. Wer alles gleich behandelt, verschwendet Zeit an unkritischen Stellen und riskiert Fehlstarts bei wichtigen Services.
Darum brauchen Backups eine Verbindung zum Servicekatalog. Der Katalog muss nicht jede Datei aufführen. Er sollte aber sichtbar machen, welche Systeme für einen Service wirklich nötig sind, welche Daten zuerst zurückkommen müssen und welche Fachbereiche nach der Wiederherstellung prüfen müssen. Erst dann wird aus technischer Datensicherung ein steuerbarer Wiederanlauf.
Prioritäten müssen vor dem Ernstfall stehen
Ein häufiger Denkfehler liegt in der Annahme, dass im Notfall einfach alles wiederhergestellt wird. In der Praxis konkurrieren Speicher, Netzwerk, Fachpersonal, externe Dienstleister und Entscheidungszeit. Besonders nach Ransomware-Vorfällen kann zusätzlich unklar sein, welche Systeme sauber sind und welche Datenstände vertrauenswürdig bleiben. Dann braucht der Betrieb eine Reihenfolge, die vorher entschieden wurde.
Eine brauchbare Priorisierung verbindet geschäftliche Wirkung mit technischer Abhängigkeit. Das wichtigste System ist nicht immer das System mit dem lautesten Nutzerkreis. Manchmal muss zuerst Identität, Netzwerk, Namensauflösung, Datenbank oder Schnittstellenplattform zurückkommen, damit andere Services überhaupt starten können. ITSM kann hier helfen, weil es Servicewirkung, Eskalationsweg und Kommunikationsbedarf zusammenführt.
Der Test muss mehr prüfen als die Datei
Eine Rücksicherungsprobe darf nicht bei der Frage enden, ob eine Datei geöffnet werden kann. Der Test muss zeigen, ob ein Service mit dem zurückgespielten Stand fachlich nutzbar ist. Dazu gehören Anmeldungen, Schnittstellen, Berechtigungen, aktuelle Stammdaten, Berichte, Protokolle und die Frage, ob Fachbereiche den wiederhergestellten Zustand akzeptieren können.
Gute Tests bleiben dabei begrenzt und wiederholbar. Niemand muss jedes Mal den kompletten Unternehmensausfall simulieren. Wertvoller ist ein klares Szenario mit Lernziel: ein Fachsystem, ein kritischer Datensatz, eine abhängige Schnittstelle und eine dokumentierte Entscheidung über zulässigen Datenverlust. So entstehen messbare Erkenntnisse statt nur ein Haken im Auditordner.
Kommunikation gehört zum Wiederanlauf
Backups wirken technisch, werden im Ausfall aber sofort kommunikativ. Nutzer wollen wissen, welche Daten fehlen könnten, welche Funktionen wieder nutzbar sind und wann sie normal weiterarbeiten können. Fachbereiche müssen prüfen, ob Buchungen, Tickets, Bestellungen oder Kundeninformationen vollständig genug sind. Der Service Desk braucht klare Aussagen, damit nicht jede Nachfrage einzeln eskaliert.
Deshalb gehört Kommunikation in die Rücksicherungsplanung. Wer informiert zuerst? Welche Aussage ist erlaubt, bevor die Fachprüfung abgeschlossen ist? Wer erklärt einen Rücksprung auf einen älteren Datenstand? Wo werden bekannte Einschränkungen veröffentlicht? Ohne diese Vorbereitung kann eine technisch gelungene Wiederherstellung trotzdem Vertrauen verlieren.
Prüffragen für den nächsten Backup-Review
- Welche Services haben eine dokumentierte Wiederherstellungsreihenfolge?
- Welche Datenstände sind fachlich noch akzeptabel und wo wäre ein älterer Stand kritisch?
- Wer darf eine Rücksicherung freigeben und wer muss sie fachlich abnehmen?
- Welche Abhängigkeiten müssen vor dem eigentlichen Fachsystem wieder laufen?
- Wann wurde zuletzt nicht nur gesichert, sondern praktisch zurückgesichert?
- Welche Nutzerinformation ist vorbereitet, falls Daten oder Funktionen eingeschränkt zurückkommen?
Fazit
Backups sind nur die halbe Absicherung. Ihr Wert entsteht erst, wenn der Betrieb weiß, wie Daten, Systeme, Rollen und Kommunikation wieder zusammenfinden. ITSM sollte Rücksicherung deshalb nicht als reines Infrastrukturthema behandeln. Der entscheidende Nachweis lautet: Der Service kommt in einer verständlichen Reihenfolge zurück, Verantwortliche entscheiden rechtzeitig und Nutzer bekommen belastbare Informationen.
