RAllgemein

RTO / RPO

Zielwerte für Wiederanlaufzeit (RTO) und Datenverlust (RPO).

RTO (Recovery Time Objective) und RPO (Recovery Point Objective) sind Zielwerte, die festlegen, wie schnell ein IT-System nach einem Ausfall wieder laufen muss (RTO) und wie viel Datenverlust maximal akzeptabel ist (RPO). Sie sind Kernbegriffe der Notfallvorsorge (Backup/Disaster Recovery) und helfen Geschäftsführern, Risiken, Kosten und Schutzmaßnahmen realistisch auszubalancieren.

Was bedeutet RTO / RPO?

  • RTO (Wiederanlaufzeit): Maximale tolerierbare Zeitspanne, bis ein Service nach einer Störung wieder verfügbar sein muss. Beispiel: „E-Mail muss innerhalb von 4 Stunden wieder funktionieren.“
  • RPO (Datenverlust-Ziel): Maximale tolerierbare Datenmenge bzw. Zeitspanne an Daten, die im Ernstfall verloren gehen darf. Beispiel: „Wir dürfen höchstens 15 Minuten Daten verlieren“ (entspricht i.d.R. Backups/Replikation alle 15 Minuten).

Wie funktioniert die Festlegung in der Praxis?

RTO und RPO werden nicht „aus dem Bauch“ entschieden, sondern aus Geschäftsanforderungen abgeleitet: Welche Prozesse hängen an einem System, wie teuer ist Stillstand pro Stunde, und welche regulatorischen/vertraglichen Anforderungen existieren? Typisch ist eine Einordnung nach Kritikalität (z. B. „kritisch“, „wichtig“, „nice-to-have“).

  • Schritt 1: Systeme & Prozesse inventarisieren (z. B. ERP, Buchhaltung, Fileserver, Webshop).
  • Schritt 2: Auswirkungen bewerten (Umsatzverlust, Produktionsstopp, Reputationsschaden, Vertragsstrafen).
  • Schritt 3: Zielwerte definieren (RTO/RPO je System, nicht „one size fits all“).
  • Schritt 4: Maßnahmen ableiten (Backup-Frequenz, Offsite-Backup, Cloud-Failover, Redundanz, Notfall-Handbuch).
  • Schritt 5: Testen & verbessern (Restore-Tests, Notfallübungen, Monitoring).

Warum sind RTO und RPO wichtig – gerade für kleine Unternehmen?

Viele kleine Unternehmen sichern zwar Daten, aber ohne klare Zielwerte. Das führt zu einer gefährlichen Lücke: Im Ernstfall stellt sich erst dann heraus, dass ein Restore zu lange dauert (RTO verfehlt) oder dass zu viele Daten seit dem letzten Backup fehlen (RPO verfehlt). RTO/RPO schaffen eine gemeinsame Sprache zwischen Geschäftsführung und IT: Sie übersetzen „Sicherheit“ in messbare Ziele und machen Entscheidungen über Budget und Architektur nachvollziehbar.

Konkrete Beispiele (leicht greifbar)

  • Webshop: RTO 1 Stunde, RPO 5 Minuten → eher Replikation/hochfrequente Sicherung, ggf. automatisches Failover.
  • Buchhaltung: RTO 24 Stunden, RPO 8 Stunden → tägliche Backups können reichen, Restore darf länger dauern.
  • Dateiserver/Projektablage: RTO 8 Stunden, RPO 1 Stunde → stündliche Snapshots + regelmäßige Restore-Tests.

Was kostet es, bestimmte RTO/RPO zu erreichen?

Je kleiner RTO und RPO, desto teurer wird es typischerweise: häufigere Backups, zusätzliche Infrastruktur, zweite Standorte/Cloud-Regionen, Automatisierung und Tests. Ein „RPO nahe 0“ (nahezu kein Datenverlust) erfordert meist kontinuierliche Replikation; ein sehr kleines RTO erfordert oft vorkonfigurierte Ausweichumgebungen. Die Kunst ist, nur für wirklich kritische Systeme „Premium“-Ziele zu setzen und für den Rest pragmatische Werte zu wählen.

Merksatz: RTO ist „Wie lange dürfen wir ausfallen?“, RPO ist „Wie viel dürfen wir verlieren?“. Zusammen bilden sie die Grundlage für ein belastbares Backup- und Wiederanlaufkonzept.