Im Rechenzentrum eines mittelständischen Unternehmens sorgt ein Cluster für die Bereitstellung aller kritischen Dienste. An einem Montagmorgen stellt der Sysadmin fest, dass die Speicher-Appliance nach einem fehlgeschlagenen Firmwareupdate keine Daten mehr bereitstellt. Innerhalb weniger Minuten fallen die ersten virtuellen Maschinen aus, da ihre Speicherpfade nicht mehr erreichbar sind. Eine klassische Notfallsituation entsteht, in der die Qualität der Backupstrategie über den Fortbestand des Unternehmens entscheiden kann.

Proxmox Virtual Environment (Proxmox VE) bietet verschiedene Möglichkeiten für das Erstellen von Sicherungen und deren Wiederherstellung. Die richtige Wahl der Backupmethode hängt von den Anforderungen an die Datensicherheit ab, dazu zählen Ausfallzeiten, Datenmengen und verfügbare Ressourcen.

Zwei Werkzeuge der Sicherung

Die in Proxmox VE eingebaute Backupfunktion verwendet das Tool "vzdump", das seit den Anfängen der Plattform zur Verfügung steht. Es erzeugt Archivdateien, die sich auf jedem Speichermedium ablegen lassen. Der Proxmox Backup Server (PBS) hingegen ist ein spezialisiertes Werkzeug, das als eigenständiger Dienst läuft und neben VMs und Containern auch physische Hosts sichern kann. PBS entstand ursprünglich, um einige der Limitierungen der integrierten Backupfunktionalität zu überwinden.

Beide Ansätze sichern die Festplatteninhalte und die Konfiguration einer virtuellen Maschine oder eines Containers, unterscheiden sich jedoch in der Art der Archivierung. Das vzdump-Tool speichert alle Daten in einer monolithischen Archivdatei, während PBS die Daten aufteilt, was erhebliche Vorteile bei der Deduplizierung und inkrementellen Sicherung bietet.

Mit Bordmittel vzdump tägliche Sicherungen durchführen

Das vzdump-Werkzeug ist das Herzstück der Backups. Sein Name stammt aus den Anfangszeiten von Proxmox VE, als noch OpenVZ für Container zum Einsatz kam. Proxmox VE wechselte später auf Linux Container (LXC), aber manche Begriffe aus der OpenVZ-Zeit kommen aus Kompatibilitätsgründen mit älteren Proxmox-VE-Versionen weiterhin zum Tragen. Mit vzdump erzeugen Sie Sicherungen von virtuellen Maschinen im Virtual-Machine-Archive-Format (VMA). Dies ist ein proprietäres Format von Proxmox VE. Diese Archive enthalten neben den Daten der virtuellen Festplatten auch Meta- und Konfigurationsdaten und tragen typischerweise Dateinamen wie "vzdump-qemu-100-2025_05_22-00_00_00.vma.zst", wobei die Zahlenfolge die ID der virtuellen Maschine und den Zeitstempel der Erstellung angibt.

Ein praktisches Beispiel zeigt den Vorteil dieses Ansatzes: Nach dem Speicherausfall findet der Admin schnell das letzte vzdump-Backup der kritischen Datenbank-VM vom Vorabend. Das VMA-Archiv enthält alle notwendigen Daten für eine vollständige Wiederherstellung. Mit einem einzigen Befehl lässt sich die VM auf einem anderem Storage wiederherstellen und der Datenbankbetrieb binnen kürzester Zeit wieder aufnehmen.

Backups erzeugen Sie mit vzdump sowohl auf der Kommandozeile als auch in der Weboberfläche. Neben einzelnen Sicherungen können Sie auch regelmäßige Jobs einrichten, die automatisch vzdump mit den entsprechenden Parametern aufrufen. So legen Sie beispielweise ein komprimiertes Backup einer VM mit ID 100 im Snapshot-Modus an:

vzdump 100 --mode snapshot --storage local --compress zstd

