Wiederherstellbarkeit als Zusage: MTD, RTO, RPO und der Umfang

Der Sicherungsjob meldet seit Monaten grün, und trotzdem ist unklar, ob der Dienst nach einem Schaden zurückkommt — und wie viel Arbeit dabei verloren geht. Dieses Modul ist der Einstieg in den Track und beantwortet die Fragen, die vor jeder Produktauswahl stehen: Woher die Zahlen kommen, warum die Wiederanlaufzeit kürzer sein muss als die tolerierte Ausfallzeit, warum eine tägliche Sicherung eine Vier-Stunden-Zusage nie einhalten kann, und was außer den Daten noch zum Dienst gehört. Vorkenntnisse brauchst du keine; alle Begriffe werden eingeführt, bevor sie benutzt werden.

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

Ein grüner Sicherungsjob ist kein Ergebnis

Auf fast jedem Server läuft eine Sicherung, und in fast jedem Betrieb steht dafür ein grünes Häkchen. Das Häkchen sagt: Daten wurden gelesen und an ein Ziel geschrieben. Es sagt nichts darüber, ob aus diesen Daten wieder ein benutzbarer Dienst wird, wie lange das dauert und wie viel Arbeit dabei verloren geht.

Genau diese Lücke ist der Gegenstand des Tracks. Wiederherstellbarkeit ist eine Eigenschaft des Dienstes, nicht der Datei. Sie entsteht nicht durch den Kauf eines Produkts, sondern dadurch, dass ein paar Zahlen vereinbart, gerechnet und geprüft werden. Wer diese Zahlen nicht hat, betreibt kein Backupkonzept, sondern einen Sicherungsjob.

Ohne Vorkenntnisse lesbarDieses Modul ist der Einstieg in den Track. Alle Begriffe werden eingeführt, bevor sie benutzt werden, und es setzt kein bestimmtes Backupprodukt voraus — im Gegenteil: Die Entscheidungen hier fallen, bevor ein Produkt ausgewählt wird. Wer sie überspringt, kauft ein Werkzeug für eine Aufgabe, die noch niemand aufgeschrieben hat.

Vier Zahlen — und die IT besitzt nur zwei davon

In Gesprächen tauchen meist zwei Abkürzungen auf: RPO und RTO. Der maßgebliche Leitfaden, NIST SP 800-34 Rev. 1, führt eine dritte Größe ein, die über beiden steht — und macht damit einen Unterschied sichtbar, der in der Praxis fast immer fehlt.

MTD — Maximum Tolerable Downtime: Die gesamte Ausfallzeit, die der Eigentümer des Geschäftsprozesses zu akzeptieren bereit ist. Sie schließt laut NIST alle Auswirkungen ein, nicht nur die technische Wiederherstellung.
RTO — Recovery Time Objective: Die Zeit, die eine einzelne technische Ressource ausfallen darf, bevor der Ausfall unvertretbar auf andere Ressourcen, den Geschäftsprozess und die MTD durchschlägt.
RPO — Recovery Point Objective: Der Zeitpunkt vor der Störung, auf den die Daten zurückgeholt werden können — bestimmt durch die jüngste verwertbare Kopie.
Nachverarbeitung: Die Zeit nach dem technischen Restore, bis der Prozess wieder normal läuft: Daten prüfen, Belege nacherfassen, liegengebliebene Warteschlangen abarbeiten.

Der Satz, den fast jeder Plan verletztNIST SP 800-34 stellt zwei Sätze nebeneinander, die zusammen die häufigste Planungslücke beschreiben. Erstens: Die RPO ist im Unterschied zur RTO nicht Teil der MTD — sie misst tolerierbaren Datenverlust, nicht eine Zeitspanne im Ausfallbudget. Zweitens: Die RTO muss normalerweise kürzer sein als die MTD, weil die Zeit für das Nacharbeiten der Daten zur RTO hinzukommt und beides zusammen in die MTD passen muss.

