Disaster‑Recovery‑Playbook für Proxmox: Cluster aus PBS, VM‑Images und Konfiguration wiederaufbauen

Ein Disaster‑Recovery‑Playbook für Proxmox ist für jeden Betriebsverantwortlichen unverzichtbar: Dieses Playbook beschreibt praxisnah, wie Sie ein Proxmox‑Cluster nach Totalverlust oder gravierendem Ausfall mit Proxmox Backup Server (PBS), VM‑Images und Konfigurationsdateien wiederaufbauen. Es richtet sich an Administratoren, System Engineers, Operatoren und technische IT‑Dienstleister und fokussiert auf Betrieb, Schnittstellen, Prüfungen und Rückfallstrategien. Das Fokus‑Keyword Disaster‑Recovery‑Playbook für Proxmox wird in der Einleitung bewusst platziert, weil es die Suchintention und den praktischen Nutzen des Beitrags präzise trifft.

Disaster‑Recovery‑Playbook für Proxmox: Warum ein Playbook und wann es greift

Ein Playbook schafft Klarheit in Stresslagen: Es definiert Reihenfolge, Verantwortlichkeiten, Timing und Prüfungen. Es greift, wenn der produktive Cluster nicht mehr bootet, /etc/pve verloren ist, Corosync kein Quorum findet oder das primäre Storage irreparabel beschädigt wurde. Zentrale Voraussetzung ist, dass Sie gültige PBS‑Backups und Kopien der Cluster‑Konfigurationen (z. B. aus automatisierter Exportroutine) haben.

Begriffsklärung (kurz)

Proxmox VE ist die Virtualisierungsplattform. Proxmox Backup Server (PBS) ist die dedizierte Backup‑Appliance für snapshots/deduplizierte Backups. pmxcfs ist das verteilte Konfigurations‑Dateisystem (control plane config) von Proxmox, Corosync ist das Quorum/Cluster‑Kommunikationslayer. VM‑Konfigurationen liegen in /etc/pve/qemu-server/ (KVM) und /etc/pve/lxc/ (LXC).

Vorbereitung: Voraussetzungen, Rollen und Prioritäten

Bevor Sie mit einem Restore beginnen, klären Sie diese Punkte:

• RTO/RPO pro VM‑Kategorie: Definieren Sie, welche VMs sofort, welche später wiederaufgebaut werden.
• Verfügbare Medien: Zugang zu PBS‑Repository, Archivkopien und ggf. Offsite‑Kopien.
• Rollen: Incident Lead, Storage Operator, Network Operator, PBS‑Operator, App‑Owner.
• Kommunikation: Kanäle, Statusmeldungen und Change‑Freeze‑Regeln während Recovery.

Priorisieren Sie: Starten Sie mit Control‑Plane‑Wiederherstellung, dann Storage, anschließend kritische VMs und zuletzt weniger kritische Systeme.

Erste Analyse: Scope bestimmen

Analysieren Sie den Ausfallumfang systematisch: Hardware tot, pmxcfs beschädigt, Netzwerk‑Partition oder PBS verloren? Prüfen Sie, ob einzelne Nodes erreichbar sind und ob PBS‑Repos per SSH/HTTPS erreichbar sind. Dokumentieren Sie Fundzustand und legen Sie ein Incident‑Log an.

Control‑Plane (pmxcfs/Corosync) wiederherstellen

Die Control‑Plane steuert Cluster‑Konfigurationen. Wenn mindestens ein Node intakt ist, prüfen Sie den Zustand:

pvecm status
systemctl status pve-cluster
systemctl status corosync

Wenn kein Node verfügbar ist, bauen Sie eine neue erste Node (Seed Node) auf. Achten Sie exakt auf Hostname und IP‑Plan, weil Corosync und DNS/Hosts auf konsistente Namensauflösung angewiesen sind. Initialisieren Sie ein Cluster nur, wenn Sie keine andere pmxcfs‑Quelle haben:

pvecm create mycluster

Hinweis: Das Erstellen eines neuen Clusters überschreibt ein existierendes pmxcfs. Wenn Sie eine gesicherte Kopie von /etc/pve oder eine Exportdatei haben, bevorzugen Sie die Rückspielung dieser Daten statt Neuanlage.

pmxcfs aus Backup rekonstruieren

Wenn Sie ein konsistentes Backup von /etc/pve oder eines pmxcfs‑Exports besitzen, spielen Sie diese Dateien auf die Seed‑Node ein. Typisches Vorgehen ist ein tar‑Archiv der /etc/pve‑Struktur, das Sie auf die Seed‑Node kopieren und dann den pve‑Cluster‑Service neu starten:

