RPO und RTO richtig definieren: So findest du die passenden Werte

TL;DR

RPO (Recovery Point Objective) definiert den maximalen Datenverlust in Zeiteinheiten. Ein RPO von 4 Stunden bedeutet: Du akzeptierst den Verlust von bis zu 4 Stunden an Daten.
RTO (Recovery Time Objective) definiert die maximale Ausfallzeit. Ein RTO von 8 Stunden bedeutet: Das System muss innerhalb von 8 Stunden nach dem Ausfall wieder verfügbar sein.
RPO und RTO werden nicht von der IT allein festgelegt, sondern gemeinsam mit den Fachabteilungen auf Basis einer Business Impact Analyse.
Kürzere RPO- und RTO-Werte kosten exponentiell mehr. Ein RTO von 1 Stunde erfordert eine völlig andere Infrastruktur als ein RTO von 24 Stunden.
Die definierten Werte müssen regelmäßig durch Restore-Tests verifiziert werden. Ein RTO auf dem Papier, das in der Praxis nicht erreichbar ist, erzeugt nur ein falsches Sicherheitsgefühl.

Zwei Kennzahlen, die alles bestimmen

Wenn du dich mit Backup, Disaster Recovery oder Business Continuity beschäftigst, begegnen dir zwei Abkürzungen immer wieder: RPO und RTO. Diese beiden Kennzahlen sind die Grundlage für deine gesamte Datensicherungs- und Wiederherstellungsstrategie. Sie bestimmen, wie oft du sichern musst, welche Backup-Methode du brauchst und wie viel Geld du in deine DR-Infrastruktur investieren solltest.

Das Problem: In vielen Unternehmen werden RPO und RTO entweder gar nicht definiert, pauschal auf alle Systeme angewendet ("alles kritisch, alles sofort") oder von der IT-Abteilung allein festgelegt, ohne die Fachabteilungen einzubeziehen. Alle drei Varianten führen zu einer Backup-Strategie, die entweder zu wenig schützt oder unnötig teuer ist.

RPO: Wie viel Datenverlust kannst du tolerieren?

RPO steht für Recovery Point Objective und beantwortet die Frage: Wie viele Minuten, Stunden oder Tage an Daten dürfen maximal verloren gehen, wenn ein System ausfällt?

Das RPO wird rückwärts vom Zeitpunkt des Ausfalls gemessen. Wenn dein ERP-System um 14:00 Uhr ausfällt und das RPO bei 4 Stunden liegt, muss das letzte verwendbare Backup von maximal 10:00 Uhr stammen. Alle Daten, die zwischen 10:00 und 14:00 Uhr eingegeben wurden, dürfen verloren sein.

RPO bestimmt dein Backup-Intervall

Das RPO hat direkte Auswirkungen auf dein Backup-Intervall. Wenn das RPO 24 Stunden beträgt, reicht ein tägliches Backup. Wenn das RPO 4 Stunden beträgt, brauchst du mindestens alle 4 Stunden ein Backup oder einen kontinuierlichen Replikationsmechanismus. Wenn das RPO bei 15 Minuten liegt, brauchst du Transaction-Log-Backups, kontinuierliche Datenreplikation oder Snapshots im Minutentakt. Und wenn das RPO bei null liegt (kein Datenverlust tolerierbar), brauchst du synchrone Replikation auf ein zweites System, was erhebliche Kosten und Komplexität mit sich bringt.

RPO ist nicht gleich Backup-Intervall

Ein häufiger Denkfehler: "Wir sichern alle 4 Stunden, also ist unser RPO 4 Stunden." Das stimmt nur, wenn das Backup auch tatsächlich konsistent und wiederherstellbar ist. Wenn dein 4-Stunden-Backup fehlerhaft ist und du auf das vorherige (8 Stunden alt) zurückgreifen musst, liegt dein tatsächliches RPO bei 8 Stunden, nicht bei 4.

Deshalb gehört zum RPO immer die Frage: Wie viele Backup-Generationen halte ich vor, und wie stelle ich sicher, dass mindestens eine davon funktioniert? Regelmäßige Restore-Tests sind die Antwort.

Unterschiedliche RPOs für unterschiedliche Daten

