Libvirt-VM-Backup und Restore

Voraussetzungen

Auf dem Ubuntu-Host:

sudo apt install rsync libvirt-clients qemu-utils python3

Auf dem Debian-Ziel:

sudo apt install qemu-system-x86 qemu-utils libvirt-daemon-system \
  libvirt-clients ovmf swtpm swtpm-tools rsync python3

Backup

Windows vollständig herunterfahren.
BitLocker-Recovery-Keys separat sichern.
Backup-Datenträger einhängen.
Skript starten:

chmod +x libvirt-backup.sh libvirt-restore.sh
sudo ./libvirt-backup.sh /mnt/backup/libvirt-host

Prüfen:

cd /mnt/backup/libvirt-host
sha256sum -c metadata/SHA256SUMS
cat metadata/block-sources.txt
cat metadata/missing-files.txt

block-sources.txt muss leer sein, sofern keine LVM-/Block-Devices verwendet werden. Enthaltene Blockgeräte sind zusätzlich separat zu sichern.

Restore

Auf Debian zunächst libvirt/QEMU installieren und den Backup-Datenträger einbinden:

sudo ./libvirt-restore.sh /mnt/backup/libvirt-host

Standardmäßig überschreibt das Skript keine vorhandenen Dateien oder libvirt-Definitionen. Für eine bewusst erzwungene Wiederherstellung:

sudo OVERWRITE_FILES=1 REPLACE_DEFINITIONS=1 \
  ./libvirt-restore.sh /mnt/backup/libvirt-host

Autostart für importierte Objekte setzen:

sudo AUTOSTART_OBJECTS=1 ./libvirt-restore.sh /mnt/backup/libvirt-host

Exportierte Host-Interfaces/Bridges werden aus Sicherheitsgründen nicht automatisch definiert. Das ist bewusst separat:

sudo RESTORE_INTERFACES=1 ./libvirt-restore.sh /mnt/backup/libvirt-host

Bei Bridges ist es häufig besser, die Netzwerkkonfiguration auf Debian mit NetworkManager oder systemd-networkd neu aufzubauen.

Wichtige Grenzen

Offline-Backup: Die VMs müssen ausgeschaltet sein.
File-basierte Images, UEFI-NVRAM und dateibasierte TPM-Zustände werden kopiert.
LVM-LVs, ZFS-ZVOLs, Ceph/RBD, iSCSI und sonstige Block-/Netzwerk-Storage- Quellen werden nur dokumentiert.
Snapshot-Backing-Chains werden nicht automatisch aufgelöst. Referenzierte Backing-Dateien müssen selbst als Disk-Quelle in der Konfiguration vorkommen oder zusätzlich gesichert werden.
Firmwarepfade können sich zwischen Ubuntu und Debian unterscheiden. Bei OVMF-Fehlern das Domain-XML und die auf Debian installierten Firmwaredateien prüfen.
Nach dem Restore zuerst nur eine VM starten und insbesondere UEFI, virtuelles TPM, Secure Boot, BitLocker und Netzwerk testen.

PAW-Netzwerk aus `50-paw-install.yml` (Version 1.2)

Das Paket sichert jetzt zusätzlich die vom Playbook verwendete Konfiguration:

/etc/NetworkManager/system-connections/
/etc/NetworkManager/dispatcher.d/
/etc/libvirt/qemu/networks/
relevante sysctl-, UFW-, Routing- und /hilden-Dateien
aktuelle MAC von br-lan
permanente MACs und Hardwarepfade aller physischen Interfaces
Zuordnung der Bridge-Ports zu br-lan

Das alte PAW-Profil bindet die Ports fest an eth0 und enp2s0f0. Beim Restore werden diese Namen anhand der gesicherten permanenten MAC-Adressen auf die unter Debian tatsächlich vorhandenen Gerätenamen umgesetzt. Zusätzlich wird die bisher dynamische MAC von br-lan als bridge.mac-address im NetworkManager-Keyfile festgeschrieben.

Empfohlene Reihenfolge auf Debian:

# 1. 50-paw-install.yml ausführen
# 2. VM- und Netzwerk-Restore vorbereiten, NetworkManager noch nicht neu starten
sudo RESTORE_PAW_NETWORK=1 ./libvirt-restore.sh /mnt/backup/libvirt-host

# 3. Profile kontrollieren
sudo grep -R -E '^(interface-name|mac-address|master)=' \
  /etc/NetworkManager/system-connections/

# 4. Nur lokal an der Konsole aktivieren
sudo RESTORE_PAW_NETWORK=1 APPLY_PAW_NETWORK=1 \
  ./libvirt-restore.sh /mnt/backup/libvirt-host

Alternativ kann nur der Netzwerkteil ausgeführt werden:

sudo ./paw-network-backup.sh /mnt/backup/paw-network
sudo ./paw-network-restore.sh /mnt/backup/paw-network
sudo APPLY_NETWORK=1 ./paw-network-restore.sh /mnt/backup/paw-network

Der Netzwerk-Restore startet NetworkManager standardmäßig nicht neu. Das verhindert einen unbeabsichtigten Verbindungsabbruch bei einem Restore per SSH.

4.1 KiB Raw Blame History