Wiederherstellbarkeit sichtbar machen: Kennzahlen, die eine Zusage belegen

Hundert grüne Sicherungsläufe belegen keine einzige Zusage: Sie messen den Apparat, nicht die Fähigkeit. Dieses Modul ersetzt die Jobüberwachung durch vier Kennzahlen, die sich unmittelbar auf den Recovery-Vertrag abbilden — und räumt dabei mit der beliebtesten auf, der Abdeckungsquote, deren Nenner aus derselben Quelle stammt wie ihr Zähler und die sogar steigt, wenn man ein problematisches Objekt aus der Sicherung entfernt.

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

Von der Jobüberwachung zum Zusagenachweis

Die Überwachung aus dem Modul über die Einrichtung beantwortet eine Frage je Pfad: Ist der letzte Lauf jung genug? Dieses Modul beantwortet eine Frage über den ganzen Bestand: Können wir unsere Zusagen heute noch einhalten, und woran sehen wir das?

Der Unterschied ist nicht akademisch. Ein Betrieb kann hundert grüne Sicherungsläufe haben und trotzdem keine einzige Zusage belegen — weil niemand weiß, welche Dienste überhaupt abgedeckt sind, wann zuletzt ein Restore gelungen ist und ob die Unveränderbarkeitssperre noch wirkt. Die grünen Läufe messen den Apparat, nicht die Fähigkeit.

Assurance — Der belegbare Zustand, dass eine zugesagte Fähigkeit heute vorhanden ist. Sie entsteht nicht aus der Abwesenheit von Fehlermeldungen, sondern aus einer kleinen Zahl von Kennzahlen, die sich unmittelbar auf die Zusagen abbilden lassen.

Der Anlass, diesen Schritt zu gehen, kommt in der Regel von außen: eine Prüfung, ein Vorfall bei einem Wettbewerber, eine Frage der Geschäftsführung nach einer Zeitungsmeldung. In diesem Moment ist die Antwort „unsere Sicherungen laufen“ erkennbar zu schwach, und es gibt nichts Besseres, weil nie jemand gemessen hat. Die vier Kennzahlen dieses Moduls sind deshalb weniger ein Beitrag zur Technik als eine Vorsorge gegen diese Frage — und sie kosten, einmal eingerichtet, wenige Minuten im Monat.

Vier Signale, die einen Bestand beschreiben

Mehr als eine Handvoll Kennzahlen pflegt niemand dauerhaft. Vier reichen, wenn jede von ihnen eine Zusage aus dem Recovery-Vertrag spiegelt.

Frische: Alter des jüngsten verwertbaren Stands je Dienst. Spiegelt die zugesagte Verlustgrenze und ist die einzige Kennzahl in derselben Einheit wie die Zusage.
Abdeckung: Anteil der Dienste im Inventar, deren Datenorte tatsächlich gesichert werden. Spiegelt die Schutzklasse — und wird fast immer falsch gemessen.
Sperrzustand: Ob die Unveränderbarkeit wirkt und wer sie aufheben kann. Spiegelt den Schutz gegen den vierten Schadensweg.
Nachweisalter: Zeit seit dem letzten gemessenen, bestandenen Restore je Dienst oder Schutzklasse. Spiegelt die zugesagte Wiederanlaufzeit.

Die vierte Zeile ist die, die in kaum einem Betrieb existiert — und die einzige, die eine Aussage über die Wiederanlaufzeit trägt. Eine Sicherung, deren Wiederherstellung seit zwei Jahren niemand gemessen hat, belegt die Verlustgrenze und nicht die Ausfallgrenze. Beide Zusagen brauchen eigene Belege.

Woher die vier Zahlen kommenFrische und Sperrzustand liefert das Sicherungssystem selbst — bei restic etwa gibt restic snapshots --json je Bestand den Zeitpunkt des jüngsten Stands, und der Sperrzustand steht in der Konfiguration des Ziels. Die Abdeckung entsteht aus der Zuordnung zum Inventar und ist Handarbeit. Das Nachweisalter kommt aus den Testberichten. Drei der vier lassen sich automatisch erheben; die vierte lebt davon, dass Berichte überhaupt geschrieben werden.