Wie erwähnt bestehen VMA-Dateien aus einem Header mit Meta- und Konfigurationsdaten sowie dem eigentlichen Image. Die Festplatteninhalte werden dabei als Sparse-Storage abgelegt und nur belegte Blöcke berücksichtigt. Das Format nutzt MD5-Prüfsummen zur Integritätssicherung. Eine automatisierte Prüfung der Integrität ist allerdings nicht vorgesehen, sie lässt sich jedoch manuell prüfen:

zstd -d -c vzdump-qemu-100-2025_05_22-00_00_00.vma.zst | vma verify -v -

Der Verify-Befehl prüft Header-Struktur, MD5-Prüfsummen und Vollständigkeit aller Datenblöcke. Ihre VMA-Archive können Sie auch manuell extrahieren:

zstd -d -c vzdump-qemu-100-2025_05_22-00_00_00.vma.zst | vma extract - </Ziel/Verzeichnis/>

Dies ermöglicht Ihnen Zugriff auf VM-Konfigurationen, Festplattenimages und – soweit vorhanden – Firewallregeln. Das Archiv enthält somit alle notwendigen Informationen, um eine virtuelle Maschine vollständig wiederherzustellen. Bei Containern wird anstelle der Disk-Images das gesamte Dateisystem archiviert.

 

 

Hookscripts erweitern vzdump

Ein wichtiges Feature von vzdump sind die sogenannten Hookscripte. Diese benutzerdefinierten Skripte ermöglichen es, vor, während und nach dem Backupjob automatisierte Aktionen auszuführen. Dergestalt erlauben sie die Integration in bestehende IT-Prozesse und erfüllen anwendungsspezifische Anforderungen wie das Vorbereiten von Datenbanken für konsistente Sicherungen. In der Praxis bedeutet dies beispielsweise bei der Sicherung einer Datenbank-VM, dass ein Hookscript vor jedem Backup alle Datenbank-Transaktionen abschließt und Caches leert. Nach Abschluss des Sicherungsvorgangs übermittelt das Skript eine Statusmeldung an das Monitoringsystem.

Das Einbinden eines Hookscripts erfolgt über einen Parameter beim Aufruf von vzdump, hier am Beispiel einer VM mit ID 100:

vzdump 100 --mode snapshot --storage local --compress zstd --script </Pfad/zum/Hookscript.sh>

Dabei müssen Sie beachten, dass Sie beim Einrichten eines Backupjobs über die Weboberfläche kein Hookscript mitgeben können. Für geplante Sicherungen müssen Sie den entsprechenden Job in der Datei "/etc/ pve/jobs.cfg" manuell bearbeiten und den Skriptparameter hinzufügen. Alternativ definieren Sie ein Hookscript global in "/etc/ vzdump.conf". Dieser Eintrag gilt für alle Backupaufträge, sofern er nicht durch einen CLI-Parameter oder einen Eintrag in "jobs.cfg" überschrieben wird.

Das Skript setzt automatisch zu verschiedenen Zeitpunkten des Backupprozesses ein, wobei es die aktuelle Phase als ersten Positionsparameten an Bord hat. Zusätzlich übermittelt es weitere wichtige Parameter wie "VMID" (ID der virtuellen Maschine), "MODE" (Backupmodus), "STOREID" (Storage-ID), "DUMPDIR" (Sicherungsverzeichnis) und "ARCHIVE_FILE" (Name der Backupdatei). Das Hookscript aus unserem Datenbankbeispiel könnten Sie wie im folgenden Listing gestalten:

#!/bin/bash

# Siehe Phasen in der Beispieldatei: https://git.proxmox.com/?p=pve-manager.git;a=blob; f=vzdump-hook-script.pl

# Beispiel-URL für externes Monitoringsystem (anpassen für eigene Umgebung)

MONITORING_URL="http://monitoring.local/api"

PHASE="$1"

VMID="$2"

MODE="$3"

STOREID="$4"

DUMPDIR="$5"