Nicht alle Daten in einem System haben denselben Wert. Die Transaktionsdaten in deinem ERP-System (Aufträge, Rechnungen, Buchungen) ändern sich ständig und haben einen hohen Wert. Die Stammdaten (Artikeldaten, Kundenstamm) ändern sich seltener. Die Konfiguration des Systems ändert sich fast nie.

In der Praxis wird das RPO trotzdem pro System definiert, nicht pro Datentyp, weil ein selektiver Backup/Restore auf Datenebene in den meisten Systemen nicht praktikabel ist. Aber es hilft bei der Einschätzung: Wenn sich die Transaktionsdaten alle paar Minuten ändern, aber die Stammdaten nur wöchentlich, dann ist ein RPO von 4 Stunden ein akzeptabler Kompromiss.

RTO: Wie lange darf das System ausfallen?

RTO steht für Recovery Time Objective und beantwortet die Frage: Wie viel Zeit darf zwischen dem Ausfall eines Systems und seiner vollständigen Wiederherstellung maximal vergehen?

Das RTO wird vorwärts vom Zeitpunkt des Ausfalls gemessen. Wenn das ERP-System um 14:00 Uhr ausfällt und das RTO bei 8 Stunden liegt, muss es spätestens um 22:00 Uhr wieder voll funktionsfähig sein.

Was gehört zur RTO-Berechnung?

Das RTO umfasst nicht nur die reine Restore-Zeit, sondern den gesamten Wiederherstellungsprozess. Dazu gehören die Erkennung des Ausfalls (wie lange dauert es, bis jemand bemerkt, dass das System ausgefallen ist?), die Diagnose (was ist die Ursache, und welche Wiederherstellungsstrategie ist die richtige?), die Bereitstellung der Infrastruktur (falls Hardware beschädigt ist: Ersatzhardware beschaffen und einrichten), der eigentliche Restore (Daten aus Backup wiederherstellen), die Verifikation (funktioniert das System nach dem Restore korrekt?) und die Benutzerfreigabe (System wird für die Benutzer freigegeben, ggf. VPN-Tunnel umkonfiguriert, DNS-Einträge angepasst).

Viele Unternehmen definieren ihr RTO nur auf Basis der reinen Restore-Zeit und vergessen die anderen Phasen. In der Praxis dauern Erkennung, Diagnose und Verifikation oft länger als der eigentliche Restore.

RTO bestimmt deine DR-Strategie

Das RTO hat direkte Auswirkungen auf die Architektur deiner Wiederherstellungslösung.

RTO über 24 Stunden: Restore aus Standard-Backup reicht aus. Keine besondere DR-Infrastruktur nötig. Kosten: gering.

RTO 4 bis 24 Stunden: Schnelle Restore-Fähigkeit erforderlich. Lokale Backups (nicht nur Cloud), ggf. vorbereitete Ersatz-VMs. Kosten: moderat.

RTO 1 bis 4 Stunden: Standby-Systeme oder Cloud-DR (Azure Site Recovery, Zerto) erforderlich. Automatisiertes Failover oder zumindest orchestrierter Restore. Kosten: erheblich.

RTO unter 1 Stunde: Active-Active-Setup mit automatischem Failover oder Hochverfügbarkeitscluster. Kosten: hoch bis sehr hoch.

RTO nahe null: Vollständige Redundanz mit synchroner Replikation. Typisch nur für geschäftskritische Systeme in Konzernen oder regulierten Branchen. Kosten: sehr hoch.

Die Kosten steigen nicht linear, sondern exponentiell, je kürzer das RTO wird. Der Sprung von 24 Stunden auf 4 Stunden ist meist mit moderaten Investitionen machbar. Der Sprung von 4 Stunden auf 1 Stunde verdoppelt oder verdreifacht die Kosten typischerweise.

Wie du RPO und RTO richtig ermittelst

RPO und RTO werden nicht von der IT-Abteilung im stillen Kämmerlein festgelegt. Sie ergeben sich aus einer Business Impact Analyse und den Anforderungen der Geschäftsprozesse, und die kennen die Fachabteilungen besser als die IT.

Schritt 1: Geschäftsprozesse identifizieren

Liste die wichtigsten Geschäftsprozesse deines Unternehmens auf. Für ein produzierendes Unternehmen könnten das sein: Auftragsannahme und -bearbeitung, Produktion und Fertigungssteuerung, Einkauf und Lagerverwaltung, Rechnungswesen und Controlling, Personalwesen und Zeiterfassung, Kundenservice und Support.