Praktisch heißt das: Wenn der Prozesseigentümer „acht Stunden“ sagt, ist das die MTD. Dauert die Wiederherstellung sechs Stunden und erfassen danach zwei Mitarbeitende drei Stunden lang Belege nach, ist die MTD gerissen — obwohl die IT ihre sechs Stunden eingehalten hat. Die richtige Reihenfolge lautet deshalb: MTD erfragen, Nachverarbeitung schätzen, und erst die Differenz ist das Budget für die RTO.

Woher die Zahlen kommen: die Business Impact Analysis

Business Impact Analysis (BIA) — Die Analyse, die für jeden Geschäftsprozess bestimmt, welchen Schaden ein Ausfall anrichtet und wie lange er dauern darf. Sie ist die einzige legitime Quelle der MTD; die IT kann sie nicht ersetzen, weil ihr die Schadenshöhe nicht bekannt ist.

NIST SP 800-34 beschreibt die BIA in drei Schritten, und ihre Reihenfolge ist kein Zufall:

Geschäftsprozesse und ihre Kritikalität bestimmen — und mit den Prozesseigentümern die akzeptable Ausfallzeit festlegen.
Die Ressourcen erfassen, die der Prozess braucht: Server, Anwendungen, Daten, Schnittstellen, Personen.
Daraus die Wiederherstellungsprioritäten ableiten — die Reihenfolge, in der im Ernstfall tatsächlich gearbeitet wird.

Der dritte Schritt ist der, der im Ernstfall zählt, und der, den fast niemand vorher aufschreibt. Ohne ihn entscheidet unter Druck, wer gerade am Telefon ist — und die Wahl fällt dann auf das System, das am lautesten reklamiert wird, nicht auf das, an dem die anderen hängen.

Wenn keine BIA existiertDas ist im Mittelstand der Normalfall. Der brauchbare Ersatz besteht nicht darin, die Zahlen selbst zu erfinden, sondern sie als Vorschlag zu formulieren und schriftlich bestätigen zu lassen: „Wir legen für diesen Dienst vier Stunden Datenverlust und acht Stunden Ausfall zugrunde. Wenn das nicht stimmt, sag es jetzt.“ Ein bestätigter Vorschlag ist eine Zusage; eine unbestätigte Annahme ist eine Ausrede.

Die RPO steht in der Zeitplanzeile, nicht in der Präsentation

Die RPO ist die einzige der vier Größen, die sich unmittelbar aus einer Konfigurationszeile ablesen lässt. Wer täglich um 23 Uhr sichert, hat diese Zeile: 0 23 * * *. Sie ist die tatsächliche RPO-Zusage; alles darüber hinaus ist Absicht.

Die Rechnung ist unangenehm einfach. Fällt der Dienst um 22:00 aus, ist die jüngste Kopie 23 Stunden alt. Der schlechteste Fall eines Sicherungsintervalls liegt immer knapp beim Intervall selbst, nicht bei seiner Hälfte. Eine tägliche Sicherung erfüllt deshalb niemals eine zugesagte RPO von vier Stunden — und kein Produktwechsel ändert daran etwas, nur ein anderes Intervall tut das.

Zwei Zuschläge, die niemand mitrechnetDer Abstand zwischen zwei Läufen ist die Untergrenze, nicht der Wert. Erstens dauert die Sicherung selbst: Ein Lauf von 23:00 bis 03:00 liefert für zuerst gesicherte Objekte den Stand 23:00, für zuletzt gesicherte den Stand 03:00 — ohne besondere Vorkehrungen ist ein Backup kein einheitlicher Zeitpunkt. Zweitens die Erkennungszeit: Wird eine Datenverfälschung erst nach drei Tagen bemerkt, hilft nicht die jüngste Kopie, sondern die jüngste unverfälschte — und die ist drei Tage alt.

Der zweite Punkt erklärt, warum Rhythmus und Aufbewahrung getrennte Größen sind. Die RPO beantwortet „wie eng liegen die Kopien beieinander“; die Aufbewahrung beantwortet „wie weit reichen sie zurück“. Ein Konzept mit engem Rhythmus und kurzer Aufbewahrung ist gegen Hardwareausfall gut aufgestellt und gegen stille Verfälschung wehrlos.

Die RTO ist eine Summe, kein einzelner Messwert