ARCHIVE_FILE="$6"

if [[ -z $PHASE || -z $VMID || -z $MODE ]];

then

          echo "BAIL: not all arguments given!"

          exit 1

fi

case "$PHASE" in

      backup-start)

          echo "Backup für Datenbank-VM $VMID gestartet"

          # Monitoring-System über Backupstart informieren

          curl -X POST "$MONITORING_URL/backup-start" -d "vm=$VMID"

          # Datenbank in konsistenten Zustand bringen vor dem Stoppen

          echo "Bereite Datenbank für Backup vor..."

          if ! qm guest exec $VMID --timeout 300 -- mysql -u backup -e "FLUSH TABLES WITH READ LOCK;"; then

              echo "FEHLER: MySQL FLUSH TABLES fehlgeschlagen"

              exit 1 # Exit-Code != 0 bricht das Backup ab

          fi

          ;;

      post-restart)

          # Datenbank-Locks nach Backup wieder freigeben

          if ! qm guest exec $VMID --timeout 300 -- mysql -u backup -e "UNLOCK TABLES;"; then

              echo "FEHLER: MYSQL UNLOCK fehlgeschlagen"

              # Das Backup hat funktioniert, daher erfolgt hier kein Abbruch

          ;;

      backup-stop)

          echo "Backup für VM $VMID erfolgreich - Archiv: $DUMPDIR/$ARCHIVE_FILE"

          # Monitoring über erfolgreichen Abschluss informieren

          curl -X POST "$MONITORING_URL/backup-status" -d "vm=$VMID&status=success&archive= $DUMPDIR/$ARCHIVE_FILE"

          ;;

      backup-abort)

          echo "FEHLER - Backup für VM $VMID fehlgeschlagen!"

          # Monitoring über fehlgeschlagenes Backup informieren

          curl -X POST "$MONITORING_URL/backup-status" -d "vm=$VMID&status=failed"

          ;;

esac

exit 0

Anwendungsszenarien für Hookscripts

Die Einsatzmöglichkeiten für Hookscripts sind vielfältig und richten sich nach den Anforderungen der Umgebung. Einer der häufigsten Anwendungsfälle ist die Sicherstellung der Datenbankkonsistenz. In der Pre-Stop-Phase ist es möglich, Transaktionen abzuschließen und Transaktionslogs auf die Festplatte zu schreiben, sodass die DB für das Backup in einem konsistenten Zustand vorliegt. Dies ist auch hilfreich, um spezifische Services in der VM vor der Sicherung zu warnen – etwa um Webserver-Caches zu leeren oder ERP-Batch-Jobs zu pausieren.

Nach erfolgreichem Backup können Hook- scripts eigene Integritätsprüfungen anstoßen oder sogar eine Testwiederherstellung in einer isolierten Umgebung durchführen, wobei Sie dies explizit programmieren müssen. Ebenso lassen sich externe Kopien realisieren, um das 3-2-1-Backupprinzip umzusetzen. Die frisch erstellte Sicherung wird dabei automatisch zu externen Speichern oder Clouddiensten übertragen.

Praktisch sind diese Skripte auch für Notifications, Cleanup-Jobs und Monitoringintegration – sie verwandeln den Backupprozess mittels vzdump in ein mächtiges Werkzeug für komplexere Workflows. Sie ermöglichen es, Proxmox VE nahtlos in bestehende IT-Prozesse zu integrieren und sicherzustellen, dass Sicherungen nicht nur technisch korrekt sind, sondern auch den fachlichen Anforderungen der jeweiligen Anwendungen entsprechen.

Proxmox Backup Server zum Einsatz bringen

Der Proxmox Backup Server stellt eine moderne Alternative zu vzdump dar. Er gleicht einige der Limitierungen aus und bietet zusätzliche Funktionen, die besonders in größeren Umgebungen mit hohen Datenvolumen von Vorteil sind. Die Verwaltung der Backupdaten erfolgt automatisiert, indem PBS regelmäßig die Datenintegrität prüft ("Verify Jobs") und alte Backups nach konfigurierbaren Aufbewahrungsregeln entfernt ("Prune/Garbage Collection").

