# RPO & RTO – Die Metriken, die entscheiden, ob Ihr Job überlebt

TL;DR / Management Summary RPO (Recovery Point Objective) definiert den maximal akzeptablen Datenverlust (Zeitraum), RTO (Recovery Time Objective) die maximal akzeptable Ausfallzeit (Wiederherstellungszeit). Diese Kennzahlen sind keine IT-Werte, sondern Geschäftsentscheidungen. Sie müssen durch technische Implementierung (Replikationstyp, Backup-Frequenz) und rigorose, automatisierte DR-Tests validiert werden. Vernachlässigen Sie RPO/RTO und Sie liefern im Ernstfall nicht das, was das Business erwartet.

# 1. Einführung & Architektur

RPO und RTO sind die Eckpfeiler jedes Business Continuity Plans (BCP) und jeder Disaster Recovery (DR) Strategie. Für uns als Architekten und Betreiber sind sie der primäre Treiber für die Wahl zwischen synchroner Replikation, asynchroner Replikation oder traditionellen nächtlichen Backups.

# Warum brauchen wir das?

Das zentrale Problem ist die Diskrepanz zwischen der technischen Machbarkeit (ein Backup ist vorhanden) und der geschäftlichen Anforderung (der Service muss in X Minuten wieder laufen, mit maximal Y Datenverlust).

• Problemstellung aus der Praxis: Ein einfaches Backup alle 24 Stunden ergibt ein RPO von 24 Stunden. Wenn das Business nur 1 Stunde Datenverlust (RPO = 1h) toleriert, ist die Strategie unzureichend, und die SLA ist verletzt.
• Fehlerhafte Metrikfokussierung: Viele Admins fokussieren sich auf die Backup-Erfolgsrate. Die richtige Metrik ist die Recovery-Erfolgsrate, gemessen an der Einhaltung von RPO und RTO.

# Architektur-Diagramm (Konzeptueller Fluss)

RPO und RTO definieren die notwendige Distanz (RPO) und die Geschwindigkeit (RTO) zwischen der aktiven Produktion und der Bereitschaft des Wiederherstellungssystems.

graph TD
    A["Business Impact Analysis (BIA)"] --> B("Definition der Service Tiers: Tier 0 - Tier 4")
    B --> C{"RPO/RTO Targets festlegen"}

    C --> D1["RPO-Strategie: Minimierung Datenverlust"]
    C --> D2["RTO-Strategie: Minimierung Ausfallzeit"]

    D1 --> E1{"Implementierung RPO: Sync/Async Replication, CDC, Snapshot-Frequenz"}
    D2 --> E2{"Implementierung RTO: Automated Failover Runbook, DR Orchestration, Idempotenz"}

    E1 --> F["Kontinuierliches Monitoring & DR Testing"]
    E2 --> F
    F --> G("Erfüllung der Business Continuity")

# Kernel-Sicht und Block Layer (RPO-Implementierung)

Obwohl RPO/RTO keine direkten Kernel-Objekte sind, werden sie tief im System implementiert:

• RPO und das I/O Subsystem: Systeme, die ein RPO von wenigen Sekunden benötigen (Tier 0), nutzen synchrone oder quasi-synchrone Replikation. Dies bedeutet, dass die I/O-Bestätigung (Commit) auf dem primären Host erst erfolgt, nachdem der Block auch beim Remote-Partner geschrieben wurde. Dies wird auf dem Storage-Level (z.B. SAN-Replikation) oder auf dem Dateisystem-Level (z.B. DRBD im Protocol C) realisiert und hat direkten Einfluss auf die Latenz des Hosts.
• RTO und Boot-Priorität: RTO hängt von der Geschwindigkeit ab, mit der die Anwendungsschicht wieder verfügbar ist. Moderne Orchestrierungssysteme (Kubernetes, VMWare SRM, AWS CloudFormation) müssen in Sekunden entscheiden, welche Systeme zuerst hochfahren, um die Kette der Abhängigkeiten (Datenbanken, Middleware, App-Server) einzuhalten.

# 2. Definition & Grundkonfiguration (Praxis)

Wir “installieren” RPO und RTO nicht, sondern wir definieren und implementieren sie in der Infrastruktur.

# Voraussetzungen

