RPO und RTO erklärt: wie viele Daten Sie verlieren dürfen und wie schnell Sie wieder laufen müssen

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-21

Was bedeuten RPO und RTO?

Der Leitfaden zur Notfallplanung NIST SP 800-34 Rev. 1 definiert drei verwandte Größen. Das SNIA Dictionary formuliert die ersten beiden etwas anders, mit gleicher Bedeutung. Das BSI nutzt im Glossar zum BSI-Standard 200-4 (Business Continuity Management) deutsche Namen für dieselben Begriffe, sie stehen in der Tabelle in Klammern.

NIST merkt außerdem an, dass der RPO im Gegensatz zum RTO nicht Teil der MTD ist: Er misst, wie viel Datenverlust der Prozess verträgt, nicht die Zeit im Ausfall. Beide Zahlen stammen aus einer Business-Impact-Analyse: Sie fragen die Verantwortlichen jedes Prozesses, was ein Ausfall kostet, und setzen die Ziele aus den Antworten.

Schematisch. Die Spannen sind nicht maßstäblich.

Wie bestimmen Backup-Häufigkeit und Laufzeit den RPO?

Ein Backup erfasst den Zustand der Daten um die Zeit, zu der ein Lauf stattfindet. Startet alle T Stunden ein Lauf und braucht er d Stunden bis zum Ende, findet ein Ausfall kurz vor Abschluss des nächsten Laufs den neuesten vollständigen Sicherungsstand etwa T + d Stunden alt vor. Das ist der ungünstigste Datenverlust:

ungünstigster Datenverlust = Backup-Intervall + Dauer eines Laufs

Zwei Folgen übersieht man leicht. Ein nächtliches Backup erfüllt keinen RPO von 24 Stunden, weil der Lauf selbst Zeit braucht. Und ein fehlgeschlagener Lauf fügt ein ganzes Intervall hinzu: Wurde der Lauf vor dem Ausfall nicht abgeschlossen, ist der neueste gute Sicherungsstand zwei Intervalle alt. Ein RPO wird nur von einem Zeitplan mit etwas Reserve erreicht und davon, dass jemand erfährt, wenn ein Lauf fehlschlägt. Das BSI verlangt entsprechend, dass die Datensicherung die Anforderungen an den RPO erfüllt, und nennt in den Umsetzungshinweisen zu CON.3 die Regel, den Abstand der Datensicherungen so zu wählen, dass Restaurierungs- und Nacherfassungszeit unter der maximal tolerierbaren Ausfallzeit bleiben.

Der RPO ist auch nicht dasselbe wie die Aufbewahrung. Der RPO betrifft den neuesten Sicherungsstand; die Aufbewahrung entscheidet, wie weit Sie zurückgehen können (siehe Generationenprinzip). NIST SP 800-34 sagt, die Richtlinie solle die Mindesthäufigkeit und den Umfang der Backups danach festlegen, wie kritisch die Daten sind und wie oft neue Informationen hinzukommen.

Was bestimmt den RTO?

Die Zeit bis zur Wiederherstellung ist die Summe mehrerer Schritte, und nur einer davon ist das Kopieren von Daten:

1. Den Ausfall bemerken und entscheiden, wiederherzustellen.
2. Ein Ziel bereitmachen: eine neue Maschine, ein neues Postfach, Zugriff und Zugangsdaten.
3. Die Daten wiederherstellen, was die Datenmenge geteilt durch die tatsächlich erreichte Geschwindigkeit dauert.
4. Das Ergebnis prüfen und den Benutzern zurückgeben.

Restore-Zeit = fester Aufwand + wiederherzustellende Daten ÷ Restore-Durchsatz

Beim Durchsatz zählt der Restore-Weg. Er ist der langsamste von: dem Speicher, aus dem Sie lesen, der Verbindung zwischen diesem Speicher und dem Ziel, der Schreibgeschwindigkeit des Ziels selbst und allen Grenzen des Dienstes, in den Sie wiederherstellen. Der Weg entscheidet auch, wie viel Sie wiederherstellen müssen: ein Postfach, einen Ordner oder eine ganze Maschine, für die bei einem dateibasierten Backup zuerst ein Betriebssystem installiert werden muss. Auch Speicherklassen zählen: Cloud-Archivklassen können Stunden brauchen, bis das erste Byte verfügbar ist, etwa S3 Glacier Flexible Retrieval mit Minuten bis Stunden und Massenabrufen von 5 bis 12 Stunden laut AWS, und ein Band muss geholt und eingelegt werden. Siehe Backup-Speicher wählen.

Ein Rechenbeispiel

