# Proxmox Disaster Recovery: Strategien für minimale RTO & RPO

TL;DR / Management Summary Ein erfolgreiches Disaster Recovery wird nicht durch Glück, sondern durch Architektur bestimmt. Wir optimieren das RPO (Recovery Point Objective) durch den Einsatz von ZFS Replication (sekundengenaue Spiegelung) und minimieren das RTO (Recovery Time Objective) durch den Proxmox Backup Server (PBS) Live-Restore. Ein Senior Admin balanciert dabei zwischen Kosten und Ausfallrisiko und automatisiert die Wiederherstellungs-Kette, um im Ernstfall menschliche Fehler auszuschließen.

# 1. Die Kennzahlen verstehen

Was das Business fordert.

RPO (Datenverlust): “Wie viel Arbeit darf nach einem Crash weg sein?”
- Ziel: 15 Minuten.
- Technik: ZFS Replication (Artikel 686).
RTO (Ausfallzeit): “Wann müssen die User wieder arbeiten können?”
- Ziel: 30 Minuten.
- Technik: Live-Restore und HA-Fencing (Artikel 692).

# 2. RPO-Optimierung: Datenverlust minimieren

Vom täglichen Backup zum Echtzeit-Spiegel.

Level 1: Tägliches Backup (RPO 24h).
Level 2: Stündliches PBS-Backup (RPO 1h).
Level 3: ZFS Replication alle 1-5 Minuten (RPO < 5 Min).
Level 4: Ceph Multi-Site Replikation (RPO fast 0).

# 3. Deep Dive: RTO-Optimierung: Den Restore beschleunigen

Sekunden statt Stunden.

Das größte Hindernis für ein niedriges RTO ist die Datenübertragung.

Live-Restore (PBS Feature): Die VM wird sofort gestartet. Fehlende Datenblöcke werden “on-demand” vom Backup-Server geladen, während im Hintergrund der Full-Restore läuft.
Snapshot-Rollback: Wenn nur das OS korrupt ist, dauert ein Rollback auf einen lokalen ZFS-Snapshot nur Millisekunden – unabhängig von der Datenmenge.

# 4. Day-2 Operations: Automatisierte DR-Orchestrierung

Der ‘rote Knopf’.

Erstellen Sie eine DR-Pipeline (z.B. via Ansible):

Trigger: Standort-Ausfall erkannt.
Action:
1. Umschalten der DNS-Einträge via API (Artikel 581).
2. Promoten der ZFS-Replikas auf Standort B.
3. Starten der VMs in der korrekten Reihenfolge (Artikel 695).

# 5. Troubleshooting & “War Stories”

Wenn die Zeit gegen einen arbeitet.

# Top 3 Fehlerbilder

Symptom: Restore dauert viel länger als berechnet.
- Ursache: Das Backup-Netzwerk ist mit 1 Gbit zu langsam für einen Massen-Restore.
- Lösung: Upgrade auf 10G oder 25G für Backup-Targets.
Symptom: Datenkorruption nach schnellem Rollback.
- Ursache: Applikation im Gast (SQL) wurde nicht sauber “eingefroren” (Quiesced).
- Fix: Guest Agent zwingend nutzen (Artikel 672).
Symptom: RPO-Verletzung durch hängende Replikations-Jobs.

# “War Story”: Der “Optimierte” Daten-Gau

Ein Admin setzte das RPO auf 1 Minute via ZFS Replication. Er verzichtete auf tägliche Backups (“Spiegelung ist ja sicher”). Das Ereignis: Ein User löschte versehentlich den Haupt-Ordner auf dem Fileserver. Das Ergebnis: Genau 60 Sekunden später wurde der Löschbefehl an den DR-Standort repliziert. Das Spiegelbild war nun an beiden Orten leer. Da kein echtes Backup existierte, waren die Daten für immer weg. Lehre: Replikation schützt vor Hardware-Ausfall, aber Backups schützen vor logischen Fehlern. Ein niedriges RPO durch Replikation entbindet Sie niemals von der Pflicht eines versionierten Backups mit langer Retention.

# 6. Monitoring & Reporting

Die DR-Bereitschaft messen.

# RTO/RPO Scorecard

Erstellen Sie monatlich einen Bericht:

Avg. Replication Lag: Ist mein RPO-Versprechen haltbar?
Last Successful Restore Test: Wurde die RTO-Zeit erreicht? (Artikel 640).

# 7. Fazit & Empfehlung

Optimieren Sie für den Restore, nicht für das Backup.

Empfehlung: Investieren Sie in NVMe-SSDs für Ihre Backup-Server. Die Lesegeschwindigkeit des Backups bestimmt Ihr RTO.
Wichtig: Automatisieren Sie den Netzwerk-Schwenk (DNS/BGP). Ein Server, der in der Cloud läuft, aber nicht erreichbar ist, zählt nicht als “wiederhergestellt”.

# Anhang: Die DR-Leistungsklassen

Klasse	RPO	RTO	Kosten
Bronze	24h	8h	Gering (NFS)
Silber	1h	2h	Mittel (PBS)
Gold	5 Min	15 Min	Hoch (ZFS Repl)
Platin	< 1 Sek	< 1 Min	Extrem (Multi-Site Ceph)