Restores nachweisen: Erfolgskriterien, Isolation, Messung, Beleg

Eine Datei kam zurück, also gilt der Restore-Test als bestanden — belegt ist damit die Lesbarkeit eines Bestands und sonst nichts. Dieses Modul macht aus der Vorführung einen Nachweis: Kriterien, die vor dem Ergebnis feststehen; ein Zielsystem, das nicht unter dem produktiven Namen im Netz erscheint; eine Uhr, die beim Alarm startet und bei der fachlichen Abnahme endet — nicht beim Restore-Befehl. Am Ende steht ein Bericht, den auch jemand auswerten kann, der nicht dabei war.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Ein Test beweist genau das, was vorher als Erfolg definiert war

Bis hierher ist alles Erwartung: Zahlen, ein Entwurf, ein eingerichteter Pfad. Der erste gemessene Restore ist der Punkt, an dem aus der Erwartung ein Nachweis wird — oder eben nicht.

Die häufigste Form dieses Nachweises ist wertlos, und zwar auf eine unauffällige Weise: Jemand holt eine Datei zurück, sie ist da, der Test gilt als bestanden. Was dieser Vorgang belegt, ist die Lesbarkeit eines Bestands. Was er nicht belegt, ist alles andere — die Dauer, die Vollständigkeit, den Weg auf ein Ersatzsystem, die fachliche Brauchbarkeit.

Eine Datei zurückgeholt: Belegt: Der Bestand ist lesbar und der Katalog findet Einzelobjekte. Mehr nicht.
Ein vollständiger Bestand zurückgeholt: Belegt zusätzlich: Umfang und Dauer der Übertragung, unter den Bedingungen des Testtags.
Ein Dienst wieder angelaufen: Belegt zusätzlich: Reihenfolge, Konfiguration, Abhängigkeiten — die Punkte, an denen die meisten Wiederherstellungen tatsächlich hängen bleiben.
Eine fachliche Aufgabe erledigt: Belegt zusätzlich: Berechtigungen, Schnittstellen und Vollständigkeit aus Sicht derer, die den Dienst benutzen.

Jede Zeile kostet mehr als die vorherige, und jede beantwortet eine Frage, die die darüberliegende offenlässt. Welche Zeile ausreicht, ist eine Entscheidung — sie darf nur nicht stillschweigend fallen, indem man die erste Zeile durchführt und die vierte behauptet.

Die Formulierung aus dem LeitfadenNIST SP 800-34 Rev. 1 definiert einen Test als Werkzeug, das mit quantifizierbaren Kennzahlen die Funktionsfähigkeit eines Systems in einer betriebsnahen Umgebung überprüft, und verlangt für jeden Test ausdrücklich vorab festgelegte Ziele und Erfolgskriterien. Beides zusammen ist der Unterschied zwischen einem Test und einer Vorführung: Ohne vorher festgelegtes Kriterium ist das Ergebnis das, was zufällig geschehen ist.

Erfolgskriterien schreibt man vorher auf

Erfolgskriterium — Eine vor dem Test festgelegte, überprüfbare Aussage darüber, welches Ergebnis den Test als bestanden gelten lässt. Sie nennt einen Messwert und eine Schwelle, keine Absicht — „Der Dienst nimmt binnen vier Stunden fachliche Buchungen an“ statt „Die Wiederherstellung funktioniert“.

Der Grund für die Reihenfolge ist menschlich, nicht technisch. Wer nach dem Test entscheidet, ob das Ergebnis genügt, entscheidet unter dem Eindruck des Aufwands, den alle gerade hatten. Ein Test, der sechs statt vier Stunden gedauert hat, gilt dann als „im Rahmen“ — vorher aufgeschrieben wäre er durchgefallen.

Messwert benennen. Dauer vom Auslöser bis zur Abnahme, Zahl der wiederhergestellten Objekte, Ergebnis einer fachlichen Stichprobe.
Schwelle benennen. Aus der Zusage abgeleitet, nicht aus der Erwartung an das Werkzeug.
Umfang benennen. Welche Daten, welcher Zeitpunkt, welches Zielsystem.
Abbruchbedingung benennen. Ab wann der Test beendet wird — sonst wird aus einem Test ein Arbeitseinsatz mit offenem Ende.

