Backup-Gespräche verlaufen oft technisch: Speichergrößen, Zeitpläne, Medien. Produktiver wird es, wenn zwei einfache Fragen zuerst beantwortet werden. Erstens: Wie lange darf ein System nach einem Ausfall stillstehen – diese Zeit ist die Recovery Time Objective, kurz RTO. Zweitens: Welchen Zeitraum an Arbeit darf das Unternehmen im schlimmsten Fall verlieren – das ist die Recovery Point Objective, RPO.
Beide Werte beschreiben Zeiträume, aber in entgegengesetzte Richtungen. Die RPO blickt vom Ausfall zurück: Sie legt fest, wie alt die letzte brauchbare Sicherung höchstens sein darf, und bestimmt damit, wie oft gesichert werden muss. Die RTO blickt nach vorn: Sie legt fest, bis wann der Betrieb wieder laufen muss, und bestimmt damit, wie die Wiederherstellung technisch und organisatorisch vorbereitet sein muss.
Im Business Continuity Management nach BSI-Standard 200-4 begegnet die RTO als Wiederanlaufzeit, kurz WAZ – die Zeit, in der zumindest ein Notbetrieb wieder aufgenommen sein soll. Darüber steht die maximal tolerierbare Ausfallzeit (MTA): der Zeitpunkt, bis zu dem ein Prozess spätestens wieder anlaufen muss, damit die Überlebensfähigkeit des Unternehmens nicht gefährdet ist. Die geplante Wiederanlaufzeit muss innerhalb dieser Grenze liegen, sonst ist der Plan schon auf dem Papier gescheitert.
Warum die Antworten selten „null“ lauten
Theoretisch wünscht sich jedes Unternehmen beides bei null. Praktisch kostet jede Annäherung an null Geld: Eine RPO von wenigen Minuten verlangt kontinuierliche Replikation, eine RTO von Minuten verlangt bereitstehende Ersatzsysteme. Deshalb werden beide Werte pro System festgelegt – die Warenwirtschaft verdient andere Werte als das Archiv der Weihnachtsfotos.
In fünf Schritten zu belastbaren Werten
- Vom Prozess her denken, nicht vom Server: Welche Abläufe tragen das Geschäft – Auftragsannahme, Produktion, Versand, Buchhaltung, Lohnabrechnung?
- Folgen in Zeitstufen bewerten: Was geschieht nach vier Stunden, nach einem Tag, nach drei Tagen, nach einer Woche? Umsatzausfall, Vertragsstrafen, versäumte Fristen und das Vertrauen der Kunden gehören gleichermaßen in die Bewertung.
- Abhängigkeiten offenlegen: Die Warenwirtschaft läuft nur, wenn auch Datenbank, Verzeichnisdienst, Namensauflösung, Lizenzserver und Internetanbindung verfügbar sind. Ein Prozess kann nie schneller wieder anlaufen als sein langsamster Baustein.
- Datenverlust unterscheiden: Lässt sich verlorene Arbeit aus Papierbelegen oder E-Mails rekonstruieren, oder ist sie unwiederbringlich fort, wie Messwerte, Konstruktionsstände oder telefonisch angenommene Aufträge?
- Werte verabschieden: Fachbereiche und Geschäftsführung legen die Werte fest, die IT beziffert Aufwand und Machbarkeit. Das Ergebnis wird schriftlich festgehalten und jährlich überprüft.
Ein Rechenbeispiel
Die folgenden Zahlen sind frei gewählte Annahmen und dienen nur der Veranschaulichung. In der Auftragserfassung arbeiten zwölf Personen, gesichert wird einmal täglich um 22 Uhr. Fällt das System am späten Nachmittag aus, fehlt im ungünstigsten Fall die Arbeit fast eines ganzen Tages: bis zu zwölf Personentage Nacherfassung – sofern sich die Vorgänge überhaupt rekonstruieren lassen. Wird stattdessen alle zwei Stunden gesichert, schrumpft der mögliche Verlust auf höchstens zwei Stunden Arbeit je Person.
Für die Wiederherstellung sei angenommen, dass 2 TB Daten mit effektiv 200 MB pro Sekunde zurückgespielt werden. Rein rechnerisch dauert das 10.000 Sekunden, also knapp drei Stunden. Hinzu kommen jedoch das Erkennen des Ausfalls, die Entscheidung zur Wiederherstellung, das Bereitstellen der Hardware, die Prüfung der Daten und die Freigabe für die Nutzer. Wer eine RTO von vier Stunden festlegt, aber keinen Ersatzserver vorhält, verfehlt sie bereits dann, wenn die Hardware erst bestellt werden muss.
Nach einem Verschlüsselungsangriff verlängert sich die Kette zusätzlich. Bevor zurückgespielt werden kann, muss geklärt sein, wie die Angreifer eingedrungen sind, welcher Sicherungsstand noch sauber ist und welche Zugangsdaten erneuert werden müssen. Eine RTO, die nur für den Hardwaredefekt geplant wurde, ist für diesen Fall zu optimistisch; sinnvoll ist, beide Szenarien getrennt zu betrachten.
Von der Zahl zur Architektur
- RPO 24 Stunden: klassische tägliche Sicherung genügt.
- RPO wenige Stunden: mehrfach tägliche Sicherungen oder Journalführung.
- RPO nahe null: Replikation auf ein zweites System, idealerweise an einem zweiten Standort.
- RTO Stunden statt Tage: Ersatzsysteme vorhalten oder Wiederherstellung in eine Cloud-Umgebung vorbereiten.
In der Praxis bewährt sich eine Einteilung in wenige Klassen, statt jedem System eigene Werte zu geben. Eine erste Klasse umfasst die Systeme, ohne die das Unternehmen binnen Stunden handlungsunfähig wird; eine zweite jene, auf die einige Tage verzichtet werden kann; eine dritte alles, was auch eine Woche warten darf. So bleibt die Übersicht handhabbar, und die Ausgaben konzentrieren sich dort, wo sie das größte Risiko verringern.
Zwei Fehler begegnen dabei regelmäßig. Der erste: Werte werden festgelegt, aber nie überprüft. Ob eine RTO von acht Stunden erreichbar ist, zeigt erst eine gemessene Wiederherstellung – alles andere bleibt Schätzung. Der zweite: Die RPO wird mit dem Sicherungsintervall gleichgesetzt, ohne die Übertragung außer Haus mitzudenken. Wird nachts lokal gesichert, aber erst am Wochenende an einen zweiten Standort übertragen, liegt die RPO für den Fall eines Brandes nicht bei einem Tag, sondern bei bis zu einer Woche.
Der eigentliche Gewinn dieser Übung ist die gemeinsame Sprache: Geschäftsführung und IT diskutieren nicht mehr über Bandlaufwerke, sondern über akzeptierte Risiken – und über die Kosten, sie zu verringern. Diese Abwägung gehört in die Hand der Geschäftsführung, denn nur sie kann entscheiden, welches Restrisiko das Unternehmen bewusst tragen will.
Verwandte Themen: Wer hier weiterdenkt, liest bei Backup-Strategie, Cloud-Backup Anbieter und Microsoft 365 Backup weiter.
