Loading content
Das Recovery Time Objective (RTO) legt die maximal tolerierbare Dauer fest, innerhalb derer ein IT-Service nach einem Ausfall wiederhergestellt sein muss, um geschäftliche Schäden zu begrenzen. Es dient als Planungsgröße für Backup-, Wiederherstellungs- und Betriebsprozesse und beeinflusst Architektur- sowie Betriebsentscheidungen. Es ist priorisierbar nach…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Das Recovery Time Objective (RTO) legt fest, wie schnell ein Dienst oder Geschäftsprozess nach einer Störung wieder verfügbar sein muss.
RTO entstand in Business-Continuity- und Disaster-Recovery-Planung als zeitliche Übersetzung der maximal akzeptablen Unterbrechung eines Geschäftsprozesses.
Ein RTO von zwei Stunden bedeutet: Der Dienst muss innerhalb dieser Frist wieder in einem vereinbarten nutzbaren Zustand sein. Das beeinflusst Bereitschaft, Redundanz, Wiederanlaufautomatisierung und Übungen. RTO misst Wiederherstellungsdauer, nicht den Umfang verlorener Daten; dieser wird mit dem RPO festgelegt.
Die maximale tolerierbare Unterbrechungsdauer wird als konkretes Ziel festgelegt.
Das Ziel definiert, wann der Dienst wieder ausreichend funktionsfähig und nicht nur gestartet ist.
Technik, Rollen und Verfahren werden entworfen und getestet, damit die Zeitgrenze erreichbar ist.
RTO priorisiert Wiederanlaufinvestitionen nach geschäftlicher Auswirkung und macht Verfügbarkeitsversprechen prüfbar. Ein RTO ersetzt keine Abhängigkeitenanalyse und muss mit RPO und tatsächlichen Tests zusammenpassen.
Wo dieser Baustein im Themenmodell verortet ist.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.