Backup & Storage

RPO und RTO

Overview

Recovery Point Objective (RPO) und Recovery Time Objective (RTO) sind die zwei zentralen Zielgrößen jeder Backup- und Notfallplanung. Microsoft definiert das RPO als die maximal akzeptable Dauer an Datenverlust im Katastrophenfall (z. B. „vier Stunden Daten“) und das RTO als die maximal akzeptable Ausfallzeit (z. B. „acht Stunden Ausfall“).

Beide Werte werden nicht von der IT festgelegt, sondern aus den Geschäftsanforderungen abgeleitet, typischerweise in einer Business-Impact-Analyse. Die IT übersetzt sie anschließend in Technik: Das RPO bestimmt die Sicherungshäufigkeit oder Replikation, das RTO die Wiederherstellungsarchitektur (Instant Recovery, Standby-Systeme, Ersatzhardware).

Abgrenzung: Disaster Recovery und Business Continuity beschreiben die Prozesse und Pläne, RPO und RTO sind die messbaren Ziele darin. Für die Gesamtplanung gibt es eigene Glossareinträge.

How it works

So werden die Kennzahlen praktisch ermittelt und umgesetzt:

  1. Systeme und Prozesse erfassen und nach Kritikalität einstufen (z. B. ERP, Mail, Fileserver, Fertigungssteuerung).
  2. Mit den Fachbereichen klären, wie lange ein Ausfall tragbar ist (RTO) und wie viel Arbeit nachträglich wiederholt werden kann (RPO).
  3. Technik zuordnen: RPO 24 Stunden lässt sich mit nächtlicher Sicherung erreichen, RPO 15 Minuten erfordert Protokollsicherungen oder Replikation, RPO nahe null eine synchrone Spiegelung oder Continuous Data Protection.
  4. RTO technisch absichern: Restore-Geschwindigkeit des Repositories, verfügbare Ersatzhardware, Instant Recovery oder replizierte Standby-VMs.
  5. In Wiederherstellungstests messen, ob die Ziele tatsächlich erreicht werden, und Abweichungen dokumentieren.

Benefits

  • Klare Grundlage für Investitionsentscheidungen, weil sich Technik und Kosten gegen messbare Ziele abwägen lassen.
  • Gemeinsame Sprache zwischen Geschäftsführung und IT, da Ausfallzeit und Datenverlust in Stunden statt in Technikbegriffen verhandelt werden.
  • Prüfbarkeit, denn Restore-Tests zeigen direkt, ob ein System seine Ziele einhält.
  • Priorisierung im Ernstfall: Die Reihenfolge der Wiederherstellung ergibt sich aus den RTO-Werten.

Practical example

Ein Automobilzulieferer mit 300 Mitarbeitenden legt in einer Business-Impact-Analyse fest: Die Fertigungssteuerung braucht RTO 4 Stunden und RPO 15 Minuten, der Fileserver RTO 24 Stunden und RPO 24 Stunden. Für die Fertigungssteuerung richtet die IT eine Replikation auf einen zweiten Hyper-V-Host ein, der Fileserver bleibt bei der nächtlichen Sicherung. Ein Test-Failover zeigt, dass die Steuerung nach 40 Minuten wieder produktiv ist.

Things to keep in mind

  • Lass RPO und RTO von der Geschäftsführung bestätigen, damit die IT im Ernstfall nicht an Zielen gemessen wird, die nie budgetiert wurden.
  • Ziele von null Minuten für beide Werte sind laut Microsoft schwierig und teuer umzusetzen: Lege realistische Werte pro System fest.
  • Berücksichtige Abhängigkeiten: Ein ERP mit RTO 4 Stunden nützt nichts, wenn Active Directory oder DNS erst nach 8 Stunden zurück sind.
  • Miss die Werte im Restore-Test unter realistischen Bedingungen, inklusive Hardwarebeschaffung und Anmeldung der Benutzer.

Conclusion

RPO und RTO sind die Messlatte, an der sich jede Backup- und DR-Architektur messen lassen muss. Leg sie zuerst fest und wähle danach die Technik, nicht umgekehrt.

Further reading

Related articles