Um den Umstieg zum PBS zu erleichtern, gibt es seit einiger Zeit auch die Möglichkeit, die zuvor erstellten, dateibasierten Backups zu importieren. Dafür steht Ihnen ein eigens von Proxmox geschriebenes Importwerkzeug namens "vma-to-pbs" zur Verfügung. Es ermöglicht, einzelne Sicherungen oder auch ein ganzes Verzeichnis zu importieren.

Praktisches Beispiel: Nach dem Speichervorfall analysiert die IT die bisherige Back-upstrategie und stellt fest, dass die virtuellen Maschinen größtenteils identische Betriebssysteme und Anwendungen ausweisen. Der Einsatz von PBS würde durch die Deduplizierung deutlich Speicherplatz sparen und damit den notwenigen Speicherbedarf reduzieren sowie letztlich dadurch die Betriebskosten senken. Zusätzlich erfüllen die verschlüsselten Backups die neuen Complianceanforderungen ohne zusätzliche Sicherheitsmaßnahmen implementieren zu müssen. Da sich bereits vorhandene Backups importieren lassen, sind zudem keine Parallelstrukturen erforderlich. Aufgrund dieser Erkenntnisse empfiehlt das IT-Team eine Migration zu PBS.

Deduplizierung nutzen

Im Gegensatz zum monolithischen Ansatz von vzdump verwendet PBS ein Chunk-basiertes Speicherformat. Dieses teilt die Daten in kleine Blöcke (Chunks) auf und speichert sie dedupliziert. Dieses Verfahren bietet folgende Vorteile:

- Container: Nur die tatsächlich veränderten Dateien sind Teil der Sicherung.

- VMs: Festplatten-Images werden in Chunks zerlegt und nur veränderte Bereiche gesichert.

- Die Chunk-Größe lässt sich anpassen (standardmäßig sind 4 MiB hinterlegt, was auch dem Maximalwert entspricht).

Diese Methode ermöglicht echte inkrementelle Backups mit kürzeren Laufzeiten. Die Deduplizierung funktioniert dabei auf Chunk-Ebene. PBS prüft vor dem Speichern, ob ein Chunk mit identischer Prüfsumme bereits im Repository existiert. Ist dies der Fall, speichert PBS nur eine Referenz auf den existierenden Chunk anstatt die Daten erneut abzulegen.

Dieser Mechanismus führt zu erheblichen Einsparungen beim Speicherplatz, da identische Datenblöcke verschiedener VMs nur einmal vorliegen. Bei Updates vergleicht Proxmox Backup Server die neuen Chunks mit den existierenden und speichert nur die tatsächlich geänderten. In der Praxis sind Speichereinsparungen von 70 Prozent und mehr keine Seltenheit, besonders in Umgebungen mit vielen ähnlichen virtuellen Maschinen und Containern. Die Deduplizierung erfolgt dabei global über alle Backups im selben Datastore, sodass identische Daten unabhängig von ihrer Herkunft nur einmal vorgehalten werden. Damit identische VMIDs von unterschiedlichen Quellen nicht kollidieren, verfügt PBS über die Möglichkeit, einen Datastore mit Namespaces auszustatten. Dadurch machen identische VMIDs keine Probleme mehr.

Die Chunk-basierte Sicherung verkürzt die Backuplaufzeiten deutlich. Der Sicherungsclient lädt zunächst den Katalog der vorhandenen Chunks des letzten Backups von PBS herunter. Dann vergleicht er die Prüfsumme jedes gelesenen Chunks mit dem Katalog. Unterscheidet sich ein Chunk, sendet der Client ihn an PBS. Bei VMs kann zusätzlich eine Dirty Bitmap zum Einsatz kommen, sofern diese aktiviert ist. Sie zeichnet auf, welche Blöcke auf den virtuellen Festplatten sich ändern. Der Client muss dann nur noch diese veränderten Chunks prüfen. Bei Containern vergleicht der Client die Metadaten der Dateien wie Änderungszeit und Größe. So erkennt er, welche Dateien sich geändert haben. Dieses Verfahren spart Zeit und Netzwerkbandbreite.

 

 