Die Falle der zirkulären Abdeckung

Die Abdeckungskennzahl wird üblicherweise aus dem Sicherungssystem gezogen: Wie viele der dort eingerichteten Objekte wurden erfolgreich gesichert? Das ergibt fast immer eine hohe Zahl — und beantwortet die falsche Frage.

Denn der Nenner stammt aus derselben Quelle wie der Zähler. Ein Dienst, den niemand eingerichtet hat, taucht in beiden nicht auf und senkt die Quote nicht. Die Kennzahl misst damit die Zuverlässigkeit des Sicherungssystems und nicht die Abdeckung des Bestands — und sie steigt sogar, wenn man ein problematisches Objekt aus der Sicherung entfernt.

Die Korrektur ist einfach und unbequemDer Nenner muss aus dem Inventar kommen, nicht aus dem Sicherungssystem: Anteil der Dienste mit Schutzklasse, deren sämtliche Datenorte nachweislich gesichert werden. Diese Zahl ist bei der ersten Messung regelmäßig erschreckend und danach die einzige, die einen Fortschritt zeigt, der etwas bedeutet. Die Zuordnungsarbeit dahinter ist genau die aus dem Inventarmodul — sie fällt einmal an und macht diese Kennzahl überhaupt erst möglich.

Dieselbe Zirkularität steckt in einer verwandten Formulierung, die in Berichten häufig auftaucht: „alle kritischen Systeme sind gesichert“. Kritisch sind dort in aller Regel die Systeme, die jemand als kritisch eingerichtet hat — also wieder dieselbe Quelle. Die belastbare Fassung nennt den Nenner mit: „von 62 Diensten mit bestätigter Schutzklasse sind 53 an allen Datenorten abgedeckt“. Diese Zahl ist unbequemer und beantwortet die Frage.

Was der Leitfaden als Kennzahlen vorschlägt

NIST SP 800-184 führt Beispielkennzahlen nach Bereichen auf. Zwei davon lohnen die genaue Lektüre, weil ihre Formulierung eine verbreitete Abkürzung ausschließt.

Anteil erfolgreicher und fristgerechter Wiederherstellungen aus Sicherungen oder Ersatzmedien. Das Wort fristgerecht steht dort ausdrücklich: Eine gelungene, aber zu langsame Wiederherstellung zählt nicht als Erfolg.
Zahl der Wiederherstellungsereignisse, die ihre Recovery-Ziele erreicht haben. Gemessen wird gegen die Ziele, nicht gegen den Abschluss — dieselbe Unterscheidung wie beim Erfolgskriterium eines Tests.
Häufigkeit und Umfang von Übungen und Tests, in Anzahl pro Jahr.
In Übungen oder Tests gefundene Lücken, als Anzahl — der Zusammenhang zwischen Übungsprogramm und Verbesserung, als Zahl ausgedrückt.

Die ersten beiden zusammen ergeben eine unangenehm ehrliche Kennzahl: nicht „wie oft hat der Restore funktioniert“, sondern „wie oft hat er innerhalb der zugesagten Zeit funktioniert“. In vielen Betrieben unterscheiden sich diese beiden Zahlen erheblich, und die Differenz ist genau der Teil, der im Ernstfall wehtut.

Die Kennzahl, die das Nichtwissen misst

Zwei weitere Beispiele aus derselben Quelle sind ungewöhnlich, weil sie nicht Leistung messen, sondern Lücken im eigenen Bild: die Zahl erheblicher Vorfälle, die in der Risikobetrachtung nicht erkannt worden waren, und die korrekt erfasste Abhängigkeitslage, ausgedrückt als Zahl der nicht erkannten Werte.