# auf Seed‑Node
rsync -av --progress /mnt/backup/etc-pve-backup/ /etc/pve/
systemctl restart pve-cluster
systemctl restart corosync

Warum: /etc/pve ist die Control‑Plane; ihre Dateien definieren VM‑IDs, Storage‑Zuordnungen und Netzwerk. Risiken: Inkonsistente Versionsstände oder fehlende Storage‑Aliases können verhindern, dass Nodes korrekt joinen.

Corosync, Quorum und Fencing

Quorum‑Probleme sind häufige Stolperfallen. Vermeiden Sie Split‑Brain, indem Sie Fencing (automatisches Trennen eines Nodes, der aus Sicht des Clusters fehlerhaft ist) testen. Falls Sie ein QDevice (externes Quorum‑Device) nutzen, stellen Sie dessen Erreichbarkeit sicher.

Prüfen Sie Quorum‑Status:

pvecm status
# oder
corosync-cmapctl | head

Wenn ein Node nicht mehr erreichbar ist, entfernen Sie ihn sauber oder passen Sie erwartete Votes an, aber dokumentieren Sie jeden Schritt und halten Sie Rückfallkommandos bereit.

PBS: Zugriff prüfen und Repository wiederherstellen

Stellen Sie sicher, dass PBS‑Repos verfügbar sind. Prüfen Sie Erreichbarkeit, Zertifikate und Benutzerzugänge. Wenn PBS selbst zerstört wurde, installieren Sie PBS neu und synchronisieren Sie die Datastore‑Dateien (rsync oder Storage‑Replica). Kopieren Sie nur Dateien, wenn Sie verstehen, wie PBS interne Datenstrukturen (chunks, indexes) nutzt—ein unvollständiges Kopieren kann Repositories korrumpieren.

# Beispiel: rsync eines PBS‑Datastores (nur, wenn Storage‑Kopie valide ist)
rsync -av --progress /mnt/offsite/pbs-datastore/ /var/lib/proxmox-backup/datastore/

Validierung: Verwenden Sie die PBS‑WebUI oder CLI, um Datastores und Snapshots zu listen, bevor Sie Restores starten.

VM‑Restore‑Strategien und detaillierte Umsetzung

Wählen Sie je nach Situation zwischen drei Wegen:

1. qmrestore: Direktes Einspielen von vzdump‑Archiven, erzeugt VM‑Konfiguration und Datenträger.
2. qm importdisk + qm set: Import roher Disk‑Images und anschließende manuelle VM‑Konfiguration.
3. pct restore: Für LXC‑Container mit Bind‑Mount‑Prüfungen.

qmrestore – Empfehlung für getestete VMs

qmrestore /backup/vzdump-qemu-101-2026_01_01.vma.zst 101 --storage local-lvm
# optional: sofort starten
qm start 101

Gefahren: qmrestore erwartet passende Storage‑IDs. Wenn das Zielstorage anders heißt, erstellen Sie temporäre Storage‑Aliases oder nutzen qm importdisk.

qm importdisk – flexibler bei Storage‑Mapping

qm create 101 --name restored-101 --memory 4096 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 101 vm-101-disk-1.qcow2 local-lvm
qm set 101 --scsi0 local-lvm:vm-101-disk-1
qm set 101 --boot c --bootdisk scsi0

Vorteil: Sie behalten Kontrolle über Thin/Thick‑Pools und Storage‑Typen. Nach dem Import fehlt ggf. die VM‑meta‑Konfiguration (cloud‑init, qemu‑agent). Ergänzen Sie diese manuell oder per Template‑Skript.

Container (LXC) – pct restore

pct restore 102 /backup/vzdump-lxc-102-2026_01_01.tar.lzo --storage local
pct set 102 --net0 name=eth0,bridge=vmbr0,ip=dhcp
pct start 102

Prüfen Sie Bind‑Mounts, AppArmor‑Profile und Privilegien nach dem Restore.

Datenbanken und konsistente Backups

Datenbank‑VMs benötigen sauber abgestimmte Recovery‑Schritte: Entweder haben Sie konsistente Snapshots (quiesced backups) oder Sie führen zusätzliche DB‑Recovery‑Schritte durch (WAL‑Replay, Replikations‑Rebuild). Bei PostgreSQL etwa prüfen Sie WAL‑Segmente und führen gegebenenfalls PITR‑Schritte aus. Für MySQL prüfen Sie Binlog‑Positionen und preferieren, wenn möglich, eine Reinitialisierung der Replikation gegenüber komplexer Binlog‑Reparatur.

