Host-Wiederanlauf vorbereiten: Proxmox Disaster Recovery umfasst die Planung des Wiederanlaufs. Ein Restore-Test prüft den ausdrücklich vereinbarten Umfang. Erstgespräch.
Wer einen PVE-Host mit PBS wiederherstellen will, muss zwei Ebenen unterscheiden: die Proxmox-Installation mit ihrer Konfiguration und die darauf betriebenen Gäste. Ein erfolgreicher VM-Backup-Job sichert nicht automatisch beide Ebenen. Der Artikel enthält ein Beispiel für die Host-Sicherung und die Reihenfolge nach einem Ausfall. Stand: Oktober 2026.
Inhalt
- Vor dem Ausfall sichern
- Beispiel: Host-Dateien mit dem Backup-Client sichern
- Reihenfolge nach einem Hostausfall
- Ausfall eingrenzen und Ziel vorbereiten
- Hostkonfiguration kontrolliert wiederherstellen
- Gäste aus PBS wiederherstellen
- Cluster-Ersatz gesondert behandeln
- Abnahme dokumentieren
- Quellen
Vor dem Ausfall sichern
Die PVE-Backup-Funktion sichert VM- und Containerkonfigurationen sowie die eingeschlossenen Gastdaten. Disk-Ausschlüsse und bei Containern Mount-Typen beeinflussen den Umfang. Die Inhalte von Bind- und Device-Mounts werden nicht mitgesichert. Erfassen Sie diese Daten gesondert.
Der Proxmox Backup Client kann Dateien direkt vom physischen Host sichern. Ein Archiv von / schließt andere Mountpoints nicht automatisch ein. Prüfen Sie daher Dateisystemgrenzen und die tatsächlich vorhandenen Archive im Backup-Katalog. Ein root.pxar allein belegt weder ein vollständiges Host-Backup noch eine bootfähige Wiederherstellung.
| Benötigter Bestand | Separat dokumentieren und geschützt vorhalten |
|---|---|
| Host und Boot | PVE-/Paketstand, Installation, Partitionierung, Bootmodus und Datenträgerzuordnung |
| Netzwerk | NIC-Zuordnung, Bridges, VLANs, IPs, Routing und Zugang zur Konsole |
| PVE-Konfiguration | pmxcfs-Konfiguration, Storage-IDs, Rechte, Jobs und Firewall |
| Lokale Ergänzungen | /etc/network/interfaces, /etc/hosts, Repository-Konfiguration, Dienste und Skripte |
| Recovery-Zugang | PBS-Repository, Namespace, Berechtigungen, TLS-Vertrauen und Verschlüsselungsschlüssel |
Die pmxcfs-Dokumentation beschreibt /etc/pve als datenbankgestütztes Dateisystem. Seine Datenbank liegt unter /var/lib/pve-cluster/config.db. Eine Sammlung einzelner /etc/pve-Dateien und eine konsistente Datenbanksicherung sind unterschiedliche Sicherungswege; der gewählte Weg muss geprüft sein. Konfigurationssicherungen können Geheimnisse enthalten und benötigen entsprechend geschützte Ablage.
Beispiel: Host-Dateien mit dem Backup-Client sichern
Ein regelmäßiger Dateibackup des Hosts ergänzt die Gast-Backups. Das folgende Beispiel sichert Konfigurationsverzeichnisse und das Root-Dateisystem mit dem Proxmox Backup Client. Der Zugang läuft über ein eigenes Token mit der Rolle DatastoreBackup (Werte sind Platzhalter):
export PBS_REPOSITORY='backup@[email protected]:store1'
export PBS_PASSWORD='<Token-Geheimnis>'
export PBS_FINGERPRINT='<Fingerprint des PBS-Zertifikats>'
# Konfiguration und Root-Dateisystem als eigene Archive, EFI-Partition einschließen
proxmox-backup-client backup etc.pxar:/etc root.pxar:/ --include-dev /boot/efi
# Vorhandene Sicherungsstände prüfen
proxmox-backup-client snapshot list
Dateisysteme anderer Mountpoints werden nur mit --include-dev eingeschlossen. Prüfen Sie nach dem ersten Lauf im Katalog, welche Archive tatsächlich vorhanden sind. Bei einem Ausfall holen Sie einzelne Archive in ein Verzeichnis zurück und vergleichen sie, statt sie über das laufende System zu kopieren:
proxmox-backup-client restore host/pve1/2026-10-21T02:00:00Z etc.pxar /root/restore-etc
Das Backup-Token gehört in einen Geheimnisspeicher, nicht in ein Skript im Klartext. Der Backup-Zugang des Hosts sollte nur schreiben und eigene Stände lesen dürfen; Löschrechte gehören nicht dazu.
Reihenfolge nach einem Hostausfall
- Alten Host gegen unbeabsichtigten Neustart sichern und Gastdatenträger-Zuordnung festhalten.
- Ersatz oder Neuinstallation mit passendem PVE-Stand, Konsole und Managementnetz bereitstellen.
- Netzwerk anhand der dokumentierten NIC-Zuordnung einrichten und prüfen.
- PBS als Storage einbinden (Fingerprint prüfen) und Schlüssel für verschlüsselte Backups bereitstellen.
- Host-Konfiguration aus dem Archiv in ein Vergleichsverzeichnis holen und nur passende Teile übernehmen.
- Infrastrukturgäste (DNS, Verzeichnis, Firewall) vor den davon abhängigen Anwendungen wiederherstellen, jeweils zunächst ohne Start.
- Gast für Gast starten, Netz, IP-Konflikte und externe Abhängigkeiten prüfen und die Anwendung abnehmen.
- Neuen Sicherungsjob prüfen und das Protokoll abschließen.
Ausfall eingrenzen und Ziel vorbereiten
Zuerst klären: Ist nur das Bootmedium ausgefallen, sind Gastdatenträger erhalten oder fehlt die gesamte Maschine? Bei erhaltenen Datenträgern deren Zuordnung sichern und keine Neuinstallation auf diese Medien freigeben. Den alten Host gegen unbeabsichtigten Neustart absichern, bevor Gäste andernorts starten.
Installieren Sie PVE auf eindeutig zugeordneten Ersatzmedien mit einem zum Restore passenden Softwarestand. Stellen Sie Konsolenzugang, Managementnetz und Ziel-Storage her. NIC-Namen und Datenträgerpfade können auf Ersatzhardware abweichen; übernehmen Sie Netzwerkdateien nicht ungeprüft. Die PVE-Netzdokumentation erläutert Bridges und Interface-Konfiguration.
Hostkonfiguration kontrolliert wiederherstellen
Für einen neu aufgebauten Einzelhost können Sie die benötigte Konfiguration anhand der gesicherten Dokumentation wieder anlegen und anschließend die Gäste aus PBS zurückholen. Dateisicherungen zunächst in ein separates Verzeichnis extrahieren, vergleichen und nur passende Einstellungen übernehmen. Die Client-Restore-Funktion stellt einzelne Archive wieder her; sie erledigt keine vollständige Boot-Reparatur.
Für den gezielten pmxcfs-Recovery-Weg beschreibt Proxmox die Übernahme von config.db auf einen neuen Host, auf dem nichts läuft: Dienst pve-cluster stoppen, Datenbank mit Rechten 0600 ersetzen, Hostname und /etc/hosts passend zum verlorenen Host setzen, neu starten und prüfen. Die Gastdaten bleiben zusätzlich erforderlich (Herstellerablauf). Das ist kein allgemeiner Befehlssatz zum Überschreiben eines bestehenden Clusters. Netz- und Storage-Zuordnung müssen zum Ziel passen; eine alte Identität darf nicht gleichzeitig aktiv sein.
Gäste aus PBS wiederherstellen
Binden Sie den erreichbaren PBS mit korrektem Datastore, Namespace, Berechtigungen und überprüftem TLS-Vertrauen ein. Bei verschlüsselten Backups den unabhängig gesicherten Schlüssel bereitstellen. Die PVE-Integration von PBS dokumentiert Anbindung und Restore.
Wählen Sie den Sicherungsstand und das Ziel-Storage ausdrücklich aus. Stellen Sie den Gast zunächst ohne Start wieder her und prüfen Sie Bridge, VLAN, IP-Konflikte, Passthrough sowie externe Datenabhängigkeiten. Für einen Test eine freie ID und ein isoliertes Netz verwenden. Bei Containern vor jedem Start alle mpX-Einträge prüfen; produktive Bind-/Device-Mounts entfernen oder auf unabhängige Testkopien umlegen. Eine neue ID allein isoliert diese Datenzugriffe nicht.
Der PBS-Restore-Test behandelt die Gastprüfung im Detail. Stellen Sie Infrastrukturabhängigkeiten vor den davon abhängigen Anwendungen wieder her. Die Reihenfolge wird im DR-Runbook festgehalten.
Cluster-Ersatz gesondert behandeln
Wenn der übrige Cluster weiterläuft, stammt dessen maßgebliche Konfiguration aus dem erhaltenen Verbund. Alten Node und seine Gäste zuerst sicher abgrenzen, Quorum und Storage prüfen und den Ersatz nach dem dokumentierten Node-Entfernen und Cluster-Beitritt planen. Nicht auf Verdacht eine alte Cluster-Datenbank einspielen.
Der Beitritt überschreibt /etc/pve des beitretenden Nodes; dieser darf keine Gäste enthalten. Wenn Daten auf Shared Storage erhalten sind, gelten für eine manuelle Übernahme die Fencing- und Ressourcenbedingungen der pmxcfs-Recovery. Fehlende lokale Disks werden durch Verschieben einer Gastkonfiguration nicht wiederhergestellt.
Abnahme dokumentieren
Prüfen Sie Hostneustart, Managementzugriff, Storage, Netz, Zeitdienst und gegebenenfalls Clusterzustand. Danach Datenstand, Anmeldung und fachlichen Ablauf der Gäste bestätigen. Einen neuen Sicherungsjob prüfen und offene Abhängigkeiten protokollieren. Der Umfang des Nachweises muss erkennen lassen, ob nur ein Gast oder auch der Host-Wiederaufbau geprüft wurde.
Für die Wiederherstellungsplanung: Disaster Recovery. Für eine definierte praktische Prüfung mit Protokoll: Restore-Test. Ein Host-Ausfallszenario wird ausdrücklich in den Prüfauftrag aufgenommen.
