Das RTO beschreibt, wie schnell ein System nach einer Störung wieder verfügbar sein soll.
Das RTO beschreibt, wie schnell ein System nach einer Störung wieder verfügbar sein soll.
Das Recovery Time Objective beschreibt die angestrebte maximale Zeit, bis ein System oder Geschäftsprozess nach einer Störung wieder nutzbar sein soll. Es hilft der Geschäftsführung zu entscheiden, welcher Ausfall nur unangenehm und welcher bereits existenzbedrohend wäre.
RTO betrifft die Dauer des Wiederanlaufs. RPO legt fest, wie aktuell der wiederhergestellte Datenstand sein muss. Für ein sinnvolles Notfallkonzept werden beide Werte je Anwendung festgelegt und mit den tatsächlich verfügbaren Sicherungen und Ressourcen abgeglichen.
Eine Fachanwendung muss innerhalb von vier Stunden wieder verfügbar sein, weil danach wesentliche Abläufe stillstehen. Eine interne Wissenssammlung darf dagegen bis zum nächsten Arbeitstag ausfallen. Dadurch können Ersatztechnik und Arbeitszeit dort priorisiert werden, wo sie den größten Nutzen bringen.
Unternehmen sollten Abhängigkeiten betrachten: Eine Anwendung kann erst starten, wenn Netzwerk, Identitätsdienst, Datenbank und Speicher funktionieren. Anschließend werden Systeme in eine nachvollziehbare Reihenfolge gebracht und Verantwortliche sowie Kontaktwege für den Ernstfall festgehalten.
Ersatzhardware, Virtualisierung, Cloud-Dienste, Bandbreite, Dokumentation und die Erfahrung mit der Wiederherstellung wirken direkt auf das RTO. Auch die Zeit bis zur Erkennung und Entscheidung gehört zum realen Ablauf. Regelmäßige Tests zeigen, ob das gewünschte Ziel tatsächlich erreichbar ist.
Für jedes System dieselbe kurze Wiederanlaufzeit zu verlangen ist meist unnötig teuer. Ebenso gefährlich ist ein Ziel, das nur auf dem Papier existiert. Fehlende Zugänge, unbekannte Abhängigkeiten oder nie getestete Backups können einen theoretisch schnellen Wiederanlauf erheblich verzögern.