Verschlüsselung: LUKS‑Header und Schlüsselmanagement

Wenn Disk‑Volumes verschlüsselt waren, sind LUKS‑Header und Schlüsselmaterial kritisch. Bewahren Sie LUKS‑Header separat auf. Falls Header beschädigt sind, ist der Datenzugriff oft unmöglich. Haben Sie Remote‑Unlock‑Mechanismen (z. B. Network‑Unlocked LUKS oder Schlüssel‑Server) dokumentiert und getestet.

Storage‑Typen: LVM, ZFS, Ceph – Besonderheiten

Jeder Storage‑Typ hat eigene Recovery‑Regeln:

• LVM: Aktivieren Sie Volume‑Groups und überprüfen Sie Thin‑Pools. Nutzen Sie lvdisplay und vgchange -ay.
• ZFS: Importieren Sie Pools mit zpool import -f und prüfen Sie Fehler mit zpool scrub.
• Ceph: Bringen Sie Monitore (MON) zuerst hoch, prüfen Sie ceph -s und stellen Sie OSDs wieder her. Ceph‑Cluster‑Wiederherstellung kann komplex sein; planen Sie ausreichend Zeit ein und folgen Sie Ceph‑Best‑Practices.

# Beispiel: LVM aktivieren
vgchange -ay
lvdisplay
# Beispiel: Ceph Status prüfen
ceph -s

Konfigurationskonflikte: Storage‑IDs, MACs und Netzwerke