Bei der RTO wird meist der falsche Wert gemessen. Gemessen wird, wie lange das Zurückspielen dauert; zugesagt wird, wann der Dienst wieder nutzbar ist. Dazwischen liegen mindestens vier Summanden.

Erkennung und Entscheidung — von der ersten Meldung bis zu der Person, die den Restore auslöst. Ohne benannte Rufbereitschaft ist das nachts der größte Posten.
Bereitstellung des Ziels — ein Server, eine virtuelle Maschine, eine Datenbankinstanz. Muss erst Hardware beschafft werden, ist die RTO in Wochen zu messen.
Übertragung und Wiederherstellung — der Teil, den die Software erledigt und den man vorab rechnen kann.
Nachlauf und fachliche Abnahme — Protokolle nachfahren, Dienste in der richtigen Reihenfolge starten, und jemand, der bestätigt, dass die Anwendung fachlich stimmt.

Was 12 TB über eine Leitung wirklich kosten

Szenario

Für eine Dateiablage mit 12 TB sind sechs Stunden Wiederanlaufzeit zugesagt. Die Sicherung liegt im Objektspeicher eines anderen Standorts, angebunden mit 1 Gbit/s.

Anforderungen

Die Zusage soll vor dem Ernstfall bestätigt oder widerlegt werden.
Für die Größenordnung soll keine Messung im Produktivbetrieb nötig sein.

Schritte

Die theoretische Obergrenze der Leitung bestimmen: 1 Gbit/s sind 125 MB/s — wenn nichts anderes darauf läuft und kein Protokoll-Overhead anfällt.
12 TB durch 125 MB/s teilen: rund 96.000 Sekunden, also etwa 27 Stunden. Nur für die Bytes, unter idealen Bedingungen.
Die drei anderen Summanden addieren: Erkennung und Entscheidung, Bereitstellung des Ziels, Nachlauf und Abnahme.
Das Ergebnis der Zusage gegenüberstellen: Sechs Stunden werden um mehr als das Vierfache verfehlt — aus einem Grund, den kein Produktwechsel behebt.
Die Konsequenz benennen: entweder die Zusage korrigieren oder den Wiederherstellungsweg ändern — eine zusätzliche Kopie am Standort, ein priorisierter Teil-Restore, oder ein Verfahren, das den Dienst vor den vollständigen Daten wieder verfügbar macht.

Merksatz: Die Rechnung dauert zwei Minuten und braucht keinen Test. Sie beantwortet nicht, ob die Wiederherstellung funktioniert — aber sie widerlegt unhaltbare Zusagen, bevor Geld für ein Produkt ausgegeben wird, das an der Leitung ohnehin scheitert.

Der Umfang: was außer den Daten zum Dienst gehört

Wiederherstellungsumfang — Die vollständige Menge dessen, was vorhanden sein muss, damit ein Dienst nach einem Schaden wieder benutzbar ist — nicht nur die Nutzdaten, sondern alles, ohne das die Nutzdaten wertlos bleiben.

Die meisten gescheiterten Wiederherstellungen scheitern nicht an den Daten. Sie scheitern an einem Bestandteil, den niemand als Teil des Dienstes betrachtet hat, weil er im Normalbetrieb einfach da ist.

Konfiguration — Einstellungen, die nicht im Datenverzeichnis liegen, sondern in einer Datei, einer Registry oder einer Verwaltungsoberfläche.
Identitäten und Berechtigungen — ein wiederhergestellter Dateibestand ohne die zugehörigen Zugriffsrechte ist ein Datenhaufen, kein Dienst.
Schlüssel und Zertifikate — verschlüsselte Sicherungen sind ohne ihren Schlüssel nur belegter Speicherplatz.
Namensauflösung und Adressen — der Dienst muss unter dem Namen erreichbar sein, den Clients kennen.
Lizenzen und Installationsmedien — die Software selbst ist selten Teil der Datensicherung.
Der Katalog der Sicherung — die Information, welche Sicherung welche Objekte enthält und wo sie liegen.