Sicherungen verschlüsseln

Backups können Sie mit PBS auch verschlüsselt erstellen. Dies erfolgt bereits clientseitig, noch vor der Übertragung zu PBS. Dadurch hat PBS niemals Zugriff auf die unverschlüsselten Daten. Chiffriert wird auf Chunk-Ebene mit AES-256-GCM. Die Deduplizierung bleibt dabei voll funktionsfähig, da identische Datenblöcke mit demselben Schlüssel zu identischen verschlüsselten Chunks führen. Sie starten diesen Vorgang, indem Sie zunächst einen Encryption-Key für Ihren Datastore generieren:

proxmox-backup-client key create /etc/pve/priv/storage/<storage-id>.enc --kdf none

Nun schützen Sie den Key mit einem Masterpasswort:

proxmox-backup-client key create /etc/pve/priv/storage/<storage-id>.enc --kdf scrypt

Ihr Encryption Key gilt für den gesamten Proxmox-VE-Cluster, da dieser in der Storage-Konfiguration hinterlegt ist. Somit verwenden alle Nodes denselben Schlüssel für einen PBS-Datastore. Für automatisierte Backups lässt sich der Key auch unverschlüsselt ("--kdf none") ablegen. Bei Verwendung eines Master-Keys auf PBS müssen Sie dessen Passwort beim Start des PBS-Diensts eingeben. Der entschlüsselte Master-Key wird im Arbeitsspeicher des laufenden PBS-Prozesses vorgehalten. Der Vorteil dabei ist, dass die vom Client (etwa Proxmox VE) mitgelieferten Encryption-Keys zusätzlich verschlüsselt im PBS lagern können. Nichtsdestotrotz müssen Sie den Encryption- oder Master-Key sicher in mehreren Formaten und Plätzen aufbewahren, um die Backups im Falle eines Desasters entschlüsseln zu können.

Synchronisieren und Spiegeln

Das 3-2-1-Prinzip besagt, dass drei Kopien der gesicherten Daten auf zwei verschiedenen Medien, davon eine an einem anderen Standort zu lagern sind. Dieser Ansatz schützt vor verschiedenen Ausfallszenarien wie Hardwaredefekten, lokalen Katastrophen oder Ransomware-Angriffen. PBS ermöglicht die Umsetzung dieses Prinzips durch integrierte Mirroring-Funktionen. Mit sogenannten Sync-Jobs lassen sich Backups automatisch zwischen verschiedenen PBS-Instanzen oder Datastores synchronisieren. Ein typisches Szenario ist ein primärer Proxmox Backup Server im Rechenzentrum und ein sekundärer an einem entfernten Standort oder in der Cloud.

Da der Prozess nur die Chunks überträgt, die auf dem Zielsystem noch nicht vorhanden sind, ist die Synchronisation sehr bandbreiteneffizient. Dadurch sind für die Replikation auch WAN-Verbindungen praktikabel. Zudem können Sie Synchronisationsjobs zeitlich steuern, um Netzwerkbelastungen in Spitzenzeiten zu vermeiden oder günstige Übertragungsfenster zu nutzen. Es lassen sich neben den Remote-Sync-Jobs auch lokale Jobs definieren. Dabei kann ein Datastore als Offline-Medium fungieren und vom PBS-System entfernt werden.

Langzeitsicherungen auf Tape

PBS bietet die Sicherung auf Bandlaufwerke (Tape-Backup) für die Langzeitarchivierung und zur Erfüllung regulatorischer Aufbewahrungspflichten. Das Tape-Backup unterstützt LTO-Bandlaufwerke (Linear Tape-Open) und Barcode-Scanner für Tape-Libraries. Die Daten lassen sich dabei verschlüsselt auf Band sichern, wobei deren Katalogisierung die spätere Wiederherstellung vereinfacht.