Ein Unternehmen mit 25 Beschäftigten hat Microsoft-365-Mail und OneDrive und einen Dateiserver mit 800 GB. Die Verantwortlichen setzen diese Ziele: Das Auftragspostfach darf höchstens vier Stunden Mail verlieren und muss binnen vier Stunden wieder da sein; der Dateiserver darf einen Tag verlieren und muss binnen acht Stunden wieder da sein. Jede Zahl unten ist eine Annahme, gewählt, um die Methode zu zeigen.

• Mail, RPO von vier Stunden. Ein Backup alle 4 Stunden, das 20 Minuten dauert, ergibt im ungünstigsten Fall 4 h 20 min und verfehlt das Ziel. Alle 3 Stunden ergibt 3 h 20 min und erreicht es, mit Luft für einen langsamen Lauf.
• Dateiserver, RPO von 24 Stunden. Ein nächtliches Backup, das zwei Stunden dauert, ergibt im ungünstigsten Fall 26 Stunden. Um 24 Stunden zu erreichen, muss das Intervall 22 Stunden oder kürzer sein, oder der Lauf muss schneller werden.
• Dateiserver, RTO von acht Stunden. Alle 800 GB aus Speicher im selben Gebäude mit 100 MB/s wiederherzustellen dauert 2 h 13 min; mit zwei Stunden Aufwand für Bemerken, Entscheiden und Vorbereiten eines Ziels sind es insgesamt etwa 4 h 13 min, das Ziel ist erreicht. Liegt die einzige Kopie in einem Bucket, den eine Leitung mit 25 MB/s erreicht, braucht allein der Kopierschritt 8 h 53 min, und insgesamt sind es etwa 10 h 53 min, das Ziel wird verfehlt. Die Möglichkeiten sind ein schnellerer Weg, eine Kopie nahe am Ziel, die wichtigsten Ordner zuerst wiederherzustellen oder ein lockereres Ziel.

Der Aufwand beträgt 60 Minuten für Mail und die virtuelle Maschine und 120 Minuten für den Dateiserver, und die Laufzeiten sind in der Reihenfolge der Zeilen 30, 20, 120, 120 und 10 Minuten. Keine dieser Zahlen ist die Messung eines Produkts. Messen Sie Ihre eigenen: Stellen Sie eine bekannte Datenmenge in ein Testziel wieder her und stoppen Sie die Zeit.

Eigene Zahlen ausprobieren

Der Rechner unten nutzt dieselben zwei Formeln. Er braucht JavaScript; ohne trägt die Tabelle oben die Rechnung. Nichts, was Sie eingeben, verlässt Ihren Browser.

Was sagen RPO und RTO nicht?

• Sie sind Ziele, keine Garantien. Ein Zeitplan kann den RPO auf dem Papier erreichen und doch Daten verlieren, wenn Läufe unbemerkt fehlschlagen.
• Sie setzen voraus, dass das Backup gut ist. Ein Sicherungsstand, der sich nicht zurücklesen lässt, erreicht kein Ziel; das ist die „0“ in 3-2-1-1-0.
• Sie setzen voraus, dass die Menschen und der Zugang da sind: die Zugangsdaten, die Schlüssel und die Person, die die Schritte kennt.
• Der RPO betrifft nur den neuesten Sicherungsstand. Er sagt nichts darüber, wie weit Sie zurückgehen können, das ist die Aufbewahrung.

So macht es Restow

Restow gibt Ihnen die Stellschrauben für den RPO und einige der Wege für den RTO. Es verspricht keine der beiden Zahlen, und gemessene Restore-Zeiten, die es nennen könnte, hat es nicht.

Zeitpläne, die RPO-Seite

