Startseite › Blog › RTO und RPO: Definition und Unterschiede für die Backup-Planung
RTO und RPO: Definition und Unterschiede für die Backup-Planung
RTO und RPO sind die zwei Kennzahlen, die den Großteil der Arbeit eines Backup-Administrators bestimmen. Die Recovery Time Objective (RTO) ist die angestrebte Zeitspanne zwischen einem Ausfall und der vollständigen Wiederherstellung des Betriebs, also wie lange das Unternehmen nach einem Ausfall stillstehen darf. Die Recovery Point Objective (RPO) ist das maximal akzeptable Alter der wiederhergestellten Daten, also wie viele Daten das Unternehmen verlieren darf.
Beide Werte bilden den Kern jedes Disaster-Recovery-Plans. Sie werden häufig verwechselt, weil beide in Zeiteinheiten angegeben werden und beide umso enger ausfallen, je wichtiger das System ist. Sie messen trotzdem unterschiedliche Dinge.
Was ist RTO (Recovery Time Objective)?
Die Recovery Time Objective ist die angestrebte Dauer zwischen einem Ausfall und dem Moment, in dem der Betrieb vollständig wiederhergestellt ist. Sie legt fest, wie schnell sich die Organisation erholen muss, bevor der Ausfall echten Schaden anrichtet.
Für die RTO gilt:
- RTO ist ein Zeitmaß. Die RTO beschreibt, wie lange Sie ausfallen dürfen, nicht wie viel Sie verlieren.
- Die Kosten steigen, je niedriger die RTO ist. Schnellere Wiederherstellung bedeutet mehr Infrastruktur und teurere Technologie.
- Die RTO unterscheidet sich je nach System. Eine kundennahe E-Commerce-Plattform und ein interner Reporting-Server brauchen nicht dieselbe RTO.
Nehmen wir einen Serverausfall mit einer RTO von vier Stunden. Backup und Wiederherstellung müssen so aufgestellt sein, dass der Betrieb innerhalb dieses Zeitfensters wieder läuft. Wird es überschritten, drohen je nach Unternehmen Umsatzverluste, Reputationsschäden oder Compliance-Strafen.
Der Zielkonflikt ist einfach. Eine kürzere RTO bringt schnellere Wiederherstellung zu einem höheren Preis. Das Ziel wird daher gegen Budget und verfügbare Ressourcen abgewogen. Der niedrigste technisch mögliche Wert ist selten der richtige.
Was ist RPO (Recovery Point Objective)?
Die Recovery Point Objective definiert das maximal akzeptable Alter der Daten, die Sie wiederherstellen. Sie gibt an, wie weit Ihre Backups zurückreichen dürfen, damit der resultierende Datenverlust noch tragbar ist.
- RPO ist ein Maß für Datenverlust. Die RPO beschreibt, wie viel Arbeit, ausgedrückt in Zeit, bei einer Wiederherstellung verloren geht.
- Eine niedrigere RPO bedeutet häufigere Backups. Das kostet Speicherkapazität und Rechenleistung.
- Die RPO hängt vom Datentyp ab. Eine transaktionale Kundendatenbank braucht eine deutlich niedrigere RPO als eine Dateifreigabe mit archivierten Dokumenten.
Bei einer RPO von einer Stunde bedeuten ein Backup um 09:00 Uhr und ein Ausfall um 09:45 Uhr den Verlust von bis zu 45 Minuten an Daten. Um diesen Wert zu senken, müssen Sie häufiger sichern und mehr speichern. Deshalb wird die RPO pro System festgelegt und nicht global.
Die wichtigsten Unterschiede zwischen RTO und RPO
Beide Ziele werden in der Disaster-Recovery-Planung gemeinsam verwendet, verfolgen aber unterschiedliche Zwecke.
| Kennzahl | RTO | RPO |
|---|---|---|
| Fokus | Wiederherstellungszeit | Datenverlust |
| Was sie misst | Zeit zwischen Ausfall und Wiederherstellung | Akzeptables Alter der Backup-Daten |
| Kostentreiber | Kürzere RTO bedeutet höhere Wiederherstellungskosten | Niedrigere RPO bedeutet höhere Speicherkosten |
| Auswirkung auf den Betrieb | Kritische Systeme werden schnell wiederhergestellt | Datenverlust wird minimiert |
Als Merkhilfe: Bei der RTO geht es darum, wie lange Sie ausfallen, bei der RPO darum, wie viel Sie verlieren, wenn Sie wieder hochfahren.
Warum sind RTO und RPO für die Backup-Planung wichtig?
Beide Kennzahlen bestimmen direkt, welche Backup-Technologie Sie brauchen und was die Wiederherstellungsinfrastruktur kostet.
Ziele an Geschäftsprioritäten ausrichten. Die RTO muss kurz sein für Systeme, deren Ausfall das Geschäft stoppt. Die RPO muss kurz sein, wo die Daten selbst der Wert sind, etwa bei Finanz- oder Patientendaten.
Die Technologie wählen. Eine kurze RTO führt zu Instant Recovery, Standby-Umgebungen oder virtualisiertem Failover. Eine kurze RPO führt zu häufigen inkrementellen Backups, Continuous Data Protection oder automatisierter Zeitplanung. Das sind unterschiedliche Investitionen, und wer beide Ziele aggressiv setzt, ohne das zu bemerken, kauft doppelt.
Die Kostenkurve verstehen. Jede Verschärfung eines der beiden Werte kostet Geld, und keine der beiden Kostenkurven verläuft im unteren Bereich linear. Der Schritt von 24 auf 4 Stunden ist meist bezahlbar, der von 4 Stunden auf 15 Minuten oft nicht. Cloudbasierte Wiederherstellung kann einen Teil der Kosten verlagern, die Kurve verschwindet dadurch aber nicht.
RTO und RPO für Ihre Organisation optimieren
Die Anforderungen an die Wiederherstellung unterscheiden sich von Unternehmen zu Unternehmen. Die Ziele sollten sich deshalb an geschäftskritischen Systemen, verfügbaren Ressourcen und den tatsächlichen Wiederherstellungskosten orientieren.
Geschäftsanforderungen bewerten. Ordnen Sie Systeme nach Umsatzwirkung, Kundenwirkung und Compliance-Risiko und ermitteln Sie, wie viel Ausfallzeit und Datenverlust jedes System verkraftet. Diese Toleranzen werden zur RTO und RPO pro System.
Technologie auf das Ziel abstimmen. Hochverfügbarkeitskonfigurationen, Instant Recovery und cloudbasiertes Failover dienen kurzen RTOs. Häufige oder kontinuierliche Backups dienen kurzen RPOs. Wie viele Kopien Sie auf welchen Medien und an welchen Standorten halten, regelt die 3-2-1 Backup Regel.
Die Werte testen. Führen Sie Wiederherstellungstests auf der echten Infrastruktur durch. Zeigen die Tests, dass die Ziele nicht erreichbar sind, muss entweder in das Schließen der Lücke investiert oder das Ziel angepasst werden. Eine RTO, die nur in einem Dokument existiert, ist schlimmer als gar keine RTO.
RTO und RPO in der Praxis
Die Anforderungen unterscheiden sich stark nach Branche.
Gesundheitswesen. Elektronische Patientenakten (EHR) brauchen kurze RTOs, damit die Patientenversorgung nicht unterbrochen wird, und eine minimale RPO, damit Patientendaten vollständig erhalten bleiben. Das dient auch den Pflichten nach HIPAA.
Finanzdienstleistungen. Handelsplattformen und kundennahe Anwendungen haben extrem niedrige RTOs, weil jede Minute ihren Preis hat. Transaktionsdaten erfordern in der Regel kontinuierlichen Schutz, damit nichts verloren geht.
E-Commerce. Ausfallzeit schlägt direkt auf den Umsatz durch, deshalb sind die RTOs kurz. Kunden- und Bestellhistorie brauchen häufige Backups, um die RPO niedrig zu halten.
Allen drei Branchen ist gemeinsam, dass die Ziele von den geschäftlichen Folgen eines Ausfalls bestimmt werden, nicht davon, was die Backup-Infrastruktur heute zufällig leisten kann.
Realistische RTO- und RPO-Ziele für Ihr Unternehmen festlegen
- Kritische Systeme identifizieren. Priorisieren Sie nach Umsatz, Kundenerlebnis und Compliance-Risiko.
- Risiko und Kosten abwägen. Kürzere Ziele kosten mehr. Prüfen Sie, ob die Ausgaben durch die vermiedenen Auswirkungen gerechtfertigt sind.
- Regulierung berücksichtigen. Vor allem im Finanz- und Gesundheitswesen gibt es Vorgaben, die begrenzen, wie großzügig Ihre Ziele ausfallen dürfen.
- Testen, dann anpassen. Üben Sie den Wiederherstellungsplan und passen Sie die Werte an das an, was tatsächlich passiert ist.
Fazit
RTO und RPO sind die zwei Stellschrauben, die bestimmen, was eine Backup-Strategie leisten muss und was sie kostet. Die RTO regelt die Wiederherstellungszeit, die RPO den akzeptablen Datenverlust. Eine Strategie, die den Geschäftsbedarf erfüllt, ohne überdimensioniert zu sein, setzt beide Werte bewusst und pro System fest.
Als erster Schritt eignet sich eine Messung der tatsächlich erreichbaren RTO und RPO. Der Vergleich mit den Werten im Disaster-Recovery-Dokument zeigt, ob die Abweichung ins Gewicht fällt.
Catalogic DPX und vStor setzen an beiden Werten gleichzeitig an. Rapid Recovery und granulare Wiederherstellung verkürzen die RTO, flexible Zeitpläne und unveränderliche Snapshots halten die RPO niedrig, ohne die Wiederherstellbarkeit zu opfern. Wenn Sie die Ziele für eine konkrete Umgebung besprechen möchten, fordern Sie eine Demo an.