Was diese Kennzahlen besonders macht: Sie steigen, wenn man genauer hinsieht, und sinken erst, wenn das Bild tatsächlich besser wird. Sie belohnen also nicht Stillhalten.
Woher die Zahlen kommen: Aus Übungen, Tests und echten Vorfällen — nicht aus der laufenden Überwachung. Es sind Kennzahlen des Lernens, nicht des Betriebs.
Warum sie unbeliebt sind: Ein Bericht, in dem eine Zahl steigt, sieht nach Verschlechterung aus. Wer sie einführt, muss diese Lesart vorher entkräften — sonst wird das Messen selbst zum Risiko für die Messenden.

Der praktische Nutzen ist trotzdem erheblich: Eine Abhängigkeit, die in der Übung erstmals auffällt, ist eine gefundene Lücke — und ihre Zahl über mehrere Übungen hinweg sagt mehr über den Reifegrad aus als jede Erfolgsquote. Ein Programm, in dem diese Zahl bei null liegt, hat entweder ein perfektes Inventar oder zu einfache Übungen.

Nachweise altern

Ein bestandener Restore-Test belegt einen Zustand zu einem Zeitpunkt. Die Umgebung ändert sich danach weiter: neue Dienste, neue Abhängigkeiten, andere Datenmengen, geänderte Speicherklassen. Der Nachweis verliert dadurch Aussagekraft, ohne dass irgendetwas eine Meldung erzeugt.

Der Nachweis, der zwei Jahre alt ist

Szenario

Für einen Dienst der obersten Schutzklasse liegt ein bestandener Restore-Bericht von vor 26 Monaten vor: vier Stunden gemessen, vier Stunden zugesagt. Seither wurde der Datenbestand von 3 auf 11 TB vergrößert und die Aufbewahrung ab Tag 30 in eine Archivklasse verschoben.

Anforderungen

Die Aussage über die Wiederanlaufzeit soll belastbar bleiben.
Der Aufwand soll sich auf das beschränken, was sich tatsächlich geändert hat.

Schritte

Feststellen, dass der Bericht einen Zustand belegt, den es nicht mehr gibt — er ist damit kein falscher Bericht, sondern ein abgelaufener.
Die beiden Änderungen einzeln bewerten: Die Datenmenge ist auf das Vierfache gestiegen, was die Übertragungszeit unmittelbar betrifft; die Archivklasse setzt für alte Stände eine Abrufzeit vor jede Übertragung.
Die Rechnung neu aufmachen, bevor gemessen wird: Vier Stunden waren für 3 TB knapp; für 11 TB sind sie rechnerisch ausgeschlossen.
Den Nachweis als abgelaufen kennzeichnen und die Zusage bis zur nächsten Messung als unbelegt führen — nicht als eingehalten und nicht als gerissen.
Für die Zukunft einen Auslöser setzen: Jede wesentliche Änderung an Datenmenge, Speicherklasse oder Abhängigkeiten setzt das Nachweisalter des betroffenen Dienstes zurück.

Merksatz: Ein Nachweis hat eine Haltbarkeit, und sie endet nicht nach einer festen Frist, sondern mit der nächsten wesentlichen Änderung. Wer das Nachweisalter als Kennzahl führt und an Änderungen koppelt, hat einen Indikator, der ohne zusätzliche Messung altert — und der genau dann Aufmerksamkeit erzeugt, wenn sich etwas geändert hat.

Warum ein Kalenderturnus dafür nicht reichtEin jährlicher Turnus behandelt einen unveränderten Dienst wie einen, dessen Datenmenge sich vervierfacht hat. Die Kopplung an Änderungen trifft dagegen genau die Fälle, in denen der Nachweis tatsächlich seine Aussagekraft verliert — und sie lässt ruhige Dienste in Ruhe. Beides zusammen ist am besten: ein weiter Turnus als Untergrenze und Änderungen als Auslöser. Wenn nur eines geht, ist es der Auslöser.

Vorlaufende und nachlaufende Signale

Kennzahlen unterscheiden sich darin, ob sie eine Lage noch abwenden lassen oder nur beschreiben, was passiert ist. Für ein kleines Team ist das die wichtigste Sortierung, weil sie festlegt, worauf Aufmerksamkeit gelegt wird.