• Mail-Jobs (Microsoft 365 und IMAP) laufen nach einem Zeitplan, den Sie setzen: alle 15 Minuten oder seltener, bis zu 31 Tagen, oder zu einer Cron-Zeit. Die erste aktive Quelle eines neuen Mandanten erhält einen Job, der alle 8 Stunden sichert und jeden Sonntag um 03:00 Uhr eine Restore-Prüfung ausführt.
• Maschinen-Jobs für Server und Clients laufen alle paar Minuten oder Stunden (das kleinste Intervall sind 5 Minuten), täglich zu einer Uhrzeit oder wenn sich der Rechner verbindet. Der Agent meldet sich etwa alle 5 Minuten.
• Jobs für Dateifreigaben laufen nach einem Zeitplan, den Sie setzen (täglich, alle N Stunden oder zu einer Cron-Zeit), höchstens stündlich; das kleinste Intervall für eine Freigabe ist also eine Stunde.
• Proxmox-VE-Jobs (eine Preview) nehmen seit 0.4.2 die Rhythmen eines Mail-Jobs: alle paar Stunden, täglich, an gewählten Wochentagen, monatlich oder als Cron-Ausdruck, und nicht öfter als stündlich.
• Für Server und Clients ändern Richtlinien der Agenten, was der Zeitplan liefert. Eine Richtlinie kann ein Sicherungsfenster setzen (Wochentage und ein Zeitbereich), in dem geplante Sicherungen, Nachholläufe und Wiederholungen starten dürfen; eine laufende Sicherung läuft weiter, und „Jetzt sichern“ ignoriert das Fenster. Sie kann eine verpasste Sicherung im nächsten Fenster nachholen („Verpasste Sicherungen nachholen“), auf Wunsch nur bis zu einem Höchstalter, und eine fehlgeschlagene bis zu zehnmal wiederholen. Ein Fenster kann den RPO also länger machen als das Intervall, das Sie geschrieben haben, und ein Nachholen oder eine Wiederholung holt einen Teil davon wieder herein. Das Fenster, das Nachholen und die Wiederholungen brauchen Agent 0.4.0, und ohne Richtlinie verhalten sich Agenten wie bisher.
• Auch ein Update von Restow verschiebt den nächsten Lauf. Ab dem Moment, in dem ein Administrator es bestätigt, bis es vorbei ist, startet kein neuer Lauf; der Dialog zählt, was läuft, und stoppt es entweder sauber (die Vorgabe), wartet darauf oder wartet nicht. Zeitpläne, die fällig werden, laufen danach. Agent 0.4.0 hält in dieser Zeit seine eigenen Zeitpläne an; ältere Agenten tun das nicht. Seit 0.4.2 lässt sich ein Update auch für ein gewähltes Datum und eine Uhrzeit planen, und vor der Bestätigung, die den Countdown vorher kommt, wird nichts angehalten. Nach dem Server-Update warten neue Läufe außerdem, während Proxmox-VE-Knoten und Agenten das neue Release installieren, höchstens 15 Minuten.
• Eine Sicherung, die ein Administrator in der Weboberfläche stoppt (seit 0.4.2), endet als „Abgebrochen“ und zählt nicht als letzte Sicherung; die Zeit seit der letzten Sicherung wächst also weiter, bis der nächste geplante Lauf normal startet.
• Bis das erste Backup eines Objekts fertig ist, gibt es keinen Sicherungsstand, es ist also nichts wiederherstellbar. Das erste Backup eines großen Microsoft-365-Tenants kann Tage dauern, weil Microsoft die Graph-API drosselt.
• Eine Meldung „Sicherung überfällig“ (backup.overdue) sagt Ihnen, wenn ein Backup später dran ist, als sein Zeitplan erlaubt, damit ein fehlgeschlagener Lauf bemerkt wird, statt Ihren Datenverlust unbemerkt zu verdoppeln.

Restore-Wege, die RTO-Seite

• Mail, Kalender, Kontakte und OneDrive: ein einzelnes Element, einen Ordner oder ein ganzes Postfach oder OneDrive wiederherstellen, in das ursprüngliche Konto oder ein anderes, nicht-destruktiv. Benutzer können ihr eigenes Postfach wiederherstellen. Mail lässt sich außerdem als EML in einer ZIP-Datei oder als MBOX exportieren; der Download-Link ist 24 Stunden gültig.
• Server und Clients: in einen neuen Ordner auf dem Rechner wiederherstellen oder Dateien als ZIP-Datei herunterladen. Die Wiederherstellung einer ganzen Maschine heißt, zuerst das Betriebssystem zu installieren; Abbild-Backup mit Bare-Metal-Restore gibt es noch nicht.
• SharePoint-Websites: Bibliotheken, Ordner, Dateien, Listen und Elemente als ZIP herunterladen, Dateien und Ordner in ihre ursprüngliche Bibliothek oder in eine andere Bibliothek einer gesicherten Website zurückspielen und Listenelemente als neue Elemente in ihre ursprüngliche Liste zurückspielen.
• Dateifreigaben: aus einem Sicherungsstand als ZIP herunterladen, in einen neuen Ordner, an den ursprünglichen Ort oder in eine andere Freigabe wiederherstellen, die Wiederherstellungen erlaubt. Siehe Dateifreigaben (SMB und NFS).
• Gäste von Proxmox VE (Preview): als neuer Gast mit neuer VMID wiederherstellen. Einen Live-Restore gibt es nicht.
• Geht der primäre Speicher verloren, kann ein Kopie-Repository zum primären befördert werden, sobald es als vollständig belegt ist. Eine Kopie deckt Mail, Kalender, Kontakte, OneDrive, SharePoint-Websites, IMAP und VM-Daten von Proxmox VE ab, nicht Server, Clients, Dateifreigaben oder Proxmox-Container. Siehe Speicher.
• Ohne laufenden Restow-Server liest ein eigenständiges Restore-Werkzeug den Speicher und den Hauptschlüssel.

Was nicht gemessen ist