Mit Tape-Backups lässt sich die erweiterte 3-2-1-1-0-Regel umsetzen, die zusätzlich zum klassischen 3-2-1 eine unveränderliche Kopie fordert. Die Unveränderlichkeit gewährleisten dabei spezielle WORM-Bänder (Write Once, Read Many) auf Hardwareebene – unabhängig vom PBS. Sowohl WORM- als auch normale Bänder werden dabei gleich behandelt.

Virtuelle Maschinen sichern

Unabhängig vom gewählten Backupwerkzeug gibt es verschiedene Methoden, wie Sie virtuelle Maschinen und Container während des Backupprozesses behandeln können. Kommen wir hier kurz zu unserem Beispiel zurück: Die kritische Datenbank-VM erfordert nach dem Speicherausfall eine Anpassung der Backupstrategie. Der Wechsel zum Snapshot-Modus eliminiert die nächtlichen Ausfallzeiten, die mittlerweile geschäftskritisch geworden sind.

Ein neu entwickeltes Hookscript stellt die Datenkonsistenz sicher, indem es vor der Snapshot-Erstellung alle Datenbank-Transaktionen abschließt und flüchtige Daten auf die Festplatte schreibt. Die weniger kritischen Webserver laufen ebenfalls im Snapshot-Modus für einen unterbrechungsfreien 24/7-Betrieb. Für die Linux-Container der Entwicklungsumgebung fällt die Wahl auf den Suspend-Modus – ein ausgewogener Kompromiss zwischen Datenkonsistenz und minimaler Unterbrechung der Entwicklungsarbeit.

Die Backupmodi "Stop", "Suspend" und "Snapshot“ bewerten wir anhand der Datenkonsistenz und der Ausfallzeiten. Die drei genannten Modi bieten unterschiedliche Kompromisse zwischen diesen Zielen. Bei VMs sind die Ausprägungen dabei wie folgt:

- Stop-Modus: Der Prozess beginnt mit dem sauberen Herunterfahren der VM, falls sie gerade läuft. Anschließend startet die VM in einem pausierten Zustand. In diesem Moment erstellt QEMU intern einen Snapshot, der als Copy-on-Write-Mechanismus fungiert. Das eigentliche Backup startet und kopiert alle Daten der gesicherten Disks zum Backupziel. Während dieser Kopiervorgang im Hintergrund läuft, wird die VM "resumed" und vollständig gebootet. Die VM ist somit nur für kurze Zeit nicht verfügbar und kann bereits wieder normal arbeiten, während das Backup weiterläuft. Sobald die Sicherung abgeschlossen ist, stoppt die VM wieder, sollte sie zu Beginn des Prozesses nicht gelaufen sein. Dieser Modus bietet hohe Datenkonsistenz bei minimaler Ausfallzeit durch die Copy-on-Write-Technik.

- Snapshot-Modus: Dieser führt zur geringsten Ausfallzeit, allerdings mit einem minimal höheren Risiko für Inkonsistenzen. Dazu erfolgt ein Proxmox-VE-Livebackup, das Datenblöcke kopiert während die VM weiterläuft. Kommt der QEMU-Guest-Agent zum Einsatz (und ist in der VM verfügbar), kann er das Gastbetriebssystem auffordern, alle Caches und Puffer auf die Festplatte zu schreiben, bevor der Snapshot entsteht. Bei Windows-Systemen ruft der QEMU-Guest-Agent automatisch den Volume Shadow Copy Service (VSS) auf, um Anwendungen wie Microsoft SQL Server oder Exchange Server konsistent zu sichern. Bei Linux-Systemen kann der Agent bei diesem Vorgang zusätzlich benutzerdefinierte Skripte ausführen, sofern diese im Gastsystem hinterlegt sind.