1. Business Impact Analysis (BIA): Das Fundament. Welche Prozesse sind kritisch? Wie hoch ist der finanzielle Schaden pro Stunde Ausfall?
2. Service Criticality Matrix: Klassifizierung der Anwendungen (Tier 0/1/2/3).
3. Ressourcenallokation: RPO/RTO sind teuer. Tier 0 (RPO < 5s, RTO < 30m) benötigt hochverfügbare, teure synchrone Lösungen und dedizierte DR-Hardware.

# Schritt-für-Schritt Setup (Der “Happy Path” der Definition)

Der Admin muss verstehen, dass er die technischen Parameter so konfigurieren muss, dass sie die Business-Ziele erreichen.

Die RPO-Formel in der Praxis: Die effektive RPO ist immer größer als das Backup-Intervall, da die Wiederherstellung eines Systems selbst Zeit kostet.

$$ RPO_{effektiv} = \text{Letztes gültiges Daten-Commit} + \text{Replikationsverzögerung} + \text{Datenbank-Recovery-Zeit} $$

# Beispiel: Konfiguration des Replication Lag für RPO-Einhaltung (PostgreSQL Example)
# Ziel: RPO von max. 10 Minuten. Die Replikation MUSS schneller sein.

# Prüfen des aktuellen Replication Lag (Metrik für RPO-Überwachung)
psql -c "SELECT client_addr, pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS lag_bytes FROM pg_stat_replication;"

# Wenn der Lag (lag_bytes) kontinuierlich steigt und sich dem maximalen RPO-Ziel nähert,
# sind die E/A-Ressourcen für die Replikation unzureichend konfiguriert
# oder die Bandbreite ist gesättigt.

# Tuning-Parameter, um RPO zu verbessern (durch Reduzierung der maximalen Verzögerung)
# In postgresql.conf:
wal_sender_timeout = '30s'         # Stoppt Sende-Prozesse, wenn zu lange inaktiv (schützt vor Zombie-Prozessen)
max_standby_streaming_delay = '60s' # Maximale Verzögerung, bevor ein Konflikt gemeldet wird (direkt an RPO gekoppelt)

# 3. Deep Dive: Konfiguration für Profis

Das Erreichen anspruchsvoller RPO/RTO-Ziele ist ein Engineering-Problem, kein reiner Administrations-Task.

# Performance Tuning (Fokus auf RTO/RPO-Engpässe)

# RPO Optimierung (Replikation)

• Write Latency Trade-off: Bei synchroner Replikation (RPO ≈ 0) steigt die Write Latency der primären Anwendung. Dies muss im SLA-Tuning berücksichtigt werden.
• WAN Optimierung: Bei asynchroner Replikation über weite Strecken (DR-Site in einem anderen Kontinent) müssen wir Latenz durch Kompression (z.B. ZFS Send/Receive, Veeam WAN Accelerator) und Deduplizierung minimieren, um den Backlog (Replication Lag) zu verhindern.

# RTO Optimierung (Recovery Time)

• Idempotente Runbooks: Der größte RTO-Killer ist der manuelle Eingriff oder nicht-idempotenter Code. Das Failover-Runbook (Ansible, Chef, Salt) muss in jeder Phase wiederholbar sein und den Zustand schnell validieren können.
• Network Provisioning: Die Zeit, die benötigt wird, um DNS-Einträge, Load Balancer und Firewall-Regeln auf der DR-Seite anzupassen, dominiert oft die RTO. Automatisierung (IaC) ist hier zwingend notwendig.

# Hardening & Security (RTO und Cyber Resilience)

Die Einhaltung von RPO/RTO ist wertlos, wenn der Wiederherstellungspunkt selbst kompromittiert ist.

• Air-Gapped Recovery: Für kritische RTO-Szenarien nach Ransomware-Angriffen muss die Recovery-Umgebung (oder zumindest das Archiv-Backup) air-gapped sein, d.h., sie darf im Normalbetrieb keine Netzwerkverbindung zur Produktionsumgebung haben.
• Immutability (Unveränderlichkeit): Moderne Storage-Lösungen (S3 Object Lock, Immutable Snapshots) garantieren ein RPO, das nicht durch einen Angreifer manipuliert werden kann.
• Verschlüsselung: Daten im Transit (Replikation) und im Ruhezustand (DR-Speicher) müssen verschlüsselt sein. Dies erhöht zwar theoretisch die RTO minimal (durch Entschlüsselungszeit), ist aber kritisch für die Datenintegrität.

