RPO und RTO
RPO und RTO sind die beiden Kennzahlen der Notfall- und Wiederherstellungsplanung. Der RPO (Recovery Point Objective) legt fest, wie viel Datenverlust ein Unternehmen maximal verkraften kann, der RTO (Recovery Time Objective), wie lange ein System wie das ERP nach einem Ausfall höchstens stillstehen darf, bis es wieder produktiv läuft.
RPO und RTO sind zwei Zielgrößen, mit denen Unternehmen festlegen, wie robust ihre IT-Systeme gegen Ausfälle abgesichert sein müssen. Der Recovery Point Objective (RPO) beantwortet die Frage „Wie viel Datenverlust ist maximal hinnehmbar?“ und beschreibt damit den zulässigen Zeitraum zwischen der letzten verwertbaren Datensicherung und dem Ausfall. Der Recovery Time Objective (RTO) beantwortet die Frage „Wie lange darf ein System höchstens stillstehen?“ und legt die maximal tolerierbare Ausfalldauer bis zur Wiederherstellung fest. Beide Werte werden in Zeiteinheiten angegeben – von Sekunden über Stunden bis zu ganzen Tagen.
Anders als ein Backup oder ein Wiederherstellungsverfahren sind RPO und RTO keine Technik, sondern betriebswirtschaftliche Vorgaben: Sie sagen, wie schlimm ein Ausfall aus Geschäftssicht sein darf, und leiten daraus ab, welche technischen Maßnahmen nötig sind. Für ein ERP-System, in dem Aufträge, Bestände, Rechnungen und Buchhaltung zusammenlaufen, sind sie besonders relevant – hier kostet jede Stunde Stillstand und jeder verlorene Datensatz unmittelbar Geld und Vertrauen. RPO und RTO übersetzen dieses Risiko in messbare, prüfbare und vertraglich zusicherbare Zahlen.
Auf einen Blick
- RPO = maximal tolerierbarer Datenverlust (wie alt darf der letzte gesicherte Stand sein)
- RTO = maximal tolerierbare Ausfalldauer (wie lange darf das System stillstehen)
- RPO steuert die Backup-/Replikationshäufigkeit, RTO die Wiederanlauf-Technik
- Beide Werte sind Geschäftsvorgaben, keine Technik – je kürzer, desto teurer die Absicherung
- Bei Cloud-/SaaS-ERP stehen RPO und RTO im SLA und sollten vor Vertragsschluss geprüft werden
Was bedeuten RPO und RTO genau?
RPO und RTO messen zwei unterschiedliche Dimensionen desselben Ausfalls: Der RPO blickt zurück in die Vergangenheit und misst verlorene Daten, der RTO blickt nach vorn und misst verlorene Zeit. Beide werden pro System oder Prozess einzeln festgelegt, denn nicht alles ist gleich kritisch. Ein Ausgangspunkt für beide Werte ist die Business-Impact-Analyse, die für jeden Geschäftsprozess abschätzt, welcher Schaden pro Stunde Stillstand und pro verlorener Datenmenge entsteht.
RPO – der maximal tolerierbare Datenverlust
Der Recovery Point Objective bezeichnet den Zeitpunkt, auf den ein System nach einem Ausfall zurückgesetzt werden kann, ohne dass der Schaden inakzeptabel wird. Ein RPO von einer Stunde bedeutet: Im schlimmsten Fall gehen die Daten der letzten Stunde vor dem Ausfall verloren. Damit gibt der RPO direkt die minimale Sicherungshäufigkeit vor – ein RPO von einer Stunde erfordert mindestens stündliche Sicherungen, ein RPO nahe null verlangt kontinuierliche Replikation. Je näher der RPO an null rückt, desto aufwendiger und teurer wird die Technik.
RTO – die maximal tolerierbare Ausfalldauer
Der Recovery Time Objective legt fest, wie viel Zeit zwischen dem Ausfall und der Wiederherstellung des produktiven Betriebs höchstens vergehen darf. Ein RTO von vier Stunden heißt: Vier Stunden nach dem Ausfall muss das ERP wieder nutzbar sein. Der RTO umfasst den gesamten Weg zurück – Fehlererkennung, Bereitstellung der Zielumgebung, Einspielen des Datenstands, Start und Prüfung. Kurze RTO-Werte verlangen vorgehaltene Ausweichsysteme oder automatisches Umschalten (Failover), lange RTO-Werte kommen mit einfachem Wiederherstellen aus dem Backup aus.
Wie RPO und RTO zusammenspielen und was sie kosten
RPO und RTO werden zwar getrennt festgelegt, hängen aber wirtschaftlich eng zusammen: Beide treiben die Kosten der Absicherung, und je strenger die Vorgaben, desto höher der Aufwand. Ein sehr kurzer RPO erfordert häufige oder kontinuierliche Datenspiegelung, ein sehr kurzer RTO eine ständig bereitstehende Zweitumgebung. In der Praxis staffeln Unternehmen ihre Systeme deshalb in Klassen (Tiers): geschäftskritische Systeme wie das ERP bekommen niedrige Werte, weniger wichtige Systeme höhere.
Wichtig ist der Unterschied zwischen Zielwert und Ist-Wert. RPO und RTO sind Vorgaben – was tatsächlich erreicht wird, zeigt erst der Ernstfall oder ein Test. Die real gemessene Wiederanlaufzeit wird manchmal als Recovery Time Actual (RTA) bezeichnet. Liegt die RTA regelmäßig über dem vereinbarten RTO, ist die Absicherung unterdimensioniert. Deshalb gehören zu jeder ernsthaften Planung dokumentierte Tests, bei denen der Wiederanlauf durchgespielt und die Zeit gestoppt wird.
Abgrenzung zu MTD und WRT
Rund um RPO und RTO existieren weitere Kennzahlen. Die Maximum Tolerable Downtime (MTD) beschreibt die absolute Obergrenze, ab der ein Ausfall existenzbedrohend wird; der RTO muss stets kleiner sein als die MTD. Die Work Recovery Time (WRT) ist die Zeit, die nach dem technischen Wiederanlauf noch nötig ist, um Daten zu prüfen und nachzupflegen, bis der Normalbetrieb wirklich steht. Vereinfacht gilt: MTD = RTO + WRT. Wer nur den RTO plant und die Nacharbeit vergisst, unterschätzt die tatsächliche Ausfalldauer.
RPO und RTO im ERP-System
Im ERP-Umfeld sind RPO und RTO besonders anspruchsvoll, weil das System selten allein steht: An das ERP sind Shops, Marktplätze, Versanddienstleister, Zahlungsanbieter und die Buchhaltung über Schnittstellen angebunden. Ein niedriger RPO betrifft deshalb nicht nur die ERP-Datenbank, sondern auch die Frage, wie Bestellungen, Bestandsbuchungen und Zahlungseingänge, die während des Ausfalls anfielen, nach der Wiederherstellung sauber nachgezogen werden. Ein zu großzügiger RPO kann hier zu Überverkäufen oder doppelten Buchungen führen.
Wie sich die Zielwerte umsetzen lassen, hängt stark vom Betriebsmodell ab. Bei einem Cloud- bzw. SaaS-ERP betreibt der Anbieter die Infrastruktur und sichert RPO und RTO im Service-Level-Agreement zu – oft mit georedundanten Rechenzentren und automatischen Sicherungen. Kunden sollten diese Werte vor Vertragsschluss ausdrücklich erfragen, denn „hochverfügbar“ allein sagt nichts über den garantierten Datenstand aus. Bei einem On-Premise-ERP legt das Unternehmen RPO und RTO selbst fest und muss Sicherung, Ausweichumgebung und Tests eigenständig organisieren.
DACH-Besonderheiten: DSGVO, Aufbewahrung und Nachweis
Im deutschsprachigen Raum sind RPO und RTO nicht nur betriebswirtschaftlich, sondern auch rechtlich relevant. Artikel 32 der DSGVO verlangt die Fähigkeit, „die Verfügbarkeit und den Zugang zu personenbezogenen Daten bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen“ – das setzt voraus, dass ein Unternehmen überhaupt definierte Wiederanlaufziele hat. Angemessene RPO- und RTO-Werte sind damit Teil der geforderten technischen und organisatorischen Maßnahmen.
Hinzu kommen die steuerlichen Aufbewahrungs- und GoBD-Pflichten: Buchungsrelevante ERP-Daten müssen über viele Jahre revisionssicher und wiederherstellbar bleiben. Ein niedriger RPO schützt dabei den aktuellen Betrieb, während die Langzeitarchivierung den gesetzlichen Nachweis sichert – beides gehört in ein durchdachtes Konzept. Wer den Betrieb an einen Cloud-Anbieter auslagert, bleibt datenschutzrechtlich verantwortlich und sollte neben RPO und RTO auch Serverstandort, Zertifizierung (etwa ISO 27001) und die vertraglich zugesicherten Fristen dokumentieren. Eine belastbare, getestete RPO-/RTO-Planung ist so zugleich Teil der Sorgfalts- und Nachweispflichten.
Praxisbeispiel
Beispiel: RPO und RTO für ein Handelsunternehmen
Ein Großhändler mit rund 1.200 Aufträgen pro Tag betreibt sein ERP als Cloud-Lösung. In der Business-Impact-Analyse rechnet das Unternehmen aus, dass jede Stunde ERP-Stillstand etwa 4.000 Euro entgangenen Umsatz und Zusatzaufwand kostet und dass ein Verlust von mehr als 15 Minuten Auftragsdaten die Bestandssynchronisation mit dem Onlineshop ernsthaft gefährdet. Daraus leitet es einen RPO von 15 Minuten und einen RTO von zwei Stunden für das ERP ab.
Mit diesen Zahlen geht der Händler in die Anbieterauswahl. Ein System, das nur tägliche Backups und einen RTO von acht Stunden zusichert, fällt heraus – der mögliche Datenverlust und die Ausfalldauer wären zu groß. Gewählt wird ein Anbieter mit kontinuierlicher Replikation (RPO wenige Minuten) und georedundantem Failover (RTO unter einer Stunde), dessen SLA diese Werte vertraglich garantiert. Ein jährlicher Wiederanlauftest bestätigt, dass die zugesicherten Werte auch real erreicht werden.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Quellen
Fragen zu RPO und RTO in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.