Fünf Bereiche — und die meisten Tests decken einen ab

Derselbe Leitfaden listet auf, was ein Test des Wiederanlaufplans abdecken soll. Die Liste ist kurz und in der Praxis ernüchternd, weil ein üblicher Restore-Test genau einen Punkt berührt.

Benachrichtigungswege: Erreicht die Meldung die Personen, die entscheiden dürfen — auch nachts und ohne die eigenen Systeme?
Wiederherstellung auf einer Ersatzplattform aus dem Sicherungsmedium: Läuft das System auf anderer Hardware oder in einer anderen Umgebung wieder an?
Interne und externe Anbindung: Erreichen Clients und Schnittstellenpartner den wiederhergestellten Dienst?
Leistung auf Ersatzausrüstung: Trägt die Ersatzumgebung die tatsächliche Last, oder ist der Dienst formal verfügbar und praktisch unbenutzbar?
Rückkehr in den Normalbetrieb: Wie kommt man von der Ersatzlösung zurück — und wer entscheidet wann darüber?

Die beiden Zeilen, die fast nie geprüft werdenZeile vier und fünf. Eine Ersatzumgebung wird nach Speicherplatz dimensioniert, weil das die sichtbare Größe ist — Prozessorleistung und Ein-/Ausgabe fallen erst unter Last auf, also im Ernstfall. Und die Rückkehr in den Normalbetrieb ist ein eigener, riskanter Vorgang, der ohne Plan im schlechtesten Moment improvisiert wird: wenn alle erschöpft sind und der Druck nachgelassen hat.

Betriebsnah testen, ohne den Betrieb zu zerstören

Hier steckt der eigentliche Zielkonflikt des Moduls. Der Leitfaden verlangt eine möglichst betriebsnahe Umgebung — je näher am echten System, desto aussagekräftiger. Ein Restore in das laufende System ist aber überschreibend: Er ersetzt den aktuellen Stand durch einen älteren und vernichtet dabei genau die Daten, die seit dem Sicherungszeitpunkt entstanden sind.

Überschreibende Wiederherstellung — Ein Restore, der den bestehenden Bestand ersetzt, statt daneben eine Kopie anzulegen. Er ist im Ernstfall oft der richtige Weg und im Test fast nie — und er ist der einzige Vorgang dieses Tracks, der selbst Daten vernichtet.

Weil er das tut, gehört er hinter eine ausdrückliche Freigabe: eine zweite Person, die bestätigt, dass der Zielpfad stimmt und der gewählte Zeitpunkt der beabsichtigte ist. Der teuerste Fehler dieses Tracks ist nicht die fehlende Sicherung, sondern der Restore eines alten Stands über einen intakten Bestand — er verwandelt eine Störung in einen Datenverlust, und zwar durch die Hand derjenigen, die helfen wollten.

Die Auflösung des Zielkonflikts liegt nicht darin, weniger realistisch zu testen, sondern darin, die richtige Sache zu isolieren. Getrennt wird die Identität im Netz, nicht das Verfahren: gleicher Ablauf, gleiche Daten, gleiche Werkzeuge — aber ein Zielsystem, das nicht unter dem produktiven Namen erreichbar ist.

Namen und Adressen. Ein zurückgeholtes System, das unter dem produktiven Namen im Netz erscheint, konkurriert mit dem echten. Clients verbinden sich zufällig auf das eine oder das andere — ein Fehlerbild, das schwer zu deuten und leicht zu vermeiden ist.
Dienstkonten und Anmeldungen. Zwei Systeme mit derselben Kennung am Verzeichnisdienst stören einander; bei manchen Diensten schließt das eine das andere aus.
Ausgehende Verbindungen. Ein wiederhergestelltes System nimmt Arbeit dort auf, wo es aufgehört hat: Es verschickt Nachrichten, ruft Schnittstellen auf, bucht in fremden Systemen. Diese Verbindungen gehören blockiert, bevor das System startet.
Zeitgeber und geplante Aufgaben. Ein Testsystem, dessen Zeitplan noch aktiv ist, führt nachts die Aufgaben des Originals aus.