# 4. Day-2 Operations: Wartung & Alltag

DR-Pläne sind veraltet, sobald sie gedruckt werden. Wartung und rigorose Tests sind der Schlüssel zur Einhaltung von RPO/RTO.

# Typische Tasks

• DR-Drills (Recovery Tests): Jährlich, mindestens einmal unangekündigt. Dies ist der einzige Weg, die RTO realistisch zu messen. Wenn die tatsächliche Wiederherstellungszeit 8 Stunden beträgt, muss die RTO von 4 Stunden auf 8 Stunden korrigiert oder die Implementierung drastisch verbessert werden.
• Target Adjustment: Wenn das Datenvolumen (TCO) steigt oder neue, kritische Services hinzukommen, muss der RPO/RTO-Target neu evaluiert werden. Wenn der Replikationskanal gesättigt ist, steigt der RPO-Lag.

# Automatisierung (Ansible/Terraform)

Die RTO wird durch die Automatisierung des Failover-Prozesses erreicht. Wir nutzen IaC, um die Infrastruktur auf der DR-Seite identisch und schnell hochzufahren.

# Ansible Playbook Snippet: Orchestrierung des Failover-Prozesses (RTO-Implementierung)
---
- name: Disaster Recovery Failover Execution
  hosts: dr_site
  gather_facts: false
  vars:
    target_env: "production"

  tasks:
    - name: 1. Ensure DR Database is promoted (Critical RTO Step)
      community.postgresql.postgresql_replication_promotion:
        data_directory: /var/lib/postgresql/14/data
        promote_cluster: true
        fail_on_error: true
      tags: db_promotion

    - name: 2. Provision necessary networking (RTO: DNS/Firewall changes)
      ansible.builtin.include_role:
        name: network_config
        tasks_from: dr_switch_ip

    - name: 3. Deploy Application Stack (Web/App Servers)
      community.docker.docker_compose:
        project_src: /opt/app/{{ target_env }}
        state: present
      tags: app_deployment

    - name: 4. Final Health Check (Validating RTO)
      ansible.builtin.wait_for:
        port: 8080
        host: "{{ inventory_hostname }}"
        state: started
        timeout: 60
      delegate_to: localhost

# 5. Troubleshooting & “War Stories”

Die größten Misserfolge bei RPO/RTO treten nicht während des normalen Betriebs auf, sondern im Stress eines tatsächlichen Desasters.

# Top 3 Fehlerbilder

# 1. Symptom A: RTO-Verletzung durch nicht-getestete Abhängigkeiten

• Fehlermeldung: Im Testlauf stoppt das Failover-Skript bei der Datenbankverbindung (Timeout).
• Ursache: Der primäre App-Server war abhängig von einem alten, nicht-dokumentierten LDAP-Server, der nicht in den DR-Plan aufgenommen wurde. Die App kommt hoch, kann sich aber nicht authentifizieren.
• Lösung: Sorgfältige BIA und Abhängigkeitskartierung (CMDB-Abgleich). Das Runbook muss diese kritischen (aber stillen) Dienste zuerst reanimieren.

# 2. Symptom B: Kontinuierlicher RPO-Anstieg (Replication Lag)

• Symptom: Das Monitoring zeigt, dass der Replikations-Backlog stetig wächst, besonders nach der Spitzenlastzeit.
• Analyse: Das primäre System erzeugt mehr I/O-Änderungen (Change Rate) pro Minute, als die verfügbare WAN-Bandbreite verarbeiten kann.
• Lösung: Achtung: Eine temporäre Erhöhung der Bandbreite ist teuer. Oft hilft nur das Umschalten auf eine Block-Level-Replikationsmethode, die effizienter mit Kompression/Deduplizierung arbeitet (z.B. ZFS, Zerto) oder eine Reduzierung des RPO-Ziels, wenn das Business die Kosten für mehr Bandbreite ablehnt.

# 3. Symptom C: Falsche Recovery Point Selection

