Warum Backups ohne Rückkehrtest trügerisch beruhigen

Ein Backup beruhigt, weil es nach Kontrolle klingt. Für den IT-Betrieb reicht diese Beruhigung aber nicht aus. Entscheidend ist nicht, ob irgendwo Daten gesichert wurden. Entscheidend ist, ob ein Service nach einem Ausfall in einer brauchbaren Form wieder arbeiten kann.

Backup bedeutet, Daten oder Systemstände als Sicherung vorzuhalten. Wiederanlauf bedeutet, daraus einen nutzbaren Service zurückzubringen. Für ITSM-Generalisten liegt genau dort der Unterschied: Die Sicherung ist ein technischer Baustein, der Wiederanlauf ist ein betrieblicher Nachweis. Er zeigt, ob Nutzer, Fachbereiche und Support nach einer Störung wieder mit dem Dienst arbeiten können.

NIST beschreibt in seiner Contingency-Planning-Leitlinie, dass Notfallvorsorge nicht bei Sicherungskopien endet. Planung, Wiederherstellungsprioritäten, Tests, Übungen und Pflege gehören zusammen. CISA und das britische NCSC betonen bei Ransomware und Ausfallschutz ebenfalls, dass Backups getrennt, geschützt und praktisch wiederherstellbar sein müssen. Daraus folgt für Serviceverantwortliche: Ein Backup ohne Rückkehrtest ist nur eine Annahme.

Die falsche Frage lautet: Haben wir ein Backup?

In Statusrunden klingt die Frage nach dem Backup oft eindeutig. Ja oder nein. Diese Abkürzung ist gefährlich, weil sie mehrere wichtige Punkte verdeckt. Welche Daten sind enthalten? Von welchem Zeitpunkt stammen sie? Liegen Konfigurationen, Berechtigungen, Schnittstellen und Schlüssel ebenfalls vor? Wer darf die Wiederherstellung auslösen? Wie lange dauert sie wirklich? Welche Fachprüfung entscheidet, ob der Dienst wieder nutzbar ist?

Ein grünes Backup-Protokoll beantwortet diese Fragen nicht automatisch. Es kann bestätigen, dass eine Sicherung erstellt wurde. Es sagt aber nicht sicher, ob die Sicherung vollständig, aktuell, lesbar, geschützt und in der richtigen Reihenfolge einspielbar ist. Gerade moderne Services bestehen selten nur aus einer Datenbank. Sie hängen an Identitäten, Netzfreigaben, Cloud-Diensten, Zertifikaten, Schnittstellen, Jobs und Fachprozessen.

Darum braucht ITSM eine bessere Leitfrage: Welchen Service können wir aus dieser Sicherung bis wann wieder arbeitsfähig machen? Diese Frage zwingt zur Serviceperspektive. Sie verbindet Technik, Priorität und Nutzerwirkung. Sie verhindert, dass sich Organisationen an einer Sicherungsdatei festhalten, während der eigentliche Geschäftsprozess noch stillsteht.

Ein Rückkehrtest zeigt die echten Lücken

Ein Rückkehrtest ist eine kontrollierte Probe, bei der ein Service oder ein wichtiger Teil davon aus gesicherten Daten und dokumentierten Schritten wiederhergestellt wird. Er muss nicht immer den kompletten Ernstfall nachstellen. Er muss aber genug Realität enthalten, um blinde Stellen sichtbar zu machen. Kann das Team die Sicherung finden? Stimmen Zugangsdaten und Rollen? Funktioniert die Reihenfolge? Sind Abhängigkeiten bekannt? Gibt es eine klare Entscheidung, wann abgebrochen oder eskaliert wird?

Solche Tests wirken manchmal unbequem, weil sie alte Gewissheiten stören. Genau darin liegt ihr Wert. Sie zeigen, dass eine Wiederherstellung zwar technisch möglich ist, aber zu lange dauert. Sie zeigen, dass ein Dienst zurückkommt, aber die Schnittstelle zum Fachsystem fehlt. Sie zeigen, dass der technische Owner handeln kann, aber der Service Desk keine verständliche Nutzerinformation hat. Das sind keine Randdetails. In einem Ausfall entscheiden sie über Vertrauen und Schaden.

Für den IT-Betrieb ist besonders wichtig, dass der Test nicht nur im Serverteam bleibt. Ein Service Owner muss bestätigen, welche Mindestfunktion nach der Wiederherstellung zählt. Der Fachbereich muss sagen, welche Arbeit zuerst wieder möglich sein muss. Der Support braucht eine Meldung, die Unsicherheit offen benennt und trotzdem Orientierung gibt. Erst dann wird aus Datenrettung wieder Servicefähigkeit.