Restow zeigt, wie lange jeder Lauf dauerte, und stellt den Durchsatz grafisch dar, Sie sehen also Ihre eigenen Zahlen. Es veröffentlicht keine Backup- oder Restore-Geschwindigkeiten, und die Release-Prüfungen liefern keine Zahl, die wir nennen könnten. Microsoft-365-Backup und -Restore sind in den Release-Prüfungen noch nicht gegen einen echten Tenant gelaufen, Restore-Zeiten für Microsoft 365 sind also nicht gemessen. Die wöchentliche Restore-Prüfung belegt, dass sich eine Stichprobe zurücklesen lässt und übereinstimmt; sie misst keinen vollständigen Restore. Zwei neuere Prüfungen gehen weiter, ohne ein vollständiger Test-Restore zu sein. Jeder neue Sicherungsstand einer Dateifreigabe wird geprüft, indem bis zu 20 Stichprobendateien zurückgelesen und verglichen werden, und seit 0.4.2 wird jeder neue Sicherungsstand eines Proxmox-VE-Gasts binnen Minuten zurückgelesen (eine Stichprobe seiner Blöcke). Eine Startprüfung für Proxmox VE (eine Preview, standardmäßig aus) stellt einen Sicherungsstand als isolierten, vorübergehenden Gast wieder her, startet ihn, wartet auf seinen Gast-Agent und zerstört ihn wieder; das zeigt, dass der Sicherungsstand startet, aber nicht, dass die Anwendungen darin laufen. Ein vollständiger Test-Restore in ein separates Ziel ist weiterhin geplant. Bis dahin messen Sie einen echten Restore selbst. Siehe Microsoft-365- und IMAP-Backup, Restore und Verifizierung.

Häufig gestellte Fragen

Quellen

Gelesen am 21. Oktober 2026.

1. BSI: Glossar und Abkürzungsverzeichnis zum BSI-Standard 200-4 (BCM). RPO als maximal zulässiger Datenverlust, RTO als geforderte Wiederanlaufzeit, MTPD als maximal tolerierbare Ausfallzeit (MTA)
2. BSI: Vorschläge zu Business-Continuity-Strategien (BC-Strategien), Hilfsmittel zum BSI-Standard 200-4. Die Datensicherung muss die Anforderungen an den RPO erfüllen, und die Wiederherstellung darf den zeitlichen Rahmen des RTO nicht überschreiten (Seite 8)
3. BSI: Umsetzungshinweise zum Baustein CON.3 Datensicherungskonzept. Der Abstand der Datensicherungen ist so zu wählen, dass Restaurierungs- und Nacherfassungszeit kleiner als die maximal tolerierbare Ausfallzeit sind
4. NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (Mai 2010, englisch). Abschnitt 3.2.1 definiert MTD, RTO und RPO; Abschnitt 3.4.2 bindet die Backup-Häufigkeit an die Kritikalität der Daten
5. NIST-Glossar: recovery point objective (englisch). Der Zeitpunkt, bis zu dem Daten nach einem Ausfall wiederhergestellt sein müssen
6. NIST-Glossar: recovery time objective (englisch). Wie lange die Komponenten eines Systems in der Wiederherstellung sein dürfen, bevor der Schaden untragbar wird
7. SNIA Dictionary (Stand 28. April 2026, englisch): Recovery Point Objective, Recovery Time Objective. Die Definitionen der Speicherbranche, einschließlich dessen, dass null ein gültiger RPO ist
8. Amazon S3: Objektspeicherklassen. Archivklassen wie S3 Glacier Flexible Retrieval werden in Minuten bis Stunden abgerufen

Verwandte Artikel

• Die 3-2-1-Backup-Regel Drei Kopien, zwei Arten von Speicher, eine Kopie an einem anderen Ort, dazu die Erweiterung um eine unveränderliche Kopie und null Fehler. Mit Microsoft-365-Beispiel.
• Voll, inkrementell, differenziell und synthetisch voll Vergleichstabelle zu Speicherbedarf, Sicherungsdauer, Restore-Aufwand und Kettenrisiko, dazu Forever-Incremental, Changed Block Tracking und Deduplizierung.
• Backup-Speicher wählen Lokale Platte, NAS und NFS, S3-kompatibler Objektspeicher, Band und Cloud-Archivklassen im Vergleich bei Kosten, Haltbarkeit, Unveränderlichkeit und Restore-Tempo.
• Generationenprinzip (GFS) Tägliche, wöchentliche, monatliche und jährliche Sicherungsstände mit Kalenderbeispiel, der Unterschied zu „alles N Tage aufbewahren“ und die Übertragung von Band auf Platte und Objektspeicher.
• Backup-Glossar Nachschlagewerk Kurze Definitionen zu Backup, Restore, Aufbewahrung, Speicher und DSGVO, von 3-2-1-Regel bis WORM, mit Links zu den Artikeln und Funktionsseiten.