Die kleinste sichere FormFür einen Datenbestand ohne laufende Anwendung reicht ein Restore in ein anderes Verzeichnis — bei restic etwa restic restore latest --target /tmp/pruefung. Der Vergleich erfolgt dann über Prüfsummen gegen die Quelle, ohne dass irgendetwas überschrieben wird. Für einzelne Dateien genügt sogar restic dump, das den Inhalt auf die Standardausgabe schreibt. Beides beweist Lesbarkeit und Inhalt — und nach wie vor nichts über Dauer und Anlauf des Dienstes.

Die Uhr startet nicht beim Restore-Befehl

Wer die Wiederanlaufzeit misst, misst fast immer den falschen Abschnitt. Gemessen wird die Zeit vom Start der Wiederherstellung bis zu ihrem Ende. Zugesagt ist die Zeit vom Ausfall bis zur Nutzbarkeit. Zwischen beiden liegt regelmäßig mehr als die Hälfte der Gesamtdauer.

Vier Stunden zugesagt, drei Stunden gemessen, sieben Stunden vergangen

Szenario

Für einen Auftragsdienst sind vier Stunden Wiederanlaufzeit zugesagt. Im Test wurde von 09:00 bis 12:00 wiederhergestellt — drei Stunden, Zusage eingehalten, Test bestanden. Bei der Nachbesprechung wird der Ablauf vollständig rekonstruiert.

Anforderungen

Die gemessene Zahl soll dieselbe Größe abbilden wie die Zusage.
Die Messung soll ohne zusätzliche Werkzeuge auskommen.

Schritte

Den tatsächlichen Beginn feststellen: Die Störungsmeldung lag um 07:20 vor, die Entscheidung zur Wiederherstellung fiel um 08:35 — 75 Minuten für Erkennung, Bewertung und Freigabe.
Die Vorbereitung dazurechnen: Von 08:35 bis 09:00 wurde das Zielsystem bereitgestellt und der Zugang beschafft.
Den gemessenen Kern übernehmen: 09:00 bis 12:00, drei Stunden technische Wiederherstellung.
Den Nachlauf ergänzen: Bis 14:20 liefen Dienste in Reihenfolge hoch, wurde die Anbindung geprüft und die fachliche Stichprobe durchgeführt.
Die Summe bilden: 07:20 bis 14:20 sind sieben Stunden. Die Zusage von vier Stunden ist deutlich verfehlt, obwohl jeder einzelne Abschnitt unauffällig war.

Merksatz: Die Uhr startet bei der ersten Meldung und endet bei der fachlichen Abnahme. Wer nur den technischen Kern misst, berichtet eine Zahl, die niemanden interessiert — und findet die beiden größten Posten nie, weil sie außerhalb des gemessenen Fensters liegen.

Wer abnimmt, entscheidet, was der Test wert ist

Ein technisch erfolgreicher Restore ist eine Aussage der IT über die IT. Ob der Dienst wieder benutzbar ist, kann nur beantworten, wer ihn benutzt — und diese Antwort ist regelmäßig eine andere.

Technischer Erfolg: Der Bestand ist zurück, die Prozesse laufen, die Oberfläche antwortet. Feststellbar durch den Betrieb.
Fachliche Abnahme: Eine echte Aufgabe lässt sich durchführen: ein Auftrag anlegen, einen Beleg drucken, eine Auswertung erzeugen. Feststellbar nur durch den Fachbereich.
Der Unterschied: Fehlende Berechtigungen, ein nicht mitgesicherter Vorlagenordner, eine Schnittstelle, die auf das alte System zeigt — nichts davon fällt technisch auf.

