Disaster Recovery testen — Restore-Prozesse die wirklich funktionieren

Die unbequeme Wahrheit: Die meisten Backups werden nicht regelmäßig getestet. Und die meisten Restore-Versuche im Ernstfall dauern länger als erwartet — weil Prozesse fehlen, Zugangsdaten weg sind oder der Encryption-Key nur einem einzigen Mitarbeiter bekannt war.

Was getestet werden muss

Drei Szenarien, aufsteigend nach Schwere:

1. Single-VM-Restore: Eine VM aus dem Backup wiederherstellen. Häufigste Situation — Datenverlust, versehentliches Löschen.
2. Node-Ausfall: Ein Proxmox-Host fällt aus, VMs müssen auf anderem Node weiterlaufen.
3. Kompletter Cluster-Verlust: Alle Nodes weg, Restore aus PBS auf neue Hardware.

Szenario 1: Single-VM-Restore

# VM aus Backup wiederherstellen
qmrestore /mnt/pbs/vm/100/2026-06-01T02:00:00Z.img 100 \
  --storage local-lvm \
  --unique 1  # Neue MAC-Adresse vergeben

# Oder direkt von PBS
proxmox-backup-client restore \
  --repository backup@pbs@10.20.0.50:prod-backups \
  vm/100/2026-06-01T02:00:00Z \
  vm.img \
  --keyfile /etc/pve/priv/backup-encryption.key

# Als neue Test-VM (VMID 900) restaurieren
qmrestore backup:vm/100/2026-06-01T02:00:00Z 900 \
  --storage local-lvm

Messung: Zeit von Restore-Start bis VM erreichbar → das ist dein RTO für Single-VM.

Szenario 2: Node-Ausfall

Bei HA-Cluster übernehmen verbleibende Nodes automatisch. Testen:

# HA-Status prüfen
ha-manager status

# Node simuliert ausfallen (auf dem Node der "ausfällt"):
systemctl stop pve-cluster corosync

# Auf verbleibendem Node: HA-Failover beobachten
ha-manager status
# VMs sollten nach ~30 Sekunden auf anderem Node starten

# Node wieder einbinden
systemctl start corosync pve-cluster
pvecm updatecerts

Szenario 3: Kompletter Cluster-Verlust

# 1. Frisches Debian + PBS installieren (wie in Artikel 7)
# 2. Backup-Daten verfügbar machen (Off-Site-Restore aus S3)
# 3. Encryption-Key bereitstellen (Paper-Key oder Passwort-Manager)

# Snapshot-Liste anzeigen
proxmox-backup-client snapshot list \
  --repository backup@pbs@<neue-pbs-ip>:prod-backups \
  --keyfile /tmp/restored-encryption.key

# Frischer Proxmox-Host: VM restoren
qmrestore backup:vm/100/2026-06-01T02:00:00Z 100 \
  --storage local-lvm

Restore-Tests automatisieren

#!/bin/bash
# /usr/local/bin/test-restore.sh

VMID=100
TEST_VMID=900
STORAGE="local-lvm"
PBS_REPO="backup@pbs@10.20.0.50:prod-backups"
KEY="/etc/pve/priv/backup-encryption.key"
LOG="/var/log/restore-test.log"

echo "$(date): Starte Restore-Test für VM ${VMID}" >> $LOG

# Neuestes Backup finden
SNAPSHOT=$(proxmox-backup-client snapshot list \
  --repository $PBS_REPO \
  --output-format json | \
  jq -r "[.[] | select(.\"backup-id\" == \"${VMID}\")] | sort_by(.\"backup-time\") | last | .\"backup-time\"")

# Test-VM löschen falls vorhanden
qm destroy $TEST_VMID --purge 2>/dev/null

# Restore
qmrestore ${PBS_REPO}:vm/${VMID}/${SNAPSHOT} $TEST_VMID \
  --storage $STORAGE \
  --unique 1

# VM starten und Erreichbarkeit prüfen
qm start $TEST_VMID
sleep 60

if ping -c 3 10.10.1.100 &>/dev/null; then
  echo "$(date): Restore-Test ERFOLGREICH" >> $LOG
else
  echo "$(date): Restore-Test FEHLGESCHLAGEN — Alarm!" >> $LOG
fi

# Test-VM aufräumen
qm stop $TEST_VMID
qm destroy $TEST_VMID --purge

# Wöchentlich sonntags um 06:00
echo "0 6 * * 0 root /usr/local/bin/test-restore.sh" > /etc/cron.d/restore-test

RTO und RPO definieren

RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel?
→ Backup alle 24h = RPO max. 24h

RTO (Recovery Time Objective): Wie lange darf der Restore dauern?
→ Single-VM: 30 Minuten
→ Node-Ausfall (HA): 5 Minuten automatisch
→ Vollständiger Cluster-Verlust: 4 Stunden

DR-Runbook Template

# Disaster Recovery Runbook — Proxmox

**Letzte Überprüfung:** YYYY-MM-DD
**Verantwortlich:** [Name]

## Zugangsdaten (im Tresor aufbewahren)
- PBS-Admin-Passwort: → Passwort-Manager
- Encryption-Key: → Passwort-Manager + Tresor (Paper-Key)
- Proxmox-Root-Passwort: → Passwort-Manager

## Szenario A: Single-VM-Restore
1. PBS-Webinterface öffnen: https://10.20.0.50:8007
2. Datastore → prod-backups → VM auswählen
3. "Restore" → Ziel-Host → Ziel-VMID wählen
4. Encryption-Key eingeben
5. Restore starten → ca. 20-30 Minuten
6. VM starten und Erreichbarkeit prüfen

## Szenario B: Node-Ausfall
1. HA-Status prüfen: `ha-manager status`
2. Abwarten bis Failover abgeschlossen (max. 2 Minuten)
3. Wenn kein Auto-Failover: `ha-manager migrate vm:100 --node pve02`
4. Ausgefallenen Node reparieren oder ersetzen
5. Node rejoinen: `pvecm add 10.0.0.10`

## Szenario C: Kompletter Cluster-Verlust
1. Neues PBS auf Backup-Hardware installieren
2. Off-Site-Daten wiederherstellen
3. Encryption-Key aus Tresor bereitstellen
4. Neuen Proxmox-Host installieren
5. PBS einbinden und VMs nach Priorität restoren

Die wichtigste Erkenntnis

Ein DR-Plan ist nur so gut wie sein letzter Test. Quartalsweise einen vollständigen Restore-Test durchführen — nicht nur den automatisierten Weekly-Test, sondern einen bei dem ein Mensch den Prozess durchgeht und die Runbook-Schritte validiert. Umgebungen ändern sich, Passwörter rotieren, Hardware wird getauscht. Der Ernstfall ist der falsche Zeitpunkt, das herauszufinden.