Der Fall, der ganze Wiederherstellungen aufhältDer letzte Punkt ist der unangenehmste. Viele Sicherungssysteme führen eine eigene Datenbank darüber, welche Sicherung welche Objekte enthält — und sie steht gern auf demselben Server, der ausfällt. Dann sind die Sicherungsdaten physisch vorhanden und nicht zuzuordnen. Andere Werkzeuge legen ihre Metadaten in das Repository selbst: restic speichert jeden Snapshot als eigenes Dokument im Verzeichnis snapshots der Sicherung, sodass der Katalog mit den Daten reist. Die Prüffrage lautet in beiden Fällen: Wird der Katalog gesichert, und ist der Weg dokumentiert, ihn ohne den ausgefallenen Server zu lesen?

Abhängigkeiten setzen die Untergrenze

Ein Dienst kann nicht schneller zurückkommen als das, worauf er steht. Eine zugesagte RTO von zwei Stunden für eine Anwendung, deren Anmeldung an einem Verzeichnisdienst mit acht Stunden RTO hängt, ist keine Zusage — sie ist eine Rechenschwäche.

Netz und Namensauflösung→Verzeichnisdienst und Anmeldung→Schlüssel- und Zertifikatsverwaltung→Datenbank→Anwendung→Fachliche Abnahme

Die reale RTO ist die Summe der Kette, nicht der Wert des letzten Glieds

Daraus folgt eine Prüfregel, die sich am Schreibtisch anwenden lässt: Für jeden Dienst mit einer zugesagten RTO die Kette aufschreiben und für jedes Glied fragen, ob es eine eigene, kleinere Zusage hat. Wo die Antwort „nein“ lautet, ist die Zusage des Dienstes nicht belegt. Das kostet eine halbe Stunde je Dienst und findet Lücken, die kein Restore-Test findet, weil ein Test die Abhängigkeiten in der Regel intakt vorfindet.

Kurzcheck

Ein Warenwirtschaftssystem hat eine bestätigte RTO von vier Stunden. Seine Anmeldung läuft über einen Verzeichnisdienst, für den keine RTO vereinbart ist. Was ist der belastbare nächste Schritt?

Für den Verzeichnisdienst eine eigene, kürzere RTO vereinbaren und belegen.
Die RTO des Warenwirtschaftssystems auf acht Stunden anheben.
Einen Restore-Test des Warenwirtschaftssystems ansetzen.

Treffer. Richtig. Die Kette braucht an jedem Glied eine Zusage, die kleiner ist als die des Dienstes darüber — sonst ist die obere Zusage nicht gedeckt.

Wer die Zahl akzeptiert

Eine RPO von vier Stunden bedeutet: Im Ernstfall ist die Arbeit von bis zu vier Stunden weg. Diese Aussage ist keine technische, sondern eine geschäftliche — und sie darf deshalb nicht in der IT entschieden werden.

Dienst-Eigentümer — Die Person, die für das fachliche Ergebnis eines Dienstes einsteht und deshalb den Verlust akzeptiert, den die RPO zulässt. Nicht der Betreiber der Technik, sondern der, dessen Prozess stillsteht.

In der Praxis fehlt diese Person oft, und der Betrieb füllt die Lücke stillschweigend. Das geht so lange gut, bis der Ernstfall eintritt: Dann steht die IT mit einer selbst gesetzten Zahl da, die niemand vereinbart hat, und die Diskussion über den Datenverlust findet zum denkbar schlechtesten Zeitpunkt statt.

Der kleinste wirksame SchrittEs braucht kein Gremium. Es braucht eine Zeile je Dienst mit Name, Verlustgrenze, Ausfallgrenze, Eigentümer und Datum — und eine kurze Bestätigung per E-Mail. Der Wert dieser Zeile liegt nicht in ihrer Genauigkeit, sondern darin, dass die Zahl jemandem gehört. Eine falsche Zahl mit Eigentümer wird korrigiert; eine richtige Zahl ohne Eigentümer wird bei der ersten Budgetfrage gestrichen.

Der Preis: kürzere Ziele kosten überproportional

NIST SP 800-34 stellt die Kostenabwägung als zwei gegenläufige Kurven dar: Je länger eine Störung andauert, desto teurer wird sie; je kürzer die RTO, desto teurer wird die Lösung, die sie einhält. Der sinnvolle Punkt ist der Schnittpunkt beider Kurven — und er liegt für jede Organisation und jeden Dienst woanders.