Die Abnahmeliste, die einmal geschrieben wirdDrei bis fünf Aufgaben je Dienst, formuliert vom Fachbereich, jede in wenigen Minuten durchführbar. Diese Liste ist der billigste dauerhafte Gewinn dieses Moduls: Sie wird einmal geschrieben, gilt für jeden künftigen Test und für den Ernstfall, und sie beendet die Diskussion darüber, ob „der Dienst wieder läuft“ — weil sie sie in eine Frage verwandelt, die jemand mit Ja oder Nein beantworten kann.

Die Abnahme hat noch eine zweite Wirkung, die selten geplant ist: Sie bindet den Fachbereich in die Wiederherstellung ein, bevor der Ernstfall eintritt. Wer einmal in einem Test bestätigt hat, dass ein Dienst benutzbar ist, weiß im Ernstfall, was von ihm erwartet wird — und diskutiert nicht mehr darüber, ob das seine Aufgabe sei. Das ist ein organisatorischer Gewinn, den kein technischer Test erzeugt.

Welchen Restore man testet

Die Auswahl des Testfalls entscheidet über den Erkenntniswert mehr als die Sorgfalt der Durchführung. Und sie fällt fast immer auf denselben Fall: den, der zuletzt funktioniert hat.

Nicht immer denselben Dienst. Der geübte Fall verrät nichts Neues; der ungeübte enthält die Befunde.
Nicht immer den jüngsten Stand. Ein alter Stand prüft die Aufbewahrungstiefe, die Speicherklasse und die Kette — drei Dinge, die der jüngste Stand nie berührt.
Zufällig auswählen statt vorbereiten. Ein angekündigter Test mit vorbereitetem Zielsystem misst die Vorbereitung, nicht die Fähigkeit.
Auch den unangenehmen Fall. Der Dienst mit der ältesten Dokumentation, der Server ohne benannten Eigentümer, das System, das nur eine Person kennt.

Jüngster Stand, geübter Dienst: Prüft den Alltagsweg. Erkenntniswert nach dem zweiten Mal nahe null — geeignet als Routineprüfung, nicht als Nachweis.
Alter Stand aus der Aufbewahrungstiefe: Prüft Kette, Speicherklasse und Abrufzeit auf einmal. Der Test mit dem besten Verhältnis von Aufwand zu Befunden.
Ungeübter Dienst, zufällig gezogen: Prüft Dokumentation und Übertragbarkeit des Verfahrens. Erzeugt die unangenehmsten und nützlichsten Befunde.
Wiederherstellung auf Ersatzhardware: Prüft die Annahme, die im Ernstfall zuerst trägt oder bricht. Aufwendig — deshalb selten, aber nicht nie.

Ein praktikabler Kompromiss für kleine Teams: eine feste Frequenz mit zufälliger Auswahl innerhalb der obersten Schutzklasse. Vier Tests im Jahr, jedes Mal ein anderer Dienst, jedes Mal ein anderer Zeitpunkt in der Aufbewahrung. Das kostet vier halbe Tage und deckt über zwei Jahre den größten Teil der Klasse ab.

Der Test ohne den Erbauer

Die wirksamste Steigerung des Erkenntniswerts kostet nichts: Der Test wird von jemandem durchgeführt, der die Umgebung nicht gebaut hat, ausschließlich anhand der vorhandenen Dokumentation. Was dabei fehlt, fehlt im Ernstfall auch — nur dann unter Zeitdruck und ohne die Möglichkeit nachzufragen.

Kurzcheck

Bei einem Test nach diesem Muster bleibt die durchführende Person nach 20 Minuten stecken: In der Anleitung fehlt, unter welchem Konto das Sicherungssystem erreichbar ist. Wie ist der Test zu bewerten?

Als bestandener Test mit einem Befund: Die Lücke ist das Ergebnis, das er liefern sollte.
Als nicht bestanden: Der Restore wurde nicht abgeschlossen, also fehlt die Messung.
Als ungültig: Die fehlende Angabe hätte vorab ergänzt werden müssen.

Treffer. Richtig. Der Test hat genau die Frage beantwortet, für die er gemacht wurde — ob die Dokumentation trägt. Ein Befund nach 20 Minuten ist der billigste mögliche Ausgang.