Schritt 2: IT-Systeme zuordnen

Für jeden Geschäftsprozess identifizierst du die IT-Systeme, die ihn unterstützen. Die Auftragsbearbeitung hängt am ERP-System und am E-Mail-System. Die Produktion hängt am ERP und möglicherweise an einem MES (Manufacturing Execution System). Das Rechnungswesen hängt am ERP und am DATEV-System.

Schritt 3: Auswirkungen eines Ausfalls bewerten

Für jeden Geschäftsprozess bewertest du die Auswirkungen eines Ausfalls über die Zeit. Was passiert, wenn die Auftragsbearbeitung 1 Stunde ausfällt? 4 Stunden? 1 Tag? 3 Tage? 1 Woche?

Die Auswirkungen können finanzieller Natur sein (Umsatzausfall, Vertragsstrafen, Überstundenkosten), operativer Natur (Produktionsstillstand, Lieferverzögerungen), regulatorischer Natur (Verstöße gegen Meldepflichten, DSGVO-Probleme) oder reputationsbezogen (Kundenverlust, Vertrauensschaden).

Die Fachabteilungen sind die richtigen Ansprechpartner für diese Bewertung. Der Vertriebsleiter weiß, wie viele Aufträge pro Stunde eingehen und was ein Tag Stillstand für die Kundenbeziehung bedeutet. Der Produktionsleiter weiß, welche Produktionslinien bei IT-Ausfall stillstehen und welche Kosten das verursacht. Die Finanzabteilung weiß, welche Zahlungsfristen und regulatorischen Termine betroffen sind.

Schritt 4: Toleranzgrenzen bestimmen

Aus den Auswirkungen leitest du die Toleranzgrenzen ab. Der Punkt, an dem die Auswirkungen inakzeptabel werden, definiert dein RTO. Der Datenverlust, der gerade noch tolerierbar ist, definiert dein RPO.

Beispiel: Der Vertriebsleiter sagt, dass ein Ausfall der Auftragsbearbeitung bis zu 4 Stunden tolerierbar ist, weil Kunden telefonisch vertröstet werden können. Nach 4 Stunden beginnen Kunden, zur Konkurrenz abzuwandern. Das RTO für das ERP-System (soweit es die Auftragsbearbeitung betrifft) liegt also bei 4 Stunden.

Der Vertriebsleiter sagt weiter, dass der Verlust von mehr als 2 Stunden an Auftragsdaten problematisch ist, weil die manuelle Nacherfassung fehleranfällig und zeitaufwändig ist. Das RPO für das ERP-System liegt also bei 2 Stunden.

Schritt 5: Realitätscheck mit der IT

Die von den Fachabteilungen gewünschten Werte müssen mit der technischen Realität und dem Budget abgeglichen werden. Die IT prüft, ob die gewünschten Werte mit der vorhandenen oder realistisch beschaffbaren Infrastruktur erreichbar sind.

Wenn der Fachbereich ein RTO von 2 Stunden wünscht, aber der Restore des ERP-Systems erfahrungsgemäß 6 Stunden dauert, gibt es drei Möglichkeiten: in schnellere Wiederherstellungstechnik investieren (z.B. Hot-Standby), das RTO auf einen realistischen Wert anpassen (und die Geschäftsleitung über das verbleibende Risiko informieren) oder den Geschäftsprozess so anpassen, dass er einen längeren IT-Ausfall besser überbrücken kann (manuelle Fallback-Prozesse).

Schritt 6: Dokumentation und Freigabe

Die finalen RPO- und RTO-Werte werden dokumentiert und von der Geschäftsleitung freigegeben. Das ist kein bürokratischer Formalismus, sondern notwendig, weil die Geschäftsleitung das verbleibende Risiko bewusst akzeptieren muss. Ein RPO von 4 Stunden bedeutet: Wir akzeptieren bewusst, dass bis zu 4 Stunden an Daten verloren gehen können. Die Geschäftsleitung muss diese Entscheidung mittragen.

Typische RPO- und RTO-Werte im Mittelstand

