Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
Proxmox-Bug: Datenverlust durch Fehler beim Restore vom Backup Server
- von Technischer Support
Ein Restore aus dem Proxmox Backup Server kann auf Proxmox VE 8 und 9 laufende virtuelle Maschinen beschädigen.
Das Zurücklesen eines Backups erzeugt eine so hohe Last auf dem Host, dass fremde VMs minutenlang blockieren, Dateisysteme beschädigt werden und Datenbanken inkonsistent zurückbleiben – obwohl diese VMs am Restore gar nicht beteiligt sind. Der Proxmox-Support hat vergleichbare Fälle bestätigt und prüft eine Korrektur. Ein Update, das den Proxmox-Bug behebt, gibt es (Stand 17. August 2026) noch nicht.
Das Wichtigste in Kürze
- Betroffen vom Proxmox-Bug ist das Zurücklesen von Backups aus dem Proxmox Backup Server (PBS) auf Proxmox VE 8 und 9.
- Während des Restores steigt die Systemlast in den dreistelligen Bereich, die E/A-Verzögerung liegt deutlich über 50 Prozent.
- Laufende VMs frieren für 20 bis 30 Sekunden ein, obwohl sie nicht wiederhergestellt werden.
- Gemeldet wurden ein beschädigtes Dateisystem auf einem Windows-Domänencontroller, defekte MySQL-Tabellen und Kernel-Hangs in Linux-VMs.
- Der Proxmox-Support vermutet, dass der Prozess pbs-restore den Seitencache des Hosts füllt und dadurch ZFS ausbremst.
- Ein Bandbreitenlimit für den Restore blieb in den Tests ohne Wirkung. Eine offizielle Korrektur wird geprüft, ist aber noch nicht verfügbar.
Was beim Restore vom Proxmox Backup Server passiert
Beim Zurückspielen einer virtuellen Maschine startet Proxmox VE den Prozess pbs-restore. Er holt die Datenblöcke vom Proxmox Backup Server, entpackt sie und schreibt sie in das Ziel-Storage. Bei einer VM mit mehreren Terabyte laufen dabei über Stunden große Datenmengen durch den Host – im gemeldeten Fall mit rund 400 MB/s.
Genau an dieser Stelle entsteht das Problem des Proxmox-Bugs. Nach Einschätzung des Proxmox-Supports nutzt pbs-restore den Seitencache des Hosts – jenen Arbeitsspeicherbereich, in dem Linux zuletzt gelesene und geschriebene Daten zwischenspeichert. Der Restore füllt diesen Cache vollständig. Der Kernel muss daraufhin ständig Speicher freiräumen, und das trifft ZFS an der empfindlichsten Stelle.
ZFS verwaltet seinen eigenen Lesecache, den ARC (Adaptive Replacement Cache). Er liegt ebenfalls im Arbeitsspeicher und konkurriert nun mit dem Seitencache des Restores um denselben Platz. Wird der ARC verdrängt, muss ZFS Metadaten und Daten wieder von den Datenträgern lesen – zusätzlich zu den Schreibvorgängen des Restores.
Die Folge ist ein Rückstau im E/A-Pfad: Schreib- und Lesezugriffe werden nicht mehr zeitnah bestätigt. Für eine laufende VM sieht das aus wie ein Datenträger, der nicht antwortet. Sie wartet – und wenn sie zu lange wartet, brechen Treiber, Dienste und Dateisysteme ab. Dass die betroffene VM mit dem Restore nichts zu tun hat, spielt keine Rolle: Sie liegt nur auf demselben Storage-Pool.
Wer ist von dem Proxmox-Restore-Fehler betroffen?
Der Proxmox-Bug ist bislang nicht auf eine einzelne Version oder eine einzelne Hardware eingegrenzt. Gemeldet wurde er aus einer Umgebung mit Proxmox VE 9.2.4 und PBS 4.2.1; laut Meldung tritt er auch unter Proxmox VE 8 auf.
Betroffen
- Proxmox VE 8 und 9 mit angebundenem Proxmox Backup Server
- Hosts, deren VM-Storage auf ZFS liegt – gemeldet für einen NVMe-Mirror (RAID 1)
- Restores großer VMs im Bereich mehrerer Terabyte
- Produktivhosts, auf denen während des Restores weitere VMs laufen
- Windows-VMs mit virtio-Treibern sowie Datenbank- und Verzeichnisdienst-VMs
Geringeres Risiko
- Der Sicherungslauf selbst – berichtet wird ausschließlich vom Zurücklesen
- Restores auf einen Host, auf dem keine produktiven VMs laufen
- Restores in ein Zielstorage, das nicht der produktive Pool ist
- Umgebungen ohne ZFS – dort liegen bislang keine Meldungen vor, ausgeschlossen ist das Verhalten aber nicht
Wichtig zu wissen: Aus dem bisherigen Meldungsbild lässt sich keine unbetroffene Version ableiten. Wer Proxmox VE 8 oder 9 mit PBS einsetzt, sollte Restores derzeit grundsätzlich als Eingriff mit Ausfallrisiko planen – nicht als Routinevorgang im laufenden Betrieb.
Welche Symptome treten während des Restores auf?
Der Betreiber berichtet von einer Serverauslastung im dreistelligen Bereich. Der Wert beschreibt keine überlastete CPU, sondern wartende Prozesse: Sie stehen in der Warteschlange, weil das Storage nicht antwortet.
Die im Proxmox-Webinterface angezeigte E/A-Verzögerung (IO delay) steigt über 50 Prozent. Ab diesem Bereich verbringt der Host mehr Zeit mit Warten auf Datenträger als mit Rechnen – alles auf dem Pool wird träge.
Laufende virtuelle Maschinen reagieren zeitweise nicht mehr und stehen für 20 bis 30 Sekunden. Für Anwendungen mit kurzen Zeitüberschreitungen ist das lange genug, um Verbindungen und Transaktionen abzubrechen.
In Windows-VMs erscheinen Fehler der virtio-Treiber. Der virtuelle Datenträger bestätigt Schreibvorgänge nicht innerhalb der erwarteten Zeit, der Treiber wertet das als Fehler des Geräts.
Auf einem Windows-Domänencontroller wurde nach einem Restore-Vorgang eine Beschädigung des Dateisystems festgestellt. Bei einem Verzeichnisdienst wirkt sich das unmittelbar auf Anmeldungen im gesamten Netz aus.
Datenbanken quittieren die abgebrochenen Schreibvorgänge mit beschädigten Tabellen. Solche Schäden bleiben häufig unbemerkt, bis eine Anwendung die betroffenen Daten liest.
In Linux-VMs kommt es zu Kernel-Hangs. Prozesse bleiben im nicht unterbrechbaren Wartezustand stehen; ein sauberes Beenden ist dann meist nicht mehr möglich, es bleibt der Neustart der VM.
Ein gesetztes Bandbreitenlimit – im gemeldeten Fall 200 MiB/s – wurde beim Restore nicht wirksam angewendet. Die naheliegende Gegenmaßnahme, den Vorgang einfach zu drosseln, greift damit nicht zuverlässig.
Wo der Schaden vom Proxmox-Bug konkret entsteht
Die Blockade selbst dauert Sekunden bis Minuten. Der Schaden, der dabei entsteht, ist deutlich langlebiger – und er zeigt sich oft erst später:
Verzeichnisdienste
Ein beschädigtes Dateisystem auf einem Domänencontroller wirkt sich auf Anmeldung, Gruppenrichtlinien und Namensauflösung im gesamten Netz aus.
Datenbanken
Abgebrochene Schreibvorgänge hinterlassen defekte Tabellen. Der Ausfall fällt häufig erst auf, wenn eine Anwendung die Daten liest.
Windows-VMs
Im Ereignisprotokoll erscheinen virtio-Treiberfehler, weil Schreibvorgänge nicht rechtzeitig bestätigt werden.
Linux-VMs
Kernel-Hangs lassen Prozesse im Wartezustand stehen. Ein Neustart der VM ist dann in der Regel unumgänglich.
Anwendungsdienste
Dienste laufen in Zeitüberschreitungen und beenden sich, obwohl die VM selbst weiterläuft.
Monitoring
Prüfungen melden während der Blockade Ausfälle für Systeme, die technisch noch laufen. Das erschwert die Einordnung im Störungsfall.
Chronologie: Wie der Fehler bekannt wurde
Der Fehler ist nicht neu, sondern seit Wochen dokumentiert. Wer die Chronologie kennt, kann besser einschätzen, wie belastbar die Informationslage ist:
1
Juli 2026
Erste Meldungen
Betreiber berichten von extremen Wartezeiten und blockierten VMs beim Zurücklesen von Backups. Am 13. Juli 2026 wird im Proxmox-Forum ein eigener Thread dazu eröffnet.
2
12. August 2026
Dokumentierter Datenverlust
Ein Betreiber beschreibt den Proxmox-Bug ausführlich – inklusive beschädigtem Dateisystem, defekten Datenbanktabellen und Kernel-Hangs. Er gibt an, das Verhalten sowohl unter Proxmox VE 8 als auch unter 9 reproduzieren zu können.
3
14. August 2026
Proxmox bestätigt den Verdacht
Aus dem Proxmox-Team wird bestätigt, dass vergleichbare Fälle im Enterprise-Support untersucht werden. Der Verdacht: pbs-restore füllt den Seitencache des Hosts und beeinträchtigt damit ZFS. Eine Korrektur wird geprüft.
Die betroffene Umgebung im Überblick
Die folgenden Werte stammen aus der ausführlichsten Meldung im Proxmox-Forum.
Sie zeigen vor allem eines: Der Fehler tritt auch auf sehr leistungsfähiger Hardware auf.
| Komponente | Angabe aus der Meldung | Einordnung |
|---|---|---|
| Proxmox VE | 9.2.4 | Laut Meldung tritt der Fehler auch unter Proxmox VE 8 auf |
| Proxmox Backup Server | 4.2.1 | Quelle des Restores |
| Ziel-Storage | 2 × 8 TB NVMe (PCIe 4.0) als ZFS-Mirror | ZFS steht im Zentrum des Verdachts |
| Ziel-Host | 48 Kerne (EPYC), 768 GB RAM | Zu wenig Rechenleistung ist nicht die Ursache |
| Netzwerk | 2 × 10 Gbit/s als LACP-Bond | Ausreichend dimensioniert |
| PBS-Host | 16 Kerne (EPYC), 128 GB RAM, 32 TB NVMe | Ebenfalls kein Engpass |
| Datenmenge | VM mit 3 bis 4 TB | Lange Laufzeit, dauerhafte Last |
| Durchsatz | rund 400 MB/s | Bandbreitenlimit blieb ohne Wirkung |
Die Tabelle ist kein vollständiges Schadensbild, sondern die Zusammenfassung eines gut dokumentierten Einzelfalls.
Für die Praxis heißt das: Eine großzügig ausgelegte Umgebung schützt nicht vor dem Problem.
Zwei Beispiele aus der Praxis
Wie sich der Fehler im Betrieb anfühlt, zeigen zwei Situationen aus den gemeldeten Fällen.
Praxisbeispiel · Restore
Blockade auf dem Produktivhost
Zurückgespielt wird eine virtuelle Maschine mit drei bis vier Terabyte auf einen Host mit 48 Kernen und 768 GB RAM. Der Durchsatz liegt bei rund 400 MB/s, der Vorgang läuft über Stunden. Auf demselben ZFS-Mirror arbeiten weitere produktive VMs weiter.
Kurz nach dem Start steigt die Systemlast in den dreistelligen Bereich, die E/A-Verzögerung überschreitet 50 Prozent. Die übrigen VMs reagieren in Schüben nicht mehr und stehen jeweils 20 bis 30 Sekunden. Ein gesetztes Bandbreitenlimit ändert daran nichts.
Empfehlung
- Große Restores in ein Wartungsfenster legen, nicht in die Kernarbeitszeit
- Vorher prüfen, welche produktiven VMs auf demselben Pool liegen
- Wenn möglich in ein separates Zielstorage oder auf einen anderen Host zurückspielen
Praxisbeispiel · Verzeichnisdienst
Schaden ohne Beteiligung am Restore
Auf demselben Host läuft ein Windows-Domänencontroller. Er ist am Restore nicht beteiligt und wird auch nicht wiederhergestellt – er liegt lediglich auf demselben Storage-Pool. Nach dem Vorgang weist sein Dateisystem eine Beschädigung auf. Im Ereignisprotokoll stehen virtio-Treiberfehler.
Im gleichen Zeitraum treten in weiteren VMs defekte MySQL-Tabellen und Kernel-Hangs auf. Auffällig ist das Muster: Der Schaden entsteht nicht an der wiederhergestellten VM, sondern an den Nachbarn.
Ein Restore ist der Moment, in dem man sich Überraschungen am wenigsten leisten kann.
Die Folge: Wer eine VM wiederherstellt und dabei drei andere beschädigt, verlängert den Ausfall statt ihn zu beenden.
Sofortmaßnahmen für Administratoren
Solange keine Korrektur verfügbar ist, geht es darum, das Risiko zu begrenzen. Vier Schritte haben sich dafür bewährt:
1
Restores als Wartungsarbeit behandeln
Ein Restore aus dem PBS ist derzeit kein Vorgang, der nebenbei läuft. Planen Sie ihn wie einen Eingriff mit Ausfallrisiko – mit Zeitfenster, Ansprechpartner und Rückfallebene.
- Wartungsfenster außerhalb der Kernarbeitszeit wählen
- Betroffene Fachbereiche vorab informieren
- Bei sehr großen VMs mit mehreren Stunden Laufzeit rechnen
2
Ziel und Produktivbetrieb trennen
Der Schaden entsteht bei den VMs, die auf demselben Pool liegen. Je weiter Restore-Ziel und Produktivbetrieb auseinanderliegen, desto geringer ist das Risiko.
- Wenn vorhanden: auf einen separaten Host oder ein Ausweichsystem zurückspielen
- Alternativ ein Zielstorage nutzen, das nicht der produktive Pool ist
- Wichtige VMs auf demselben Pool vorher kontrolliert herunterfahren
- Nach dem Restore die VM erst prüfen, dann in den Betrieb nehmen
3
Last während des Restores beobachten
Systemlast, E/A-Verzögerung und ZFS-ARC verraten früh, ob der Vorgang aus dem Ruder läuft. Wer mitliest, kann abbrechen, bevor Dateisysteme Schaden nehmen – und hat für den Support belastbare Werte.
4
Nacharbeiten und Updates verfolgen
Prüfen Sie nach jedem Restore die Dateisysteme und Datenbanken der VMs, die auf demselben Pool lagen – nicht nur die wiederhergestellte VM. Und behalten Sie die Änderungsprotokolle von Proxmox VE und PBS im Blick: Eine Korrektur ist angekündigt, aber noch nicht veröffentlicht.
Technische Umsetzung und Checkliste
Die folgenden Befehle helfen dabei, die Last während eines Restores einzuordnen und den ZFS-ARC zu begrenzen. Im Forum werden zusätzlich Testeinstellungen genannt, die Schreibvorgänge nicht mehr sicher auf die Datenträger schreiben – etwa das Abschalten von sync oder das Ignorieren von Cache-Flushes. Diese Einstellungen gehören ausdrücklich nicht in den Produktivbetrieb: Sie erhöhen das Risiko eines Datenverlusts, statt es zu senken.
Shell · Last und E/A beobachten
# E/A-Druck des Hosts live mitlesen (Proxmox VE) watch -n 5 cat /proc/pressure/io # Auslastung der ZFS-Datentraeger und ARC-Trefferquote zpool iostat -v 5 arcstat 5
Shell · ZFS-ARC begrenzen
# Aktuelle Obergrenze des ZFS-ARC auslesen cat /sys/module/zfs/parameters/zfs_arc_max # Obergrenze dauerhaft setzen (Beispiel: 64 GiB) und initramfs neu bauen echo "options zfs zfs_arc_max=68719476736" > /etc/modprobe.d/zfs.conf update-initramfs -u -k all
Checkliste: Sind Ihre Restores abgesichert?
- Restore-Vorgänge grundsätzlich in ein Wartungsfenster gelegt
- Vor dem Restore geprüft, welche produktiven VMs auf demselben Pool liegen
- Wenn möglich ein separates Zielstorage oder ein anderer Host vorgesehen
- Systemlast, E/A-Verzögerung und ZFS-ARC während des Restores überwacht
- Nach dem Restore Dateisysteme und Datenbanken der Nachbar-VMs geprüft
- Keine unsicheren ZFS-Testeinstellungen im Produktivbetrieb aktiv
- Änderungsprotokolle von Proxmox VE und PBS auf eine Korrektur verfolgt
- Restore-Tests dokumentiert – mit Dauer, Last und Auffälligkeiten
FAQ zum Proxmox-Bug
Ist auch die Sicherung bedim Proxmox-Restore-Fehler selbst betroffen oder nur der Restore?
Berichtet wird ausschließlich vom Zurücklesen. Der Sicherungslauf steht in den Meldungen nicht im Verdacht. Vorsicht ist damit beim Restore geboten, nicht beim Backup.
Tritt der Fehler nur auf ZFS auf?
Die vorliegenden Meldungen kommen aus ZFS-Umgebungen, und der Verdacht des Proxmox-Supports bezieht sich ausdrücklich auf das Zusammenspiel von Seitencache und ZFS. Dass andere Storage-Arten grundsätzlich unbetroffen sind, lässt sich daraus aber nicht ableiten.
Hilft es, die Bandbreite des Restores zu begrenzen?
Im gemeldeten Fall nicht. Ein Limit von 200 MiB/s wurde beim Restore nicht wirksam angewendet. Verlassen Sie sich nicht darauf, den Vorgang einfach drosseln zu können.
Gibt es schon ein Update, das den Fehler behebt?
Stand 17. August 2026 nicht. Aus dem Proxmox-Team wurde bestätigt, dass eine Lösung geprüft wird. Beobachten Sie die Änderungsprotokolle von Proxmox VE und Proxmox Backup Server.
Sollten wir jetzt gar keine Restores mehr durchführen?
Nein – ein Backup, das nicht zurückgespielt werden kann, ist wertlos. Behandeln Sie den Restore aber als Eingriff mit Ausfallrisiko: im Wartungsfenster, möglichst getrennt vom Produktivbetrieb und mit Kontrolle danach.
Wie erkennen wir nach einem Restore, ob eine VM Schaden genommen hat?
Prüfen Sie das Ereignisprotokoll auf Treiber- und Datenträgerfehler, lassen Sie eine Dateisystemprüfung laufen und kontrollieren Sie Datenbanken auf beschädigte Tabellen. Wichtig: nicht nur die wiederhergestellte VM, sondern alle VMs auf demselben Pool.
Fazit
Der Fehler betrifft genau den Vorgang, auf den im Ernstfall alles hinausläuft: die Wiederherstellung. Dass dabei nicht die wiederhergestellte VM, sondern ihre Nachbarn Schaden nehmen, macht ihn besonders unangenehm – der Zusammenhang wird leicht übersehen, und der Schaden fällt oft erst Tage später auf.
Bis Proxmox eine Korrektur veröffentlicht, gilt: Restores gehören in ein Wartungsfenster, möglichst getrennt vom laufenden Betrieb, mit Blick auf E/A-Druck und ARC – und mit einer Kontrolle aller VMs auf demselben Pool danach. Wer regelmäßige Restore-Tests fährt, sollte diese fortsetzen, aber bewusst planen. Unsichere ZFS-Testeinstellungen sind dafür kein Ersatz.
Sie betreiben Proxmox VE mit PBS und möchten Ihre Restore-Abläufe abgesichert wissen? Wir prüfen Backup- und Wiederherstellungskonzepte im Rahmen unserer Managed Services und begleiten Restore-Tests. Sprechen Sie uns gerne an.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!