RTO in Tagen: Sicherung auf ein günstiges, langsames Medium reicht. Wiederherstellung überwiegend manuell.
RTO in Stunden: Zweite Kopie in erreichbarer Nähe, geprobter Ablauf, benannte Zuständigkeit rund um die Uhr.
RTO in Minuten: Bereitstehende Zweitumgebung, laufende Replikation, automatisierte Umschaltung — dauerhafte Kosten, auch wenn nie ein Ausfall eintritt.

Der ehrliche Umgang damit besteht darin, den Preis zu benennen, statt die kürzeste Zahl zuzusagen. Ein Fachbereich, dem man vorrechnet, dass „Minuten statt Stunden“ eine dauerhaft laufende Zweitumgebung bedeutet, entscheidet in aller Regel anders als einer, den man nur nach seinem Wunsch fragt. Und die Entscheidung ist dann seine, nicht eine stillschweigende Annahme der IT.

Die Umkehrung gilt auchZu lange Ziele sind ebenfalls eine Entscheidung mit Preis — sie sind nur billiger zu treffen und teurer zu bezahlen. Wer eine RTO von drei Tagen akzeptiert, akzeptiert damit auch, dass der Prozess drei Tage lang auf einem Ersatzverfahren läuft. Ob dieses Ersatzverfahren existiert, gehört zur selben Entscheidung.

Der Recovery-Vertrag: sechs Felder je Dienst

Alles bisher Gesagte lässt sich für einen Dienst in sechs Feldern festhalten. Sie sind die kleinste Form, in der die Zusage überhaupt prüfbar wird — und sie sind der Bezugspunkt für jedes weitere Modul dieses Tracks.

Dienst und Eigentümer: Welcher fachliche Dienst, und wer steht für sein Ergebnis ein.
MTD: Die gesamte tolerierbare Ausfallzeit aus Sicht des Prozesses.
RTO: Der technische Teil davon, abzüglich der geschätzten Nachverarbeitung.
RPO: Die tolerierte Datenlücke — abgeglichen mit dem tatsächlichen Sicherungsrhythmus.
Umfang: Daten, Konfiguration, Identitäten, Schlüssel, Namen, Lizenzen, Katalog.
Abhängigkeiten: Die Kette darunter, mit je eigener, kleinerer Zusage.

Was diese sechs Felder nicht sindSie sind kein Nachweis. Sie beschreiben, was gelten soll — nicht, dass es gilt. Der Nachweis entsteht erst durch einen gemessenen Restore, und genau dort trennt sich das Konzept vom Wunsch. Ein vollständig ausgefüllter Vertrag ohne einen einzigen gemessenen Restore ist eine sauber formulierte Behauptung.

Was dieses Modul nicht entscheidet

Bewusst offen bleibt hier alles, was ein Werkzeug betrifft. Welches Medium, welche Kopienzahl, welche Aufbewahrungsregel, welche Absicherung gegen Verschlüsselungsangriffe — all das folgt aus den Zahlen dieses Moduls und wird in den nächsten Modulen entschieden.

Inventar und Schutzklassen — wie aus einer Serverliste eine Liste von Diensten mit Eigentümern wird.
Schutzdesign und Fehlerdomänen — wie viele voneinander unabhängige Kopien es braucht und wogegen sie schützen.
Recovery-Architektur und Medien — welches Verfahren die gerechneten Ziele überhaupt einhalten kann.
Restores nachweisen — wie aus der Zusage ein gemessener Beleg wird.

Abgrenzung zu den NachbartracksPlattformspezifische Wiederherstellung steht bewusst woanders: windows-server-administration behandelt die Werkzeuge auf dem Windows-Server selbst, active-directory die Besonderheiten eines Verzeichnisdienstes, storage-file-services Replikation und Dateidienste. Dieser Track liefert die Disziplin darüber — die Entscheidungen, die unabhängig vom Produkt gleich bleiben.

Jetzt anwenden

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

Zum Modul →

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