• Anekdote (War Story): Ransomware Recovery Wir mussten nach einem Ransomware-Angriff die gesamte Umgebung wiederherstellen. Das RPO war 1 Stunde (gesichert durch stündliche Snapshots). Die RTO betrug 4 Stunden. Wir stellten den letzten Snapshot wieder her, aber die Anwendung war sofort wieder verschlüsselt. Ursache: Die Malware hatte sich 48 Stunden lang in der Umgebung ausgebreitet, bevor sie ausgelöst wurde. Wir stellten immer wieder infizierte Punkte her.
  • Lösung: RPO muss neu definiert werden als: Time since last verified, clean data snapshot. Dies zwang uns, bis zu 7 Tage zurückzugehen, was eine RPO-Verletzung bedeutete, aber die einzige Chance auf eine saubere Wiederherstellung war. Lektion: RPO schützt vor Datenverlust, nicht vor Datenkorruption.

# Recovery Szenarien (Die RTO-Feuerprobe)

graph TD
    A["Disaster Event Detected"] --> B{"Failover Initiated?"}

    B -- "Yes" --> C["Automated DR Runbook Start"]
    B -- "No" --> D["Manual Validation & Approval"]

    C --> E{"Check DB Status: RPO Met?"}
    E -- "No (Lag too high)" --> F["Stop: Data Loss Unacceptable"]
    E -- "Yes" --> G["Promote DB (Primary)"]

    G --> H["Application Stack Deployment"]
    H --> I["Network/DNS Switch"]

    I --> J{"Health Check OK?"}
    J -- "No" --> K["Troubleshoot: RTO Clock Running!"]
    J -- "Yes" --> L["Service Restored (RTO Achieved)"]

# 6. Monitoring & Alerting

RPO/RTO dürfen keine statischen Werte sein. Sie müssen kontinuierlich überwacht werden, da Infrastrukturänderungen sie dynamisch beeinflussen.

# Metriken

Die Metriken müssen den Abstand zum Schwellenwert messen.

# Alerting-Regeln

Wir definieren kritische RPO- und RTO-Verletzungen:

• RPO Critical Alert: Wenn der Replication Lag 90% des definierten RPO-Ziels überschreitet (z.B. RPO ist 1 Stunde; Lag ist 54 Minuten). Dies erfordert sofortiges Eingreifen, da ein Ausfall in diesem Zustand das Business-Ziel verfehlen würde.
• RTO Alert (Operational): Wenn das automatische Failover-Runbook (Ansible/Terraform) im Test 50% länger dauert als erwartet. (Wenn RTO 30 Minuten ist, aber der Test 45 Minuten braucht).

# Prometheus Alerting Rule (Conceptual for Replication Lag)
groups:
- name: rpo_alerts
  rules:
  - alert: HighReplicationLag
    expr: replication_lag_seconds{job="postgres_dr"} > 540  # 9 minutes (90% von RPO 10m)
    for: 5m
    labels:
      severity: critical
      rpo_target: 600s
    annotations:
      summary: "RPO für Tier 1 Datenbank ist in Gefahr. Replication Lag überschreitet 90% des Ziels."

# 7. Fazit & Empfehlung

RPO und RTO sind die wahren Maßstäbe für die Resilienz einer Infrastruktur. Als Senior Engineers müssen wir die Business-Anforderungen in harte, messbare technische Implementierungen übersetzen.

Wann würde ich es nicht einsetzen? RPO/RTO-Analysen sind immer relevant. Die Frage ist die Granularität. Für nicht-kritische, statische Inhalte (z.B. Archiv-Webseiten, interne Wikis mit geringem Änderungs-Rate) ist die Investition in niedrige RPO/RTO-Ziele unnötig. Hier reicht eine RTO von 72 Stunden und ein RPO von 7 Tagen. Verschwenden Sie keine teure synchrone Replikation für statische Assets.

Ausblick Der Trend geht zur Cyber Resilience, die die Wiederherstellung nicht nur nach Hardware-Ausfällen, sondern auch nach logischen Fehlern und Cyber-Angriffen (Ransomware) umfasst. Dies erfordert die Integration von RPO/RTO-Zielen mit unveränderlichen Speichern und automatisierten, isolierten Recovery-Umgebungen (Clean Room Recovery). Künftige Versionen werden zunehmend KI-basierte Validierung nutzen, um die RTO-Drills permanent und ohne menschliches Zutun durchzuführen.

# Anhang: Cheatsheet

# Referenzen

• ISO 22301 (Societal security – Business continuity management systems)
• SANS Institute: Critical Controls for Disaster Recovery Planning
• PostgreSQL Documentation: Write Ahead Log (WAL) and Streaming Replication
• Upstream Documentation zu den verwendeten DR Orchestration Tools (VMware SRM, Zerto, AWS DR)