Katalog
concept#Zuverlässigkeit#Daten#Architektur#Governance

Recovery Point Objective (RPO)

RPO definiert den maximal tolerierbaren Datenverlust in zeitlicher Hinsicht und dient als Maß für Backup‑ und Replikationsanforderungen.

Das Recovery Point Objective (RPO) definiert den maximal tolerierbaren Datenverlust in einem Disaster‑Recovery‑Szenario.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Backup‑Software (z. B. Veeam, Commvault)Storage‑ und ReplikationsdiensteMonitoring‑ und Alerting‑Systeme

Prinzipien & Ziele

RPO muss geschäftsgetrieben sein und priorisiert Critical Data.RPO ist ein messbarer Sollwert und wird in SLAs dokumentiert.Technische Maßnahmen sollen RPO‑Ziele kosteneffizient unterstützen.
Betrieb
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Unrealistische RPOs führen zu wiederkehrenden SLA‑Verstößen.
  • Fehlende Tests können falsche Sicherheit über RPO‑Erfüllung erzeugen.
  • Kostenexplosion durch Überprovisionierung zur Einhaltung strenger RPOs.
  • RPO gemeinsam mit Fachbereichen und Betrieb definieren.
  • Automatisierte Tests und Monitoring implementieren.
  • RPO‑Anforderungen regelmäßig überprüfen und anpassen.

I/O & Ressourcen

  • Liste kritischer Geschäftsprozesse und zugehöriger Daten
  • Bestehende Backup‑ und Replikationskonfigurationen
  • Kapazitäts‑ und Kostenmodelle
  • Dokumentierte RPO‑Ziele pro Datenklasse
  • Angepasste Backup‑Pläne und SLAs
  • Validierte Testprotokolle zur RPO‑Erfüllung

Beschreibung

Das Recovery Point Objective (RPO) definiert den maximal tolerierbaren Datenverlust in einem Disaster‑Recovery‑Szenario. Es legt fest, bis zu welchem Zeitpunkt Daten wiederhergestellt werden müssen, um Geschäftsprozesse zu sichern. RPO ist Kernbestandteil von Recovery‑Planung und Service‑Level‑Agreements. Organisationen definieren RPO basierend auf Geschäftsanforderungen und technischen Möglichkeiten.

✔

  • Klarheit über akzeptablen Datenverlust und Prioritäten.
  • Fundament für Backup‑ und Replikationsarchitektur.
  • Messbare Vorgabe für Tests und SLAs.

✖

  • Alleinige Fokussierung auf RPO berücksichtigt nicht RTO oder Konsistenz.
  • Strenge RPOs können erhebliche Kosten und Komplexität verursachen.
  • Technische Einschränkungen (Netzwerk, Storage) begrenzen erreichbare RPOs.

  • Erreichtes RPO

    Gemessene Zeitspanne zwischen dem letzten konsistenten Datenpunkt und dem Ausfallzeitpunkt.

  • Backup‑Erfolgsrate

    Anteil erfolgreicher Backup‑Jobs im definierten Zeitraum.

  • Zeit bis zur Verfügbarkeit nach Recovery

    Dauer bis zum Wiederherstellen von Diensten in akzeptablem Zustand nach einem Ausfall.

E‑Commerce: RPO 15 Minuten für Bestelltransaktionen

Ein Online‑Shop definiert 15 Minuten RPO für Bestell‑DBs, um Umsatzausfälle zu minimieren und Chargebacks zu vermeiden.

Behörde: RPO stundenweise für Archivdaten

Für weniger kritische Archivdaten wird ein RPO von mehreren Stunden akzeptiert, um Kosten zu optimieren.

SaaS‑Anbieter: unterschiedliche RPOs pro Kunden‑Tier

Ein SaaS‑Anbieter bietet Premium‑Kunden kürzere RPOs gegen Aufpreis und standardmäßige längere RPOs für Basis‑Pläne.

1

Datenklassifizierung durchführen und kritische Assets identifizieren.

2

RPO‑Ziele pro Daten‑ und Systemklasse definieren.

3

Backup‑ und Replikationsstrategie auswählen und konfigurieren.

4

Regelmäßige Tests planen und Ergebnisse operationalisieren.

⚠️ Technische Schulden & Engpässe

  • Alte Backup‑Tools, die keine inkrementellen Replikationen unterstützen.
  • Nicht getestete Recovery‑Skripte und -Prozesse.
  • Fehlende Automatisierung für regelmäßige RPO‑Validierung.
NetzwerkbandbreiteSpeicherkapazität und IOPSWiederherstellungsfenster und Personalressourcen
  • RPO sehr streng setzen und dann Budgetkürzungen vornehmen.
  • RPO in SLAs aufnehmen, ohne Monitoring zur Kontrolle.
  • Nur auf Backup‑Snapshots vertrauen ohne Konsistenzprüfungen.
  • Verwechslung von RPO und RTO führt zu falschen Zielsetzungen.
  • Annahmen über Netzwerkleistung ohne Messung.
  • Unzureichende Dokumentation der Wiederherstellungsprozesse.
Backup‑ und Storage‑AdministrationskenntnisseKenntnisse in Disaster‑Recovery‑PlanungFähigkeit zur Bewertung von Geschäftsanforderungen
Geschäftskritikalität der DatenCompliance‑ und rechtliche AnforderungenVerfügbare Replikations‑ und Backup‑Technologien
  • • Budget‑Restriktionen für redundante Infrastruktur
  • • Technologische Limitierungen bestehender Systeme
  • • Regulatorische Vorgaben zur Aufbewahrung und Replikation