- Suspend-Modus: Dieser ist hauptsächlich aus Kompatibilitätsgründen zum Suspend-Modus von Containern verfügbar – dazu gleich mehr. Die VM wird vor dem Aufruf des Snapshot-Modus angehalten. Da das Suspendieren zu einer längeren Ausfallzeit führt und die Datenkonsistenz sich dadurch nicht unbedingt verbessert, ist generell zu empfehlen, den Snapshot-Modus zu verwenden.

 

 

Backup von Containern

Bei Containern fehlt der zusätzliche Layer, der das Wegkopieren im laufenden Betrieb ermöglicht, weshalb die Backupmodi anders funktionieren als bei VMs:

- Stop-Modus: Schaltet den Container wirklich aus und anschließend hängt der Modus die Mountpoints des Containers am Hostsystem ein, damit er auf das Dateisystem zugreifen kann. Nach Abschluss des Backups werden die Mountpoints wieder ausgehängt und der Container gestartet. Während der Sicherung ist der Container nicht verfügbar, was zu langen Ausfallzeiten führt. Dafür ist die Konsistenz der Daten gewährleistet.

- Suspend-Modus: Kopiert die Daten des Containers mittels rsync zur Laufzeit des Containers an einen temporären Ort. Dann hält der Modus der Container kurz an und kopiert die zwischenzeitlich geänderten Daten erneut mit rsync. Danach wird der Container sofort wieder fortgesetzt. Der Vorteil ist hier die geringe Ausfallzeit, die jedoch mit erhöhtem Platzbedarf für die temporären Kopien einhergeht.

- Snapshot-Modus: Dieser Modus funktioniert grundlegend anders als bei VMs. Dabei ist die Unterstützung von Speicher-Snapshots zwingend erforderlich. Zunächst wird der Container suspendiert, um die Datenkonsistenz sicherzustellen. Anschließend erfolgt ein Snap-shot der Container-Volumes und das Sichern der Snapshot-Inhalte in einem Tar-Archiv. Nach Abschluss des Vorgangs löscht dieses Verfahren den Snapshot.

Performance hoch halten

Bei größeren virtuellen Maschinen kann der Snapshot-Modus zu Performanceproblemen führen. Der Copy-on-Write-Filter verknüpft die IO-Geschwindigkeit der VM direkt mit der des Backups. Schreibvorgänge des Gastsystems stoppen kurzzeitig, bis die entsprechenden Daten im Backuparchiv gesichert sind. Dies kann die VM-Performance während laufender Backups erheblich reduzieren. Hier schafft Fleecing Abhilfe, denn es erstellt ein temporäres Disk-Image auf einem schnellen, lokalen Speicher zur Zwischenspeicherung der Daten. Dies entkoppelt die VM von der Geschwindigkeit des Storage.

Bei Containern verhält es sich ähnlich, aber nur, wenn Sie diese im Suspend-Modus sichern. Mit dem Parameter "-tmpdir" leiten Sie die temporäre, via rsync erstellte Kopie auf schnellen Speicher um.

Wiederherstellen aus Sicherungen
Proxmox VE verwendet unabhängig von der Backupmethode dieselben Restore-Befehle: für virtuelle Maschinen "qmrestore", für Container "pct restore". Der einzige Unterschied liegt in der Angabe der Quelle. Beim Restore von vzdump-Backups geben Sie den lokale Dateipfad an, beispielweise, um eine VM mit der neuen VM-ID 201 zurückzuspielen:

qmrestore /var/lib/vz/dump/ vzdump-qemu-100-2025_05_22-00_00_00.vma.zst 201

Einen Container stellen Sie so wieder her:

pct restore 201 /var/lib/vz/dump/ vzdump-lxc-100-2025_05_22-00_00_00.tar.zst