Um dir eine Orientierung zu geben, hier typische Werte für verschiedene Systemkategorien in mittelständischen Unternehmen. Diese Werte sind Richtwerte, nicht Vorschriften. Deine tatsächlichen Werte hängen von deinem spezifischen Geschäftsmodell ab.

Geschäftskritische Systeme (ERP, Datenbank, Active Directory)

Typisches RTO: 2 bis 8 Stunden. Typisches RPO: 1 bis 4 Stunden. Backup-Strategie: Lokale Backups alle 2 bis 4 Stunden, ggf. Transaction-Log-Backups alle 15 Minuten für Datenbanken. Standby-System oder Cloud-DR für RTOs unter 4 Stunden.

Wichtige Systeme (Fileserver, E-Mail, CRM)

Typisches RTO: 8 bis 24 Stunden. Typisches RPO: 4 bis 12 Stunden. Backup-Strategie: Tägliche Backups mit lokaler und Cloud-Kopie. Restore aus lokalem Backup möglich.

Standard-Systeme (Intranet, Zeiterfassung, Druckserver)

Typisches RTO: 24 bis 72 Stunden. Typisches RPO: 24 Stunden. Backup-Strategie: Tägliches Backup, Restore bei Bedarf. Keine besondere DR-Infrastruktur.

Unkritische Systeme (Testumgebungen, Archiv)

Typisches RTO: 72 Stunden bis 1 Woche. Typisches RPO: 24 Stunden bis 1 Woche. Backup-Strategie: Wöchentliches Backup oder Neuinstallation nach Bedarf.

RPO/RTO in der Praxis: Zwei Beispiele

Beispiel 1: Handelsunternehmen mit Onlineshop

Ein Handelsunternehmen mit 80 Mitarbeitern betreibt einen Onlineshop, der 60 % des Umsatzes generiert. Der Shop läuft auf einer E-Commerce-Plattform mit angebundener Warenwirtschaft.

Der Onlineshop hat ein RPO von 15 Minuten (Transaction-Log-Backup der Datenbank alle 15 Minuten, weil jede verlorene Bestellung Umsatzverlust und Kundenfrust bedeutet) und ein RTO von 2 Stunden (ein Ausfall von mehr als 2 Stunden während der Geschäftszeiten kostet tausende Euro und schadet dem Google-Ranking).

Die Warenwirtschaft hat ein RPO von 1 Stunde und ein RTO von 4 Stunden (Aufträge können manuell zwischengepuffert werden).

Die DR-Strategie für den Shop sieht so aus: Die Datenbank wird synchron auf ein Standby-System repliziert. Bei Ausfall des Primärsystems erfolgt ein automatisches Failover. Transaction-Log-Backups alle 15 Minuten als zusätzliche Sicherheit. Das ist teurer als ein einfaches tägliches Backup, aber die Geschäftsleitung hat entschieden, dass die Kosten eines Shop-Ausfalls die DR-Kosten bei Weitem übersteigen.

Beispiel 2: Ingenieurbüro

Ein Ingenieurbüro mit 25 Mitarbeitern arbeitet primär mit CAD-Software und einem Projektmanagement-Tool. Die CAD-Dateien sind groß (mehrere GB pro Projekt), ändern sich aber nur während der aktiven Bearbeitungsphase.

Die CAD-Daten auf dem Fileserver haben ein RPO von 4 Stunden (ein verlorener Arbeitstag wäre ärgerlich, aber 4 Stunden Arbeit lassen sich nacharbeiten) und ein RTO von 24 Stunden (die Ingenieure können im Notfall einen Tag mit Planungstätigkeiten, Kundengesprächen oder Dokumentation überbrücken).

Das Projektmanagement-Tool hat ein RPO von 24 Stunden und ein RTO von 48 Stunden (die Daten ändern sich selten, und die Mitarbeiter können kurzzeitig ohne arbeiten).

Die DR-Strategie: Tägliches Backup des Fileservers auf ein lokales NAS und in die Cloud. Wöchentliches Full-Backup, tägliches inkrementelles Backup. Kein Standby-System nötig. Die Kosten für diese Strategie liegen bei wenigen hundert Euro pro Monat.

Die Kostenfalle: Zu ambitionierte Werte

Der häufigste Fehler bei der RPO/RTO-Definition ist der Wunsch, für alles möglichst kurze Werte anzusetzen. "Sicher ist sicher" klingt vernünftig, führt aber zu einer massiv überdimensionierten und teuren Infrastruktur.

