Bildquelle: extern
Backups wirken im IT-Betrieb oft wie eine beruhigende Antwort auf fast jede Krise. Daten werden regelmäßig gesichert, Speicherziele sind vorhanden, Jobs laufen grün und ein Dashboard zeigt Erfolg. Für ITSM-Generalisten ist das wichtig, aber noch nicht ausreichend. Im Ausfall entscheidet nicht die Existenz einer Sicherung, sondern der echte Wiederanlauf eines Services.
Kurz gesagt Ein Backup ist eine Kopie von Daten oder Systemständen. Ein Wiederanlauf ist der praktische Weg zurück zu einem nutzbaren Service, mit Infrastruktur, Identitäten, Berechtigungen, Netzwegen, Fachprüfung und Kommunikation. Genau deshalb muss der Servicebetrieb nicht nur fragen, ob Daten gesichert sind. Er muss prüfen, ob aus diesen Daten wieder ein funktionierender Geschäftsprozess wird.
Der Unterschied klingt klein, ist aber operativ groß. Eine Datenbank kann technisch wiederhergestellt sein, während die Anwendung noch keinen Zugriff hat. Ein Fileshare kann verfügbar sein, während Berechtigungen fehlen. Ein Fachsystem kann starten, aber niemand weiß, ob der Datenstand für den nächsten Arbeitstag reicht. Solche Lücken erkennt man selten in einer Backup-Statistik. Sie zeigen sich erst in einem Wiederanlauftest.
Die Sicherung ist nur ein Baustein
Backup-Jobs beantworten vor allem die Frage, ob Daten an einen anderen Ort geschrieben wurden. Für den Betrieb geht es danach weiter. Wo liegt die Wiederherstellungsanleitung? Wer darf sie starten? Welche Systeme müssen zuerst zurückkommen? Welche Abhängigkeiten zu Identitätsdiensten, Namensauflösung, Netzwerk, Schnittstellen und Fachfreigaben bestehen? Ohne diese Sicht bleibt der Wiederanlauf eine technische Hoffnung.
Gerade moderne Serviceketten bestehen aus mehreren Schichten. Ein Portal braucht vielleicht eine Datenbank, ein Dateisystem, einen Login-Dienst, eine API zu einem Drittanbieter und ein Monitoring, das nach dem Neustart nicht sofort falschen Alarm erzeugt. Wenn nur einzelne Komponenten gesichert wurden, aber keine getestete Reihenfolge existiert, kann der Service trotz vorhandener Kopien lange blockiert bleiben.
Wiederanlaufziele müssen in Servicesprache übersetzt werden
In Notfallkonzepten tauchen oft zwei Zielgrößen auf. Das Recovery Time Objective beschreibt grob, wie schnell ein Service wieder nutzbar sein soll. Das Recovery Point Objective beschreibt, wie viel Datenverlust höchstens akzeptabel ist. Für Nicht-Spezialisten heißt das einfacher: Wie lange darf der Dienst ausfallen und auf welchen Stand darf er höchstens zurückfallen?
Diese Ziele gehören nicht nur in eine technische Tabelle. Sie müssen mit dem Fachbereich und dem Service Desk abgestimmt sein. Ein CRM-System braucht andere Grenzen als ein Archiv. Ein Ticketsystem hat andere Folgen als ein reines Testsystem. ITSM kann hier vermitteln, weil es den Servicekontext kennt und technische Wiederherstellung in nachvollziehbare Betriebszusagen übersetzt.
Ein Restore-Test ohne Nutzerprüfung bleibt halb
Ein technischer Restore-Test ist wichtig. Er zeigt, ob Dateien, Datenbanken oder Maschinen aus einer Sicherung zurückkommen. Er reicht aber nicht, wenn danach niemand die fachliche Nutzbarkeit prüft. Die entscheidende Frage lautet nicht nur, ob ein Server startet. Sie lautet, ob der betroffene Service wieder so funktioniert, dass Nutzer ihre Arbeit fortsetzen können.
Deshalb sollte jeder ernsthafte Test eine kurze Nutzer- oder Fachprüfung enthalten. Kann sich eine berechtigte Person anmelden? Sind die wichtigsten Daten sichtbar? Funktioniert ein typischer Vorgang von Anfang bis Ende? Stimmen Schnittstellen und Benachrichtigungen? Gibt es nach dem Wiederanlauf eine klare Kommunikation an Support, Fachbereich und Management? Diese Punkte machen aus einer Technikprobe einen Service-Test.
Protokolle helfen nur mit Entscheidungen dahinter
NIST beschreibt in seiner Notfallplanungslogik unter anderem Tests, Übungen, Rollen und laufende Pflege von Wiederanlaufplänen. CIS Control 11 fordert nicht nur Datensicherungen, sondern auch Wiederherstellungstests. CISA empfiehlt im Ransomware-Kontext ebenfalls robuste Backups und erprobte Wiederherstellung. Die gemeinsame Botschaft ist für ITSM gut verständlich: Schutz entsteht nicht allein durch Kopien, sondern durch geübte Rückkehr in den Betrieb.
Wichtig ist, dass Testprotokolle nicht als Ablage enden. Aus jedem Test sollten Entscheidungen folgen. Welche Reihenfolge war falsch? Welche Berechtigung fehlte? Welche Kontaktperson war veraltet? Welche Serviceabhängigkeit war nicht dokumentiert? Welche Zeitannahme war zu optimistisch? Wenn diese Fragen nicht in Problem Management, Change Management und Servicekatalog zurückfließen, wird der nächste Test denselben Mangel erneut finden.
Ransomware macht die Reihenfolge noch wichtiger
Bei klassischen Ausfällen kann der Betrieb oft relativ schnell entscheiden, welcher Stand zurückgespielt wird. Bei Ransomware ist das schwerer. Dann geht es zusätzlich darum, ob Sicherungen unverändert geblieben sind, welche Systeme sauber sind, welche Identitäten vertrauenswürdig sind und ob eine vorschnelle Rückkehr die Infektion wieder einschleppt. Ein Backup allein beantwortet diese Fragen nicht.
Für ITSM heißt das: Der Wiederanlauf braucht einen eigenen Entscheidungsraum. Security, Infrastruktur, Fachbereich, Service Owner und Kommunikation müssen wissen, welche Freigabe vor welchem Schritt nötig ist. Sonst gewinnt der Wunsch nach Tempo gegen die nötige Vorsicht. Ein geübter Ablauf schützt vor hektischen Einzelentscheidungen und macht sichtbar, wo ein Service wirklich wieder belastbar ist.
Eine praktikable Prüffrage für den Alltag
Teams müssen nicht jeden Monat ein Großszenario durchspielen. Schon kleinere, rotierende Tests bringen viel. Einmal wird ein einzelner kritischer Datensatz zurückgeholt. Ein anderes Mal wird ein Fachprozess auf einer Testumgebung neu gestartet. Danach wird eine Kontaktkette geprüft oder eine Wiederanlaufreihenfolge aktualisiert. Entscheidend ist, dass der Test konkret genug ist, um echte Lücken zu zeigen.
Eine einfache Leitfrage hilft: Welcher Nachweis zeigt, dass dieser Service nach einem Ausfall nicht nur Daten besitzt, sondern wieder arbeitsfähig ist? Wenn die Antwort nur auf Backup-Logs verweist, fehlt ein Teil der Betriebsreife. Wenn sie einen getesteten Ablauf, klare Rollen, eine fachliche Prüfung und dokumentierte Grenzen enthält, wird aus der Sicherung ein belastbarer Wiederanlaufplan.
Fazit
Backups sind unverzichtbar, aber sie sind kein fertiger Service-Rettungsplan. Der eigentliche Wert entsteht erst, wenn Wiederherstellung, Reihenfolge, Verantwortlichkeiten und fachliche Nutzbarkeit gemeinsam geprüft werden. ITSM sollte deshalb Backup-Status nicht mit Betriebsfähigkeit verwechseln. Wer den Wiederanlauf regelmäßig übt, findet Lücken früher, erklärt Risiken besser und kommt im Ernstfall schneller zu einer kontrollierten Entscheidung.
Quellen und Einordnung Geprüft wurden NIST Special Publication 800-34 Rev. 1 zur Notfallplanung, CIS Control 11 zu Data Recovery und der CISA Ransomware Guide. Bildquelle: Pexels, Transport einer weißen Box als Symbol für gesicherte Daten und Wiederanlaufvorbereitung, https://www.pexels.com/photo/man-carrying-a-white-box-7581041/. Stand der Quellenprüfung: 20.06.2026.