Der Beleg: was der Bericht enthalten muss

Der Leitfaden verlangt für jede Test- und Übungsaktivität einen Nachbericht mit den gewonnenen Erkenntnissen und den daraus abgeleiteten Korrekturmaßnahmen. Entscheidend ist, dass dieser Bericht ein Jahr später noch benutzbar ist — von jemandem, der nicht dabei war.

Was geprüft wurde: Dienst, Zeitpunkt des Stands, Zielsystem, Umfang. Ohne diese vier Angaben ist der Bericht nicht wiederholbar.
Die Erfolgskriterien: Wörtlich so, wie sie vorher aufgeschrieben wurden — nicht nachträglich an das Ergebnis angepasst.
Die Messwerte: Uhrzeiten der Abschnitte, Objektzahl, Größe. Zahlen, keine Bewertungen.
Das Urteil: Bestanden oder nicht, gemessen an den Kriterien. Ein Satz.
Die Befunde mit Eigentümer und Termin: Ein Befund ohne Namen und Datum ist eine Notiz. Die Wirkung des Tests entsteht hier, nicht beim Restore.

Der Bericht ist außerdem das einzige Artefakt dieses Moduls, das gegenüber Dritten trägt — gegenüber der Geschäftsführung, einem Wirtschaftsprüfer, einem Versicherer oder einem Kunden mit eigenen Anforderungen. Diese Leserschaft interessiert sich nicht für den Ablauf, sondern für zwei Dinge: ob ein Kriterium vorher feststand und ob das Ergebnis daran gemessen wurde. Ein Bericht, der beides zeigt, beendet Diskussionen, die sonst jedes Jahr neu geführt werden.

Die Zeile, die den Bericht rettetDie letzte. Ein Testprogramm, das Befunde erzeugt und nicht schließt, produziert nach drei Jahren eine Liste bekannter Mängel und dieselbe Wiederanlaufzeit wie am Anfang. Wenn nur eine Zeile aus diesem Modul in die eigene Vorlage übernommen wird, dann diese.

Was ein bestandener Test nicht beweist

Ein bestandener Restore-Test ist ein starker Beleg für einen eng umrissenen Fall. Die Grenzen gehören in denselben Bericht, sonst wird aus dem Beleg eine falsche Sicherheit.

Die Abhängigkeiten waren intakt. Verzeichnisdienst, Namensauflösung und Netz standen — im Ernstfall womöglich nicht.
Es war ein Dienst. Ein Test misst nie den Wettbewerb um dieselben Leitungen, Personen und Zielsysteme, der entsteht, wenn zwanzig Dienste gleichzeitig zurückkommen sollen.
Die Menschen waren verfügbar. Der Test lief zur Arbeitszeit mit den Zuständigen im Haus.
Die Umgebung war unversehrt. Ein Test unterstellt vertrauenswürdige Systeme — nach einem Angriff gilt genau das nicht mehr.

Diese vier Punkte sind kein Argument gegen den Test, sondern die Begründung für die Module, die noch kommen. Der gleichzeitige Wiederanlauf vieler Dienste ist Gegenstand des Wiederanlaufs, die unversehrte Umgebung Gegenstand der Module über Angriffsfälle, und die Verfügbarkeit der Menschen Gegenstand des Übungsprogramms.

Abgrenzung

Hier geht es um den Nachweis für einen einzelnen Dienst. Wie ein Programm aus mehreren Testarten entsteht — Planbesprechung, technischer Test, Vollübung — und wie Befunde über Jahre gesteuert werden, steht im Modul über das Übungsprogramm.

NachbartracksKontrollierte Fehlerinjektion und Verfügbarkeitsexperimente stehen in monitoring-incident-operations; die Prüfung von Wiederanlaufannahmen aus Sicht des Service-Managements in itsm-operations. Hier interessiert der Nachweis, dass aus einer Sicherung ein benutzbarer Dienst wird.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität3 Primärquellen · zuletzt geprüft: 2026-09-04