Vorlaufend: Alter des jüngsten Stands, Auslastung des Sicherungsfensters, Nachweisalter, Zahl der Dienste ohne Klasse. Sie zeigen eine Verschlechterung, bevor sie Folgen hat.
Nachlaufend: Anteil erfolgreicher Wiederherstellungen, Zahl der Störungen, gemessene Ausfallzeiten. Sie belegen die Vergangenheit und taugen für Berichte.
Der übliche Fehler: Ausschließlich nachlaufende Kennzahlen zu berichten, weil sie leichter zu erheben sind — und sich dann zu wundern, dass der Bericht keine Handlung auslöst.

Die Auslastung des Sicherungsfensters ist dabei das unterschätzte Beispiel: Sie ist die einzige Größe im Sicherungsbetrieb, die sich ohne Zutun verschlechtert, und sie warnt Monate vor dem Überlauf. Wer sie nicht führt, erfährt vom zu kleinen Fenster erst durch übersprungene Läufe.

Für die Einführung gilt eine praktische Reihenfolge: zuerst die vorlaufenden Kennzahlen, weil sie Handlung auslösen, und erst danach die nachlaufenden, weil sie berichtet werden. Wer umgekehrt beginnt, baut ein Berichtswesen über einen Zustand, den niemand steuert — und stellt nach zwei Quartalen fest, dass die Zahlen zwar vorliegen, sich aber nicht bewegen.

Wenn die Meldung das richtige Verhalten beschreibt

Ein Teil der Ereignisse, die in einer gut gebauten Sicherungsarchitektur entstehen, sind Belege dafür, dass sie wirkt. Werden sie als Störung geführt, trainiert sich das Team an, sie wegzuklicken — und verliert damit die Meldungen, die tatsächlich zählen.

Das gilt über den Einzelfall hinaus. Eine wirksame Aufbewahrungssperre erzeugt abgelehnte Löschversuche. Ein Ziel, das nur Anlegen erlaubt, erzeugt abgelehnte Änderungsversuche. Eine getrennte Aufhebungsrolle erzeugt Berechtigungsfehler, wenn jemand aus Gewohnheit den falschen Weg nimmt. Alle drei sind Belege für eine funktionierende Trennung — und alle drei landen in einer unbedachten Überwachung als Fehler.

Kurzcheck

Im Protokoll des Sicherungsziels erscheinen regelmäßig Antworten 403 Forbidden auf versionsbezogene Löschanfragen des Aufräumauftrags. Wie ist damit umzugehen?

Als erwartetes Ereignis führen und getrennt auswerten — es belegt, dass die Sperre wirkt.
Als Fehler des Aufräumauftrags behandeln und ihn so ändern, dass er gesperrte Objekte überspringt.
Die Meldungen unterdrücken, weil sie im Normalbetrieb keinen Handlungsbedarf erzeugen.

Treffer. Richtig. Die Ablehnung ist der Beweis für eine wirksame Aufbewahrungssperre. Sie gehört gezählt und nicht alarmiert — und ihr Ausbleiben wäre der interessante Befund.

Die allgemeine Regel dahinterJedes Ereignis bekommt eine von drei Einstufungen: alarmieren (jemand muss jetzt handeln), zählen (gehört in den Bericht, kein Handlungsbedarf) oder verwerfen (ohne Aussagewert). Die mittlere Kategorie wird meist vergessen, und dann landet alles in einer der beiden Extreme — mit dem Ergebnis, dass entweder zu viel alarmiert oder zu viel weggeworfen wird.

Wer beobachtet das Sicherungssystem

Die Überwachung meldet Zustände von Diensten. Das Sicherungssystem selbst ist ein Dienst, und in vielen Betrieben derjenige, über den am wenigsten bekannt ist — obwohl er die weitreichendsten Rechte besitzt und im Ernstfall als Erstes gebraucht wird.