Das Restore mit einer neuen ID (hier 201 statt 100) ist üblich, da so die ursprüngliche VM beziehungsweise der Container erhalten bleibt. Dies ermöglicht Tests der wiederhergestellten Instanz oder parallelen Betrieb. Um die Original-VM beziehungsweise den Original-Container zu überschreiben, müssen Sie diese zuerst stoppen und dann mit der Option "--force" wiederherstellen. Um also eine VM mit ihrer ursprünglichen ID zurückzusichern (überschreibt VM 100), nutzen Sie:

qmrestore /var/lib/vz/dump/vzdump-qemu-100-2025_05_22-00_00_00.vma.zst 100 --force

Bei PBS-Вackups erfolgt die Angabe über PBS-Storage und den Snapshot-Namen. Daher nutzen Sie hier diesen Befehl für den Restore einer VM:

qmrestore pbs-storage:backup/vm/100/ 2025-05-22T00:00:00Z 201

Eine VM mit Live-Restore (startet sofort, Daten werden im Hintergrund geladen) rufen Sie wie folgt ins Leben:

qmrestore pbs-storage:backup/vm/ 100/2025-05-22T00:00:00Z 201 --live-restore

Beim Container-Restore kommt dieses Kommando zum Einsatz:

pct restore 201 pbs-storage:backup/ct/100/2025-05-22T00:00:00Z

Die Live-Restore-Option "--live-restore" ermöglicht bei VMs einen sofortigen Start aus dem Backup heraus. Benötigte Datenblöcke werden dazu nach Bedarf der VM vom PBS geholt und auf dem lokalen Storage bereitgestellt, während im Hintergrund die restlichen Daten übertragen werden, bis das gesamte Backup lokal vorliegt. Dies reduziert die Downtime auf Sekunden. Natürlich braucht es für den Live-Restore eine großzügige Netzwerkbandbreite, sonst kann die VM nicht flüssig hochfahren.

Über die Weboberfläche ist die Wiederherstellung noch einfacher. Im Storage-Browser navigieren Sie zum entsprechenden Backup, wählen "Restore" und legen die gewünschten Optionen wie Ziel-ID und Storage fest. Bei VMs mit direkt durchgereichten Hardwarekomponenten (PCI Pass-through, GPU Pass-through) ist darauf zu achten, dass die entsprechende Hardware auf dem Zielsystem für die Wiederherstellung verfügbar oder eine angepasste Konfiguration vorhanden ist.

Fazit

Die verfügbaren Varianten für Backups sind eine der großen Stärken von Proxmox VE und versetzen Sie in die Lage, die optimale Lösung für Ihre Umgebung auszuwählen. Dabei eignet sich vzdump für kleinere Umgebungen dank seiner einfachen Handhabung, der sofortigen Verfügbarkeit ohne zusätzliche Infrastruktur und der unkomplizierten Wiederherstellung. Diese Backupfunktion ist direkt über das Proxmox-GUI nutzbar – ohne Kommandozeile oder komplexe Konfiguration.

Proxmox Backup Server ist die erste Wahl für anspruchsvolle Umgebungen mit vielen VMs und Containern. Die Deduplizierung spart erheblich Speicherplatz, die clientseitige Verschlüsselung erfüllt Compliance-Anforderungen und die effizienten inkrementellen Backups minimieren die Netzwerklast. Der Zusatzaufwand für die PBS-Installation zahlt sich schnell aus.

Nicht besprochen haben wir die Integration externer Backupsoftware. Hier sei kurz angemerkt, dass diese primär dann in Frage kommt, wenn bereits eine etablierte Sicherungsinfrastruktur existiert oder spezielle Features erforderlich sind. Typische Szenarien sind dabei die zentrale Verwaltung heterogener Virtualisierungsumgebungen, die Integration in bestehende Enterprise-Backup-Workflows, spezielle Compliance-Reports, oder, wenn Application-aware Backups für Anwendungen wie SAP oder Oracle benötigt werden, die die nativen Proxmox-Tools nicht unterstützen. (jp)

von Alwin Antreich und Frank Bartkewitz