Häufige Probleme nach Restore sind Storage‑ID‑Mismatch und duplizierte MAC‑Adressen. Prüfen Sie /etc/pve/qemu-server/*.conf auf veraltete Storage‑Bezeichner und passen Sie sie an. Beispiel einer VM‑conf (Auszug):

# /etc/pve/qemu-server/101.conf
boot: cdn
cores: 4
memory: 4096
scsi0: local-lvm:vm-101-disk-1,size=50G
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0

Wenn MAC‑Adressen Konflikte verursachen, ändern Sie sie vor dem Boot und dokumentieren Sie Anpassungen. Nutzen Sie qm set zur Änderung statt direkter Datei‑Manipulation, wenn möglich.

Validation und Smoke‑Tests (detailliert)

Validierung ist nicht optional. Für jede wiederhergestellte VM führen Sie mindestens durch:

1. Serielle Konsole/Boot‑Log auf Kernel‑Errors kontrollieren (GUI/Web oder qm monitor).
2. Netzwerktests: ping, traceroute, DNS‑Auflösung und Port‑Checks.
3. Applikations‑Smoke: HTTP/HTTPS‑Health, DB‑Verbindungstests, Hintergrund‑Jobs prüfen.
4. Datenintegrität: Prüfsummen wichtiger Verzeichnisse oder Anwendungschecks (z. B. SELECT COUNT(*) für Tabellen mit Referenzwert).

# Beispiel Smoke‑Test
ssh admin@vm-ip 'systemctl is-active postgresql && curl -sfS http://localhost:8080/health'
# Prüfsummevergleich
ssh admin@vm-ip 'sha256sum /var/lib/app/data/important.db | cut -d" " -f1'

Automatisierung und Skripte: robust, idempotent und auditiert

Automatisieren Sie wiederkehrende Tasks, aber nicht kritische Entscheidungen. Ein idempotentes Bash‑Skript für Batch‑Restore reduziert Fehler, protokolliert Schritte und erlaubt kontrollierte Ausführung. Beispiel (erweitert):

#!/bin/bash
# batch_restore_checked.sh
set -euo pipefail
MAPFILE=${1:-restore-map.csv}
LOG=/var/log/proxmox-recovery.log
exec &> >(tee -a "$LOG")
while IFS=, read -r backup vmid storage ; do
  echo "[INFO] Restoring $backup to VM $vmid on $storage"
  if [ ! -f "$backup" ]; then
    echo "[WARN] Backup $backup missing, skipping"
    continue
  fi
  # Quick storage check
  if ! pvesm status | grep -q "$storage" ; then
    echo "[ERROR] Storage $storage not present, aborting for $vmid"
    continue
  fi
  qmrestore "$backup" "$vmid" --storage "$storage" || { echo "[ERROR] qmrestore failed for $vmid"; continue; }
  echo "[OK] Restore triggered for $vmid"
done < "$MAPFILE"

Rückfallstrategie: Was, wenn Restore scheitert?

Haben Sie einen Plan B: Falls Restores fehlschlagen, können Sie:

• VMs manuell neu provisionieren (Installer + Datenimport) für geschäftskritische Dienste.
• Auf Read‑Only‑Replikate oder alte Snapshots zurückgreifen.
• Netzwerk/Security‑Einstellungen temporär lockern, wenn sie den Boot verhindern (z. B. Firewall Regeln).

Wichtig ist, Zeitlimits und Entscheidungspunkte zu definieren: Nach X Stunden Recovery wechselt Incident Lead zu Plan B, um Gesamt‑RTO einzuhalten.

Hyper‑V‑Spezialsektion: Transferierbare Lessons

Auch wenn dieses Playbook Proxmox fokussiert, lassen sich einige Prinzipien auf Hyper‑V übertragen. Bei Hyper‑V sind VHD(X)‑Exporte, der Zustand der Hyper‑V‑Konfiguration (Export/Import) und die Hyper‑V‑Hosts (Failover Cluster) kritisch. Wichtig sind: konsistente VM‑Exports, Prüfen von CSV/NAS/SMB‑Mounts und Netzwerkmapping (vSwitch). Testen Sie Import/Attach‑Workflows in einer Preprod‑Umgebung, bevor Sie im Notfall darauf angewiesen sind.

Post‑Recovery: Härtung, Lessons Learned, Dokumentation

Nach dem Restore führen Sie eine Post‑Mortem‑Analyse durch, dokumentieren Änderungen und justieren Backups, Tests und Verantwortlichkeiten. Passen Sie RTO/RPO an realistische Messwerte aus dem Drill an und planen Sie Folge‑Drills, um regressionsfrei zu bleiben.

Praxis‑Checkliste (kompakt)

1. Scope & Prioritäten definieren.
2. Control‑Plane rekonstruieren (pmxcfs/corosync) oder Seed‑Node anlegen.
3. PBS‑Repository prüfen / wiederherstellen.
4. Storage‑Targets einbinden (LVM/ZFS/Ceph prüfen).
5. VMs selektiv mit qmrestore/qm importdisk/pct restore wiederherstellen.
6. Datenbank‑Recovery (WAL/Binlog/PITR) durchführen.
7. Smoke‑Tests, Integritätsprüfungen und Applikationschecks.
8. Lessons Learned dokumentieren und Follow‑Up planen.

Fazit

Ein belastbares Disaster‑Recovery‑Playbook für Proxmox ist mehr als eine Sammlung von Kommandos: Es ist ein operatives Dokument mit Prioritäten, Rollen, Prüfungen und Rückfallstrategien. Testen Sie regelmäßig, halten Sie pmxcfs‑Exports und PBS‑Zugänge aktuell und automatisieren Sie Unterstützungs‑Checks, nicht aber kritische Recovery‑Entscheidungen. So reduzieren Sie RTO und vermeiden teure Fehler im Ernstfall.

Diese Anleitung ist als modulare Ergänzung Ihrer Betriebsdokumentation gedacht. Passen Sie sie an Ihre Storage‑Topologie, RTO/RPO‑Vorgaben und internen Kommunikationswege an und führen Sie regelmäßige Restore‑Drills durch.

Integrationen, Secrets und Betriebsaspekte

Oft unterschätzt: Netz‑ und Infrastruktur‑Integrationen entscheiden, ob ein Restore tatsächlich produktiv wird. Stellen Sie zuerst zentrale Infrastrukturen wieder her—DNS, DHCP, NTP und PKI—bevor Sie Anwendungsschichten hochfahren. Fehlt DNS, booten VMs zwar, sind aber für Services unauffindbar; fehlende Zeitstempel (NTP) kann Datenbankreplikation zerstören.

Sichern Sie Schlüsselmaterial und Zertifikate getrennt vom PBS und dokumentieren Sie Unseal/Unlock‑Prozeduren (z. B. HashiCorp Vault, KMIP). Externe Secrets‑Stores sollten im Playbook mit expliziten Zugriffstests auftauchen.

Praktischer Hinweis: Schalten Sie Monitoring‑Alarme temporär auf „maintenance“, um Alarmfluten zu vermeiden, und re‑registrieren Sie Hosts gezielt nach erfolgreichen Smoke‑Tests. Für Multi‑Tier‑Anwendungen planen Sie koordinierte Snapshot/Restore‑Fenster, damit Datenbank und App konsistent bleiben.

Auditieren Sie jeden Recovery‑Schritt: Logs, Checksummen, Versionsstände und wer Änderungen freigibt — so wird das Playbook betriebssicher und organisatorisch belastbar.

Für dieses Thema sind auch Vm-Images Wiederherstellen und Proxmox Cluster Recovery wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.