WZ-IT führt einen abgegrenzten Proxmox Restore-Test mit Protokoll durch. Für den vollständigen Wiederanlauf mehrerer Systeme ist Disaster Recovery der passende Rahmen.
Ein erfolgreicher Sicherungsjob und ein erfolgreicher Verify-Job beantworten andere Fragen als ein Restore-Test. Erst die isolierte Wiederherstellung prüft, ob Sicherungsstand, Schlüssel, Zielkapazität und Anwendung zusammen funktionieren.
Stand: Oktober 2026.
Soll auch die ausgefallene PVE-Installation ersetzt werden, planen Sie den Host-Wiederaufbau mit PBS zusätzlich zum Gast-Restore.
Inhalt
- Vorbereiten und isolieren
- VM oder Container wiederherstellen
- Start und Anwendung prüfen
- Protokoll und Automatisierung
- Quellen
Vorbereiten und isolieren
System, Sicherungsstand, Eigentümer und Prüfkriterien festlegen. Backup- und Restore-Berechtigungen, TLS-Vertrauen sowie bei Verschlüsselung den separat gesicherten Schlüssel prüfen. PBS muss als Storage-Ziel eingebunden und erreichbar sein; die PBS-Integration dokumentiert die Anbindung.
- Freie VM-/CT-ID und ausreichend Ziel-Storage bestätigen.
- Testnetz ohne Verbindung zu produktiven Clients, DHCP, E-Mail-Versand oder externen Jobs vorbereiten.
- Automatischen Start und produktive Netzwerkanschlüsse vor dem Testboot prüfen und sperren.
- Zeitmessung, Abbruchpunkt und Ansprechpartner festlegen.
- Für Offsite-Nachweise tatsächlich die Offsite-Kopie verwenden.
VM oder Container wiederherstellen
Im Proxmox-VE-Webinterface das PBS-Storage öffnen und den vereinbarten Snapshot auswählen. Über die Restore-Funktion eine neue, freie ID und den Ziel-Storage angeben. Die produktive Instanz bleibt bestehen. Den Restore zunächst ohne automatischen Start ausführen; anschließend Netzwerk und Gerätezuordnung der wiederhergestellten Instanz kontrollieren.
Die Restore-Dokumentation unterscheidet qmrestore für VMs und pct restore für Container. Live-Restore startet eine VM bereits während der Wiederherstellung; für diesen kontrollierten Ablauf bleibt die Option aus.
Bei VMs auch Firmware, benötigte Geräte und Gastbetriebssystem prüfen. Bei Containern gesondert feststellen, welche Mountpoints im Backup enthalten sind: Bind-Mount-Inhalte sind nicht automatisch Teil des Container-Backups. Die Container-Dokumentation beschreibt diesen Ausschluss ausdrücklich. Fehlende externe Datenquellen verhindern eine vollständige Anwendungsprüfung, auch wenn der Container startet.
Beim einfachen Container-Restore einschließlich Weboberfläche werden Bind- und Device-Mounts wieder in die Konfiguration übernommen, obwohl ihre Inhalte nicht gesichert sind. Vor jedem Containerstart sämtliche mpX-Einträge prüfen: Produktive Bind-/Device-Mounts entfernen oder auf unabhängige Testkopien umlegen. Auf demselben Host können sonst produktive Verzeichnisse oder Blockgeräte beschreibbar sein; eine neue ID und Netzisolation verhindern das nicht.
Start und Anwendung prüfen
Die wiederhergestellte Instanz erst nach der Netzwerk-, Geräte- und Mount-Prüfung im isolierten Netz starten. Boot, Dateisysteme, erwarteten Datenstand und ausgewählte Dienste prüfen. Für eine Datenbank beispielsweise einen lesenden Konsistenz- und Anwendungstest definieren; allein ein laufender Prozess genügt nicht. Wiederherstellungspunkt und gemessene Gesamtdauer gegen die vereinbarten Ziele einordnen, ohne aus einem Test eine zukünftige Garantie abzuleiten.
Bei Fehlern Logs und Konfiguration sichern, Ursache eingrenzen und den Wiederholungstest nach der Korrektur planen. Testinstanz und temporäre Zugänge nach dokumentierter Abnahme bereinigen; produktive Backups und Aufbewahrung bleiben erhalten.
Protokoll und Automatisierung
Muster, kein Kundenergebnis:
| Feld | Eintrag |
|---|---|
| System und Snapshot | [ID, Zeitpunkt, Datastore] |
| Wiederherstellungspunkt | [erreichter Datenstand] |
| Dauer | [Start, Ende, gemessene Zeit] |
| Prüfkriterien | [Boot, Daten, Dienste, Ergebnis] |
| Befunde | [Fehler, fehlende Abhängigkeiten] |
| Maßnahmen | [Priorität, Zuständigkeit, Wiederholung] |
Ein Skript kann Snapshot-Auswahl, Wiederherstellung unter freier ID, Statusabfrage und Protokollierung verbinden. Vor einem automatischen Start müssen Netzisolation, zulässige IDs und bei Containern sämtliche mpX-Einträge technisch geprüft sein; produktive Bind-/Device-Mounts müssen entfernt oder auf unabhängige Testkopien umgelegt sein. Anwendungen benötigen eigene Health Checks und Abbruchregeln. Ein möglicher Ablauf als Pseudocode:
prüfe Freigabe, freie Ziel-ID, Kapazität und Netzisolation
protokolliere Snapshot und Startzeit
restore ohne automatischen Start
prüfe Netz- und Gerätekonfiguration
prüfe bei Containern alle mpX-Einträge und entferne produktive Bind-/Device-Mounts oder lege sie auf unabhängige Testkopien um
starte erst nach bestandener Prüfung isoliert
prüfe Boot, Datenstand und definierte Anwendungskriterien
protokolliere Ende, Befunde und Maßnahmen
bereinige Testressourcen nach Freigabe
Ein Bash-Gerüst für den VM-Restore ohne Start folgt unten. Vor Aufruf auf einem freigegebenen Testziel freie Cluster-ID, Storage-Kapazität und Isolation prüfen. Parameter sind die PBS-Backup-Volume-ID aus der Storage-Inhaltsansicht, eine freie Ziel-ID und das Test-Storage. Das Gerüst prüft vorhandene Gast-Konfigurationen, startet keine VM und löscht keine Ressourcen; es ist kein vollständiger Anwendungstest. Keine produktiven Zugangsdaten als Parameter übergeben.
#!/usr/bin/env bash
set -euo pipefail
archive=${1:?PBS backup volume ID required}
target_id=${2:?Free target VM ID required}
target_storage=${3:?Test storage ID required}
[[ "$target_id" =~ ^[1-9][0-9]{2,8}$ ]] || exit 2
[[ "$archive" == *:backup/vm/* ]] || exit 2
shopt -s nullglob
existing=(/etc/pve/nodes/*/qemu-server/"$target_id".conf
/etc/pve/nodes/*/lxc/"$target_id".conf)
((${#existing[@]} == 0)) || exit 3
printf 'restore_start=%s target=%s\n' "$(date -u +%FT%TZ)" "$target_id"
qmrestore "$archive" "$target_id" --storage "$target_storage" \
--unique 1 --force 0 --start 0 --live-restore 0 --ha-managed 0
printf 'restore_end=%s target=%s\n' "$(date -u +%FT%TZ)" "$target_id"
Die Optionen sind in der offiziellen qmrestore-Synopsis dokumentiert. --unique ändert die MAC-Adresse, ersetzt aber keine Netzisolation. Erst nach manuell geprüfter Netzwerk- und Gerätezuordnung isoliert starten. Laufzeit und Fehlercode im eigenen Testprotokoll erfassen; das Gerüst wurde hier nur auf Bash-Syntax geprüft.
Verify-Jobs bleiben eine ergänzende Integritätsprüfung. Der PBS-Grundlagenartikel erklärt Datastores und Verschlüsselung. Wiederkehrende Tests und vollständige DR-Drills werden nach Umfang vereinbart.
Wiederherstellungsweg prüfen lassen: Proxmox Restore-Test für ein vereinbartes System anfragen. Die PBS-Verschlüsselungsanleitung behandelt Schlüssel und Wiederherstellung.