Ein konkretes Rechenbeispiel: Ein Unternehmen mit 15 virtuellen Maschinen möchte für alle Systeme ein RTO von 2 Stunden und ein RPO von 30 Minuten. Das erfordert für jedes System ein Standby-System oder eine Cloud-DR-Replikation, Transaction-Log-Backups oder Snapshots im 30-Minuten-Takt für alle Datenbanken, Orchestrierungs-Software für das automatisierte Failover und erheblichen Storage für die häufigen Backups.

Die Kosten dafür liegen bei geschätzt 3.000 bis 5.000 Euro pro Monat, zuzüglich der einmaligen Einrichtungskosten.

Wenn das Unternehmen realistisch bewertet, welche Systeme tatsächlich ein RTO von 2 Stunden brauchen (vermutlich 2 bis 3), und für den Rest 24 Stunden akzeptiert, sinken die Kosten auf 800 bis 1.500 Euro pro Monat. Die Ersparnis ist erheblich, und das tatsächliche Risiko steigt kaum, weil die unkritischen Systeme ohnehin nur wenige Nutzer betreffen.

RPO/RTO überprüfen und anpassen

RPO und RTO sind keine statischen Werte. Sie müssen regelmäßig überprüft und bei Bedarf angepasst werden, und zwar bei Änderungen an der IT-Landschaft (neues ERP-System, Migration in die Cloud, neue Geschäftsanwendungen), bei Änderungen am Geschäftsmodell (neuer Onlineshop, neue Produktionslinie, Expansion), nach Restore-Tests (wenn die tatsächliche Wiederherstellungszeit das RTO überschreitet), nach realen Vorfällen (wenn sich herausstellt, dass das RPO zu großzügig oder zu eng war), bei Änderungen der regulatorischen Anforderungen (neue NIS2-Umsetzungsverordnung, neue Branchenstandards) und mindestens einmal jährlich im Rahmen des Management-Reviews.

Messung und Nachweis

Für Audits und Zertifizierungen reicht es nicht, RPO und RTO auf Papier zu definieren. Du musst nachweisen, dass du die Werte auch tatsächlich einhalten kannst. Der Nachweis erfolgt durch regelmäßige Restore-Tests, bei denen du die tatsächliche Wiederherstellungszeit misst (RTA, Recovery Time Actual) und den tatsächlichen Datenverlust bestimmst (RPA, Recovery Point Actual).

Wenn das definierte RTO bei 4 Stunden liegt und dein letzter Restore-Test eine RTA von 5,5 Stunden ergeben hat, hast du ein Problem, das du lösen musst. Entweder verbesserst du den Wiederherstellungsprozess (schnellere Hardware, optimierte Runbooks, parallele Restores) oder du passt das RTO an und kommunizierst das verbleibende Risiko an die Geschäftsleitung.

Dokumentiere jeden Restore-Test mit Datum, getestetem System, geplanter RTO/RPO, gemessener RTA/RPA und Abweichungen mit Ursachenanalyse. Diese Dokumentation ist dein stärkstes Argument im Audit.

RPO und RTO in der ISMS-Dokumentation

RPO und RTO sind Bestandteil mehrerer ISMS-Dokumente. In der Business Impact Analyse (BIA) werden die Werte erstmalig ermittelt und begründet. Im Disaster Recovery Plan werden sie als Zielwerte für die Wiederherstellungsstrategien verwendet. In der Backup-Richtlinie werden die Backup-Intervalle aus den RPOs abgeleitet. In den Restore-Testprotokollen werden die tatsächlich erreichten Werte dokumentiert. Im Management-Review werden Abweichungen zwischen Soll und Ist berichtet und Maßnahmen beschlossen.

Wenn du RPO und RTO sauber definierst, dokumentierst und regelmäßig überprüfst, hast du nicht nur eine funktionierende Backup- und DR-Strategie, sondern auch einen wesentlichen Teil deiner NIS2- und ISO-27001-Anforderungen abgedeckt. In ISMS Lite lassen sich RPO- und RTO-Werte pro System dokumentieren, mit Backup-Strategien verknüpfen und durch Testergebnisse belegen.

Weiterführende Artikel

RPO RTO Backup Disaster Recovery BCM Business Impact Analyse ISMS