Anmeldungen des Sicherungskontos außerhalb der Sicherungsfenster. Eine der wenigen Auswertungen, die mit wenig Aufwand einen echten Angriffshinweis liefert.
Änderungen an Aufbewahrungsregeln und Sperren. Sie verändern die Wiederherstellbarkeit rückwirkend und erzeugen sonst keine sichtbare Wirkung.
Wer besitzt aktuell das Recht, Sperren aufzuheben oder Bestände zu löschen? Eine Rechteauswertung, keine Statusabfrage — und deshalb eine, die turnusmäßig laufen muss.
Der Aufräumauftrag auf der Zielseite. Sein Ausfall ist leiser als der einer Sicherung und läuft den Speicher voll.

Die Kennzahl dazuFür die dritte Zeile genügt eine Zahl je Bestand: wie viele Rollen können die Aufbewahrungssperre aufheben oder Objekte endgültig löschen? Steigt sie, ist etwas passiert, das niemand berichtet hat. Bleibt sie bei eins oder zwei, ist die Trennung intakt. Diese Zahl ist mit einer einfachen Auswertung zu erheben und der beste Einzelindikator für den Schutz gegen den vierten Schadensweg.

Der Grund für diesen eigenen Abschnitt ist eine Asymmetrie: Fällt ein Fachdienst aus, merkt es der Fachbereich binnen Minuten. Fällt das Sicherungssystem aus oder wird es manipuliert, merkt es niemand — es hat keine Anwender, die sich beschweren. Seine Überwachung ist deshalb die einzige, die vollständig aus eigenem Antrieb entstehen muss, und sie fällt in kleinen Teams als Erstes hinten runter.

Berichten an Dritte

Irgendwann fragt jemand von außen: eine Prüfung, ein Versicherer, ein Kunde mit eigenen Anforderungen, die Geschäftsführung nach einem Vorfall in der Branche. Diese Leserschaft interessiert sich nicht für Sicherungsläufe, sondern für zwei Dinge — gibt es eine Zusage, und ist sie belegt.

Die Zusage: Verlustgrenze, Ausfallgrenze und Umfang je Schutzklasse, bestätigt von benannten Eigentümern.
Der Beleg: Nachweisalter je Klasse, Anteil fristgerecht erfolgreicher Wiederherstellungen, Abdeckung gegen das Inventar.
Die Grenze: Was ausdrücklich nicht abgedeckt ist — Dienste ohne Klasse, offene Befunde mit Termin, Szenarien außerhalb des Übungsprogramms.

Die dritte Zeile ist die, die einen Bericht glaubwürdig macht. Eine Darstellung ohne benannte Grenzen wird von erfahrenen Prüfern als unvollständig gelesen, und die Nachfragen richten sich dann auf alles. Wer die Grenzen selbst benennt, führt das Gespräch — und der Aufwand dafür entsteht ohnehin, weil die offenen Befunde aus dem eigenen Testprogramm stammen.

Der häufigste Fehler in solchen BerichtenZahlen ohne Bezugsgröße. „98 Prozent erfolgreiche Sicherungsläufe“ klingt gut und beantwortet keine der beiden Fragen — es sagt nichts über die Zusage und nichts darüber, ob ein Restore je gelungen ist. Ein Bericht, der stattdessen drei Zeilen je Schutzklasse enthält — zugesagte Grenzen, Nachweisalter, Abdeckung gegen das Inventar —, ist kürzer und beantwortet, was gefragt war.

Abgrenzung

Hier geht es um die Kennzahlen, die eine Wiederherstellungszusage belegen. Wie die Übungen entstehen, aus denen ein Teil dieser Zahlen kommt, und wie ihre Befunde gesteuert werden, ist Gegenstand des nächsten Moduls.

NachbartracksÜberwachungsarchitektur, Signalqualität und Alarmgestaltung im Allgemeinen behandelt monitoring-incident-operations; Dienstgüte und Berichtswesen aus Sicht des Service-Managements itsm-operations. Hier interessiert nur der Ausschnitt, der eine Aussage über Wiederherstellbarkeit trägt.

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