RTO – Recovery Time Objective
Abkürzung: RTO
Die Recovery Time Objective (RTO) gibt an, wie viel Zeit nach einem Ausfall höchstens vergehen darf, bis ein System oder Geschäftsprozess wieder arbeitet. Ein RTO von vier Stunden heißt: Fällt das System um 10 Uhr aus, muss es spätestens um 14 Uhr wieder verfügbar sein. Auf Deutsch spricht man vom Wiederanlaufziel oder der geplanten Wiederanlaufzeit.
Die RTO ist ein Ziel, kein Messwert. Sie wird festgelegt, bevor etwas passiert, und bestimmt, wie aufwendig die technische Lösung sein muss. Ob sie erreicht wird, zeigt erst ein Test oder der Ernstfall.
RTO und RPO
RTO wird fast immer zusammen mit der Recovery Point Objective (RPO) genannt. Beide beschreiben verschiedene Richtungen auf der Zeitachse:
| Recovery Point Objective | Recovery Time Objective | |
|---|---|---|
| Frage | Wie viele Daten dürfen verloren gehen? | Wie lange darf der Ausfall dauern? |
| Richtung | zurück vom Ausfall zur letzten Sicherung | vor vom Ausfall bis zum Wiederanlauf |
| Bestimmt | wie oft gesichert oder gespiegelt wird | wie schnell wiederhergestellt werden kann |
| Beispiel | höchstens 15 Minuten Datenverlust | spätestens 4 Stunden bis zum Wiederanlauf |
Ein System kann eine kurze RTO und eine lange RPO haben oder umgekehrt. Ein Webshop braucht oft beides kurz. Ein Archivsystem darf tagelang stehen, aber keine Daten verlieren.
Woher der Wert kommt
Die RTO ist eine geschäftliche Entscheidung, keine technische. Grundlage ist eine Business Impact Analyse: Was kostet eine Stunde Ausfall, ab wann drohen Vertragsstrafen, verlorene Kunden oder Verstöße gegen Vorschriften?
Darüber steht die maximal tolerierbare Ausfallzeit (MTA, englisch Maximum Tolerable Period of Disruption, MTPD). Sie beschreibt, ab wann ein Ausfall nicht mehr hinnehmbar ist. Die RTO muss deutlich darunter liegen, damit Zeit für Unvorhergesehenes bleibt.
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| Maximal tolerierbare Ausfallzeit | fachliche Grenze, ab der der Schaden untragbar wird | 24 Stunden |
| Recovery Time Objective | geplantes Ziel für den Wiederanlauf | 8 Stunden |
| Tatsächliche Wiederanlaufzeit | im Test oder Ernstfall gemessen | 6 Stunden |
Was die RTO technisch verlangt
| RTO | Typische Lösung |
|---|---|
| Tage | Wiederherstellung aus der Datensicherung auf neuer Hardware |
| Stunden | Ersatzsysteme stehen bereit, Daten werden aus der Sicherung zurückgespielt |
| Minuten | zweiter Standort mit laufenden Systemen und gespiegelten Daten, automatische Umschaltung |
| nahe null | aktiver Betrieb an zwei Standorten gleichzeitig (Hochverfügbarkeit) |
Je kürzer die RTO, desto teurer. Der Sprung von Stunden auf Minuten bedeutet meist einen zweiten Standort, der ständig mitläuft.
Was die RTO verlängert
Die Zeit für den Wiederanlauf umfasst mehr als das Einspielen der Daten:
- bis der Ausfall erkannt und die Entscheidung zum Umschalten gefallen ist
- bis Hardware, Lizenzen und Zugänge bereitstehen
- die Wiederherstellung selbst, abhängig von Datenmenge und Leitungsbandbreite
- die Prüfung, ob die wiederhergestellten Daten vollständig und konsistent sind
- Abhängigkeiten: Eine Anwendung läuft erst, wenn Datenbank, Verzeichnisdienst und Netz wieder da sind
Nach einem Ransomware-Angriff kommt hinzu, dass erst geklärt werden muss, welche Sicherung sauber ist. Die tatsächliche Wiederanlaufzeit liegt dann oft bei Tagen bis Wochen, auch wenn die geplante RTO Stunden betrug.
Im Rechenzentrum
Für Rechenzentren und IT-Dienstleister taucht die RTO in Verträgen und Ausschreibungen auf. Wichtig ist, worauf sie sich bezieht: auf die Infrastruktur des Rechenzentrums, auf einen einzelnen Dienst oder auf die gesamte Anwendung des Kunden. Ein Colocation-Anbieter kann zusagen, wie schnell Strom und Kühlung nach einer Störung zurück sind. Wann die Anwendung des Kunden wieder läuft, liegt bei dessen eigener Planung.
Normen
- BSI-Standard 200-4: Business Continuity Management
- ISO 22301: Business Continuity Management Systems