Ransomware macht den Unterschied schmerzhaft sichtbar

Bei Ransomware zeigt sich der Unterschied zwischen Backup und Wiederanlauf besonders deutlich. Angreifer versuchen häufig, Sicherungen zu verschlüsseln, zu löschen oder Zugänge zu missbrauchen. CISA empfiehlt deshalb robuste, getrennte und getestete Backups als Teil der Vorsorge. Für ITSM heißt das: Die Backup-Strategie gehört nicht nur in die Technikdokumentation. Sie gehört in die Service- und Krisenplanung.

Ein betroffener Service braucht Prioritäten. Nicht jedes System kann gleichzeitig zurückkommen. Manche Daten sind wichtiger als andere. Manche Dienste müssen in einer reduzierten Form starten, damit Fachbereiche überhaupt weiterarbeiten können. Manche Systeme dürfen erst nach Sicherheitsprüfung wieder verbunden werden. Ohne vorherige Entscheidung entsteht im Ernstfall ein Streit über Reihenfolge, Risiko und Verantwortung.

Auch die Kommunikation muss vorbereitet sein. Nutzer wollen nicht wissen, wie viele Terabyte gesichert wurden. Sie wollen wissen, welcher Dienst betroffen ist, ob Daten verloren sein könnten, welche Umwege gelten und wann die nächste belastbare Aussage kommt. Ein Wiederanlaufplan übersetzt technische Wiederherstellung in verständliche Betriebsführung.

Die Wiederherstellungszeit muss zur Servicezusage passen

Viele Organisationen kennen Begriffe wie RTO und RPO. RTO beschreibt grob, wie schnell ein Dienst wieder verfügbar sein soll. RPO beschreibt, wie viel Datenverlust zeitlich höchstens akzeptiert wird. Für Generalisten reicht zunächst die einfache Übersetzung: Wie lange darf der Service fehlen und auf welchen letzten Stand müssen wir zurückkommen?

Diese Ziele dürfen nicht nur auf Folien stehen. Sie müssen gegen die echte Wiederherstellung geprüft werden. Wenn ein kritischer Dienst laut Servicezusage nach vier Stunden wieder laufen soll, der letzte Test aber acht Stunden dauerte, ist die Zusage nicht belastbar. Wenn höchstens eine Stunde Datenverlust akzeptiert wird, die Sicherung aber nur einmal nachts läuft, passt die Sicherung nicht zum Risiko. Das Problem ist dann nicht nur technisch, sondern vertraglich, organisatorisch und kommunikativ.

Darum sollte jeder wichtige Service eine kleine Wiederanlaufakte haben. Sie enthält die Priorität, die akzeptable Ausfallzeit, den tolerierbaren Datenstand, die wichtigsten Abhängigkeiten, die verantwortlichen Rollen, den letzten Testerfolg, die bekannten Lücken und eine verständliche Nutzerkommunikation. Diese Akte muss kurz genug sein, damit sie gepflegt wird. Sie muss aber konkret genug sein, damit sie im Ernstfall führt.

So wird aus Sicherung ein belastbarer Betriebsnachweis

Der erste Schritt ist eine Service-Landkarte der kritischen Dienste. Welche Systeme, Daten, Schnittstellen und Rollen braucht der Dienst wirklich? Der zweite Schritt ist eine klare Priorisierung. Nicht die lauteste Anwendung gewinnt, sondern der größte Betriebs- und Nutzerschaden. Der dritte Schritt ist ein regelmäßiger Rückkehrtest mit dokumentierter Dauer, Ergebnis und offener Nacharbeit.

Wichtig ist außerdem die Trennung von Erfolg und Teilerfolg. Ein Test ist nicht automatisch bestanden, nur weil Daten kopiert wurden. Bestanden ist er erst, wenn der vereinbarte Servicezustand erreicht und fachlich bestätigt wurde. Wenn nur ein Teil funktioniert, ist das kein Scheitern, sondern ein wertvoller Befund. Er muss als Aufgabe in den Betrieb zurückfließen.

Für ITSM entsteht daraus eine einfache Regel: Backup-Berichte sind gut, aber Wiederanlaufberichte sind besser. Sie zeigen, ob eine Organisation nach einem Ausfall nicht nur Daten besitzt, sondern den Service wieder führen kann. Genau dieser Nachweis entscheidet, ob ein Backup im Ernstfall beruhigt oder nur trügerische Sicherheit liefert.

Quellen und Einordnung: NIST SP 800-34 Rev. 1 zu Contingency Planning, CISA StopRansomware Guide sowie NCSC-Hinweise zu Backups. Stand der Quellenprüfung 24.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.