RTO und RPO: Welche Recovery-Ziele Ihre Infrastruktur wirklich braucht
Für Business Continuity, Disaster Recovery und NIS2-nahe Resilienz
RTO beschreibt, wie schnell ein System nach einem Ausfall wieder laufen muss. RPO beschreibt, wie viele Daten maximal verloren gehen dürfen.
Erst wenn RTO und RPO pro Anwendung definiert sind, lässt sich entscheiden, ob Backup, HA-Cluster, Disaster Recovery oder echte Fehlertoleranz die richtige Schutzklasse ist.
Der Unterschied in einem Satz
RTO fragt: Wie lange darf es dauern? RPO fragt: Wie viel darf fehlen? Beide Werte sind keine IT-Wunschzahlen, sondern Business-Entscheidungen. Die Fachbereiche müssen sagen, wann ein Ausfall kritisch wird; die IT muss zeigen, welche Architektur diese Ziele realistisch erreicht.
Ein Backup kann ein gutes RPO liefern, aber ein schlechtes RTO. Ein HA-Cluster kann ein gutes RTO liefern, aber beim Failover trotzdem Daten im Arbeitsspeicher verlieren. Fehlertoleranz ist dann relevant, wenn beides extrem niedrig sein muss.
Beispiele für RTO und RPO im Mittelstand
| System | Typisches RTO | Typisches RPO | Auswirkung |
|---|---|---|---|
| ERP / Warenwirtschaft | 30-60 Minuten | 0-15 Minuten | Aufträge, Lagerbewegungen und Abrechnung geraten ins Stocken. |
| Produktionssteuerung | 0-15 Minuten | 0 Minuten | Stillstand wirkt sofort auf Maschinen, Schichten und Liefertermine. |
| Dokumentenmanagement | 30-120 Minuten | 15-60 Minuten | Freigaben, Verträge, Personal- und Rechnungsprozesse verzögern sich. |
| E-Mail / Kollaboration | 2-8 Stunden | 1-4 Stunden | Kommunikation leidet, ist aber oft temporär durch Ersatzwege möglich. |
Richtwerte zur Planung. Die tatsächlichen Ziele müssen je Unternehmen über Prozess- und Ausfallkosten bestimmt werden.
Von Recovery-Zielen zur Architektur
RTO liegt bei 0-15 Minuten
HA-Cluster kann zu langsam sein; Fehlertoleranz prüfen.
RPO liegt bei 0 Minuten
Backup allein reicht nicht; synchrone Replikation oder FT nötig.
Ausfall betrifft Kunden oder Produktion sofort
Kosten pro Minute berechnen und Schutzklasse erhöhen.
Wiederherstellung wurde nie getestet
RTO/RPO sind Annahmen, keine belastbaren Ziele.
So geht Diventus vor
- Kritische Anwendungen und Abhängigkeiten identifizieren.
- Ausfallkosten mit dem Fachbereich schätzen.
- RTO und RPO pro Anwendung festlegen.
- Ist-Zustand gegen die Ziele prüfen: Server, Internet, Backup, Monitoring.
- Schutzklasse wählen: Backup, HA, Disaster Recovery oder Fehlertoleranz.