Proxmox Backup Server: Restore großer VMs kann Datenverlust auslösen — so testen Sie Ihre Wiederherstellung, bevor der Ernstfall eintritt

Ein Restore soll der sichere Rückweg sein, wenn im Betrieb etwas schiefgeht — bei Proxmox VE 8 und 9 kann genau dieser Rückweg gerade selbst zum Risiko werden: Nutzer berichten von schweren E/A-Blockaden beim Zurücklesen von Backups über den Proxmox Backup Server (PBS), die virtuelle Maschinen beschädigen und laut ersten Schilderungen sogar zu Datenverlust führen können.

Was gemeldet wird

Proxmox VE ist eine kostenlose Open-Source-Virtualisierungsplattform, der Proxmox Backup Server (PBS) ergänzt sie um inkrementelle, ZFS-taugliche Sicherungen. In der Proxmox-Community häufen sich seit Mitte Juli 2026 Berichte über ein Problem, das ausschließlich beim Restore über PBS auftritt — nicht bei der Sicherung selbst, die nach den vorliegenden Schilderungen zuverlässig läuft. Ein Administrator beschreibt, wie sein Proxmox-VE-Host beim Zurücklesen eines rund 3 bis 4 Terabyte großen VM-Backups so stark ausgelastet wurde, dass laufende virtuelle Maschinen keine CPU-Zuteilung mehr erhielten und einfroren. Nach rund 20 bis 30 Sekunden erschienen in den Windows-Ereignisprotokollen betroffener VMs virtio-Treiberfehler — ein Hinweis darauf, dass Windows wegen der massiven E/A-Verzögerung versucht, den virtio-Controller zurückzusetzen.

Ein zweiter, unabhängig geschilderter Fall zeigt ein ähnliches Bild mit deutlich konkreteren Folgen: Beim Restore einer vergleichsweise kleinen Linux-VM auf einem gut ausgestatteten Host — zwei Intel-Xeon-CPUs, 1 TB RAM, NVMe-SSDs im ZFS-Spiegel — wurden gleichzeitig ein virtualisierter Windows-Domänencontroller und ein Windows-Druckserver im Dateisystem beschädigt, eine MySQL-Tabelle auf einer weiteren Linux-VM war korrupt, und die zugehörige VM erlitt einen Kernel-Hang.

Was das Fehlerbild von einem gewöhnlichen Engpass unterscheidet

Bemerkenswert ist, was gerade nicht beschädigt ist: Der zugrunde liegende ZFS-Pool bleibt nach Angaben der Betroffenen intakt, Scrubs melden keine Fehler, und weder die NVMe-Laufwerke noch das Dateisystem zeigen eigene Integritätsprobleme. Der Schaden entsteht offenbar nicht durch defekte Hardware oder ein fehlerhaftes ZFS, sondern durch die extreme E/A-Konkurrenz, die der Restore-Vorgang selbst erzeugt — und die dann andere, eigentlich unbeteiligte VMs auf demselben Host in Mitleidenschaft zieht.

Was derzeit noch offen ist

Wann genau es zum Datenverlust kommt, ist nach aktuellem Kenntnisstand nicht geklärt — ebenso wenig, ob bestimmte Storage-Konfigurationen, Backup-Größen oder Hardware-Kombinationen das Risiko erhöhen. Das Problem wird derzeit vom Proxmox-Support geprüft; eine offizielle Bestätigung der Ursache oder ein Fix stehen öffentlich bislang nicht fest. Auch bleibt unklar, wie viele Installationen betroffen sind — die vorliegenden Schilderungen stammen aus einer kleinen Zahl von Einzelfällen, nicht aus einer systematischen Auswertung.

Was Sie jetzt tun können

Aus unserer Sicht ist das kein Grund, PBS als Backup-Lösung grundsätzlich infrage zu stellen — die Sicherung selbst läuft in den geschilderten Fällen zuverlässig. Der wunde Punkt ist der Restore, und genau den testet man in der Praxis am seltensten, weil er im Alltag kaum vorkommt. Wer produktive VMs über PBS sichert, sollte deshalb nicht erst im Ernstfall zum ersten Mal einen vollständigen Restore fahren: Ein Testlauf in einer isolierten Umgebung, mit Blick auf CPU- und E/A-Auslastung während des Vorgangs, zeigt, ob der eigene Host unter Last ähnliche Symptome zeigt. Besonders bei großen VM-Backups im Terabyte-Bereich lohnt sich zusätzlich, den Restore-Vorgang bis zur Klärung der Ursache auf ein separates Storage-Ziel statt direkt auf den produktiven Pool zu planen.

Quellen: Borns IT- und Windows-Blog — „Schwerer Fehler in Virtualisierungslösung Proxmox führt zu Datenverlust“ (https://borncity.com/blog/2026/08/17/schwerer-fehler-in-virtualisierungsloesung-proxmox-fuehrt-zu-datenverlust/)