In der Virtualisierungslösung Proxmox gibt es einen schweren Bug, der zum Datenverlust führen kann, weil Backups nicht mehr problemlos zurück gelesen werden können. Es kommt zu Hängern und andere virtuelle Maschinen können unter Proxmox VE 8 oder 9 in bestimmten Fällen sogar beschädigt werden. Ein Blog-Leser, der von diesem Problem betroffen ist, hat mich die Tage über den Sachverhalt informiert. Das Problem wird in der Proxmox-Community diskutiert und derzeit vom Proxmox-Support untersucht. Ich stelle es mal zur Information für die Leserschaft hier ein.
Die Virtualisierungslösung Proxmox VE
Proxmox VE (Proxmox Virtual Environment; kurz PVE) ist eine kostenlose Open-Source-Plattform für Virtualisierung. Die Open-Source-Virtualisierungsplattform setzt auf Debian zum Betrieb der virtuellen Maschinen und bietet ein Webinterface zur Einrichtung und Steuerung von x86-Virtualisierungen. Proxmox verwendet dabei QEMU mit der Kernel-based Virtual Machine (KVM) als Virtualisierung. PVE bietet neben dem Betrieb von klassischen virtuellen Maschinen (Gastsystemen), die auch den Einsatz von Virtual Appliances erlauben, auch Linux Containers (LXC) an.
Als Zusatz bietet der Proxmox-Backup-Server (PBS) Administratoren die Möglichkeit, Virtuelle Maschinen (VMs) in vorher konfigurierten Intervallen zu sichern. PBS verwendet hierfür inkrementelle Backups, bei welchen nach der ersten Vollsicherung lediglich die Änderungen im Vergleich zum vorherigen Backup mitgespeichert werden, was sehr kurze Backup-Intervalle ermöglicht.
Ein kurzer Leserhinweis
Ein Blog-Leser hat mich zum 13. August 2026 per E-Mail kontaktiert (danke) und schrieb unter dem Betreff "schwerwiegender Fehler bei Proxmox / PBS", dass es ein massives Problem mit Proxmox / Proxmox Backup-Server im Zusammenspiel ZFS/Restore gebe, was zu irreparablen Datenverlust führen kann. Unklar ist derzeit noch, wann genau es zum Datenverlust (in VMs) kommt.
Laut Ronnie habe es bereits bereits vor 4 Wochen, im Juli 2026, einige Hinweise auf Probleme gegeben. Nun ist der Leser in seinem Unternehmensumfeld selber erheblich von diesem Bug betroffen. Er schloss seine Mail: "Ich halte es für wichtig, dass andere Kollegen von diesem Nightmare verschont bleiben, da es gerade kleine Unternehmen existenziell gefährden kann."
PBS-Restore-Problembericht im Proxmox-Forum
Der ungenannt bleiben wollende Blog-Leser verwies mich auf den Thread Proxmox 9 CPU/IO starved when doing a restore from PBS vom 13. Juli 2026 im Proxmox-Forum. Der Thread-Starter schreibt, dass Proxmox 9 unter CPU- bzw. E/A-Engpässen bei der Wiederherstellung (Restore) per Proxmox Backup Server (PBS) leidet.
Beim Versuch, ein größeres VM-Backup (etwa 3–4 TB) wiederherzustellen, steige die Auslastung des Servers massiv an, schrieb der Thread-Starter. Die "Serverauslastung" läge im dreistelligen Bereich (was immer das bedeutet mag, mehr als 100 % kann sie ja nicht erreichen) und die E/A-Verzögerung liege deutlich über 50 %, heißt es.
Das führt dazu, das die in Proxmox VE laufenden virtuellen Maschinen (VMs) nicht mehr reagieren (denen fehlt die CPU-Zuteilung). Nach etwa 20–30 Sekunden träten schließlich virtio-Treiberfehler in den Windows-Ereignisprotokollen auf, beschreibt der Betroffene das Fehlerbild. Das deutet laut seiner Aussage darauf hin, dass die E/A-Verzögerung so groß ist, dass Windows versucht, den virtio-Controller zurückzusetzen. Der Thread-Starter fragt, wie er die Diagnose dieses Problems, dass ein Zurücklesen der Backups verhindert, genauer diagnostizieren kann.
Präzisierung des Fehlerbilds beim Restore
Zum 12. August 2026 hat sich dann ein Proxmox-Nutzer mit dem Alias guyman (der Blog-Leser gemeldet und beschrieb seine Erfahrung. Die Kurzfassung lautet, dass es unter Proxmox VE 8 und 9 zu schwerwiegenden I/O-Blockaden und Beschädigung von VMs bei der PBS-Wiederherstellung kommen kann.
Der Poster schreibt, dass sie einen Proxmox VE-Host mit einem Knoten betreiben, der seine VMs regelmäßig auf einem Proxmox-Backup-Server sichert. Die Backups selbst funktionieren zuverlässig und ohne spürbare Beeinträchtigungen. Der Host ist recht leistungsstark:
- Zwei Intel Xeon-CPUs mit 1 TB RAM
- Samsung Enterprise NVMe-SSDs
- ZFS-Spiegel
Er verwendet also ein ZFS-Dateisystem mit Spiegel-Servern. ZFS ist ein von Sun Microsystems entwickeltes transaktionales Dateisystem, das zahlreiche Erweiterungen für die Verwendung im Server- und Rechenzentrumsbereich enthält. Ein ZFS-Spiegel (Mirror / RAID-1) speichert identische Daten auf zwei oder mehr Festplatten. Fällt eine Festplatte aus, läuft das System ohne Datenverlust weiter.
Laut Poster meldet das ZFS keine Fehler und der Pool ist in ordnungsgemäßem Zustand. Dann beschreibt er seine Erfahrung beim Versuch, eine relativ kleine Linux-VM aus Proxmox Backup Server (PBS) wiederherzustellen. Während der Wiederherstellung (der Linux-VM aus dem Backup):
- kam es bei einem (wohl virtualisierten) Windows-Domänencontroller zu einer Beschädigung des Dateisystems, sodass dieser wiederhergestellt werden musste;
- ein weiterer (virtualisierter) Windows-Server, der als Druckserver diente, wies ebenfalls eine Beschädigung des Dateisystems auf;
- eine MySQL-Tabelle auf einer Linux-VM wurde beschädigt; die Linux-VM, auf der MySQL lief, erlitt einen Kernel-Hang.
Der zugrunde liegende ZFS-Pool selbst sei laut Poster weiterhin intakt. Scrubs melden keine Fehler, und es gibt keine offensichtlichen Integritätsprobleme bei NVMe oder ZFS. Der Betroffene schreibt, dass das Problem daher eher mit den extremen E/A-Konflikten und -Blockaden zusammenzuhängen scheint, die beim Wiederherstellungsvorgang auftreten, als mit einem zugrunde liegenden Speicherausfall.
Die IT-Mitarbeiter des Posters sind zunächst bei der neuesten Version von Proxmox VE 8 auf dieses Problem gestoßen. Aufgrund der Schwere des Problems haben sie den Host dann auf Proxmox VE 9 aktualisiert und den Test wiederholt. Leider lässt sich das gleiche Verhalten auch unter Proxmox VE 9 reproduzieren.
Es handelte es sich im beschriebenen Fall nicht nur um ein vorübergehendes Leistungsproblem. Vielmehr ist kein Restore eines Backups vom Proxmox Backup Server (PBS) unter Proxmox VE 8 und 9 mehr möglich. Und noch schlimmer: Beim Versuch, ein Backup einer VM zurück zu lesen, werden andere, laufende VM-Gäste beschädigt, so dass die oben beschriebenen Probleme auftreten können.
Der Betroffene schrieb: Während eine PBS-Wiederherstellung läuft, ist der normale Betrieb der anderen VMs auf dem Host praktisch unmöglich. Noch besorgniserregender ist, dass die E/A-Blockaden offenbar so schwerwiegend sind, dass sie zu einer Beschädigung des Dateisystems bzw. der Datenbank in nicht betroffenen, laufenden VMs führen können. Das bedeutet, dass es äußerst schwierig ist, in einer produktiven Virtualisierungsumgebung die Wiederherstellungsfunktion vom PBS sicher einzusetzen. "Eine Backup-Lösung muss selbstverständlich zuverlässige Wiederherstellungen ermöglichen, ohne dass damit nicht betroffene Workloads auf demselben Host gefährdet werden." schreibt der Betroffene.
Das Proxmox-Team ist dran
Vorigen Freitag, den 14. August 2026, hat sich ein Mitglied des Proxmox-Teams gemeldet und schrieb, dass ein ähnliches Problem auch im Unternehmens-Support gemeldet wurde. Das Problem wird derzeit von den Support-Technikern untersucht. Derzeit vermuten die Techniker, dass das Problem damit zusammenhängt, dass der Prozess "pbs-restore" den Host-Seiten-Cache nutzt und diesen für ZFS füllt. Das Team ist derzeit dabei, eine Lösung zu prüfen.
Für Nutzer des Proxmox Backup Server (PBS) heißt dies derzeit, besonders vorsichtig mit dem Zurücklesen von Backups zu sein, da dieser Vorgang virtuelle Maschinen auf Proxmox VE 8 oder 9 beschädigen kann. Noch jemand von diesem Problem betroffen?
MVP: 2013 – 2016
Uiii das nenne ich mal ein echtes Problem. Hoffentlich wird das ASAP gefixt.
Böse Zungen würden nun behaupten: Wärt ihr mal lieber bei vmware geblieben!
Spaß beiseite – das klingt wirklich übel. Habe selbst kein PBS bei Proxmox im Einsatz und werde ich nach der Meldung fürs erste auch meiden. Scheint ja kein Problem der letzten Updates zu sein…
Deswegen mache ich Backups auch zusätzlich direkt aus den VMs.
Aber natürlich trotzdem ein Desasaster für Proxmox, das sie hoffentlich schnell in den Griff bekommen.
Unschön und hoffentlich bald gefixt.
Wobei ich wage, ein großes Fragezeichen bei 3-4 TB großen VMs zu setzen…
Unschön? Das ist eine Katastrophe für die, die diese Backuplösung einsetzen und gff. einen Restore dringend benötigen. 4 TB ist jetzt nicht die Welt.
Was ist mit Offsite-Sicherungen? Was ist mit halbtäglichen Datenbank-Dumps? Was ist mit automatischen Testing der Sicherungen vom Vortag? Betreibst Du das alles nicht?
Zusammen mit 4+ TB große VMs weist das auf ein Problem hin: Mangelhafte Segmentierung und fehlende Redundanz.
Das ist das eigentliche Problem.
Wenn Du einmal gesehen hast, wie lange 4TB brauchen, um von einem externen USB-Medium oder über eine schmalbandige Internetverbindung irgendwie wieder zurückgespielt zu werden, dann wirst Du vielleicht besser verstehen, warum das eine ganz dumme Idee ist, seine VMs so groß werden zu lassen.
Mach doch nicht schon wieder Opferblaming, Thomas.
Da hat jemand für viel Geld ein Backup-Programm gekauft.
Mit Restore-Tests bekommst du das Zeitintervall verkürzt, in denen du Fehlerfreiheit garantieren kannst, aber du bekommst es nicht auf 0, weil zwischen den Restore Tests immer noch etwas schief gehen kann.
Wir wissen aber alle, dass dir bisher noch nie Fehler passiert sind.
Den Kommentar hättest Du Dir schenken können. Dezent am Thema vorbei…
Viel Geld für ein freies Open Source Programm?!?
Und was laberst Du da von Zeitintervall = 0 Müll wenn ein Backup eh nur 12 oder 24 Stunden RPO abdeckt?
Restore-Tests laufen skriptgesteuert automatisiert und prüfen auch automatisiert, wenn eine VM erfolgreich hochfährt (oder was Du sonst als Indiz im Monitoring nimmst).
Aber Hauptsache einen polemisch rausgedrückt oder was?
Naja, an sich an Thomas schon Recht.
Du kannst halt nicht für viel Geld ein Backup-Programm kaufen und dann erwarten, dass alles geht. Das sollte man erwarten können, aber wie Thomas schon sagte, du kannst damit nich rechnen.
Wenn du es nicht testest dann weißt du eben nicht, ob es mal Probleme geben könnte. Wenn man es dann testet wenn man es benötigt und dann Probleme feststellt. Martin scheint sich ja hier auch nicht auf das Backup zu verlassen uns sichert nicht mal die VMs. Allein ein inkrementelles Backup würde ich tendenziell schon als problematisch betrachten, je nachdem wie das gesichert wird. Da muss doch dann die ganze Kette durchlaufen werden?
> Allein ein inkrementelles Backup würde ich tendenziell schon als problematisch betrachten
Genau so ist es! Was meinst Du erst, wie das bei Snapshots und HyperV aussieht. Mir sind Fälle bekannt, da haben sich jahrelang die AVHDX Diffs aufgebläht bis die Kette brach und man zurück auf den Stand von vor zig Jahren fiel.
Das Problem hast du aber jeder Art von Layer-Storage, egal welches OS, egal ob Server/NAS/SAN.
Dass man dort genug Speicherplatz blocken sollte, ist nichts neues.
Ich habe eine VM, die 140 TB groß ist (aktuell 80 TB genutzt), wird aber nicht über PBS gesichert, sondern inkrementell über rsync und Band.
Das hört sich echt übel an. ZFS ist erheblich komplexer als man vermuten mag und geht weit über Raid 0/1 hinaus. Wir hatten im laufenden Betrieb eines TrueNAS mit 12×4 TB NVMEs das Problem das nach kurzer Zeit (waren glaube ich auch Samsungs) das Problem das einzelne NVMEs rausgeworfen wurden da deren Fehlercounter für defekte Blöcke innerhalb von Stunden explosionsartig angestiegen ist und nur noch verzögert reagierten. Nach einem Neustart waren die dann wieder auf Null und das Spiel ging von Vorne los. Nach einigen Untersuchungen stellte es sich raus das es sich dabei um einen Firmware-Bug auf den betroffenen NVMes handelte und zum Glück nur die wenigsten NVMEs mit dieser Firmware-Version ausgeliefert wurden. Nach dem Firmware-Update liefen die NVMes dann problemlos.
ZFS ist ein sehr gutes Dateisystem, man möge sich mal die Youtube-Videos anschauen bei denen bei einem laufenden Kopiervorgang RAM rausgezogen wird und nach einem Neustart alles funktioniert, aber bei der Grundeinrichtung immer noch einen zweiten Blick braucht ob da nicht doch noch irgendein Hardwarecache zwischen Filesystem und Laufwerk sitzt.
Deshalb setzt man auch auf stabile OpenZFS Implementierungen, z.B. OmniOS oder auf das Original, Solaris ZFS.
Frage hier: Ist das ein eher generelles Problem bei der Ressourcenzuteilung, wenn ein Backup zurückgespielt wird=betrifft auch andere Backup-Produkte?
Wäre hier Veeam als verbreitete Lösung ebenfalls betroffen?
Es ist generell ein Problem in proxmox, also im Gegensatz zu VMware ESXI ist es aktuell deutlich schlechter im Fairnesss-Zuteilungen von Disk-IO und Netzwerk-IO.
Ich denke, dass das eher eine Herausforderung vom Unterbau Linux ist. Das müsste meines Erachtens auf Treiber und Scheduler Ebene gelöst werden.
Mich würde interessieren, ob das Problem auch bei ZFS basierten Shared Storages auftritt oder nur auf der hci Server Lösung.
Der zugrunde liegende Fall ist zweifellos ernst und Proxmox untersucht offenbar tatsächlich ein Problem im Restore-Pfad, derzeit mit Verdacht auf 'pbs-restore' bzw. den Host Page Cache im Zusammenspiel mit ZFS.
Die Überschrift „schwerer Fehler … führt zu Datenverlust" halte ich nach dem derzeit öffentlich bekannten Stand allerdings für deutlich zu weitgehend. Bestätigt sind massive I/O-Stalls während eines Restore-Vorgangs. Die Beschädigung anderer laufender VMs stammt bislang aus einem Anwenderbericht; eine von Proxmox bestätigte Kausalkette „PBS-Restore-> Datenkorruption" gibt es meines Wissens derzeit noch nicht.
Auch die Aussage, ein Restore sei unter PVE 8 und 9 generell nicht mehr möglich, lässt sich aus dem verlinkten Thread so nicht ableiten.
Nebenbei: Die im Thread genannte „server load into hundreds" ist kein Prozentwert. Der Linux Load Average kann selbstverständlich weit über 100 liegen – gerade bei einer großen Zahl von Prozessen im I/O-Wait bzw. uninterruptible sleep ist das sogar ein ziemlich passendes Symptom.
Das Problem sollte man definitiv ernst nehmen und insbesondere Restores auf produktiven ZFS-Hosts momentan mit entsprechender Vorsicht durchführen. Von einem bestätigten generellen „Proxmox-Datenverlust-Bug" würde ich zum jetzigen Zeitpunkt aber noch nicht sprechen.
Den zweiten Absatz im Kommentar halte ich für eine gefährliche Relativierung. Meiner Lesart nach sind drei Fälle, wo es zu beschädigten VMs kam, dokumentiert: 1. Vom Thread-Starter des verlinkten Forenposts (Mitte Juli 2026), 2. vom Blog-Leser, den es im August getroffen hat, und 3. vom Proxmox-Support, der einen ähnlichen Bericht untersucht.
Unabhängig davon: Es braucht nur einen einzelnen Nutzer zu treffen, der (die mir bisher unbekannte Konstellation als Trigger hat und) plötzlich eine beschädigte VM hat oder ein dringend benötigtes Backup nicht zurück lesen kann. Der wird mutmaßlich nicht "och, ist nicht so schwerwiegend" argumentieren, wenn ein virtualisierter DC die Grätsche macht.
Danke für die Klarstellung des "server load into hundreds"-Themas.
naja sicher ärgerlich, vor allem wenn man betroffen ist.
Aber da fehlt immer das Verhältnis Betroffene Systeme / weltweit vorhandene Systeme, erst dann lässt sich sowas einordnen.
1 System unter 10 wäre ne Katastrophe; 1 System unter 1 Million pillepalle!
Aber verständlich der blog lebt nun mal davon! und als Honeypot melden sich meistens natürlich auch nur Leute welche ein Problem haben. Leser von nem Fachblog sollten selbst in der Lage sein sowas einzuschätzen!
Als reine Info ohne Wertung trotzdem wertvoll.
Die Elefantenmücke ist halt im Internet ne weit verbreitete Spezies ;-P
Das Problem beim PBS ist schon das "Backup machen". Da kann man viel falsch einrichten und dann handelt man sich permanente Dateisystemkorruption des Hosts ein, ohne jemals etwas zurückgespielt zu haben.
Hab ich auch viel Diskussion im Proxmox Forum angestoßen und ist aus meiner Sicht nicht wirklich geklärt. Für ein Produkt in der Preisklasse nicht hinnehmbar, siehe Beitrag weiter unten von mir.
Die passende Perfmon-Metrik unter Windows, die der loadavg unter Unix-Systemen entspricht heißt "Durchschnittliche Länge der Prozessor-Warteschlange" und ist sehr aufschlussreich, wenn die CPU-Last auf 100% geht. Sagt grob gesagt, wie viele cores man in die CPU jetzt maximal zusätzlich einbauen könnte, so dass die Last immer noch bei 100% wäre.
kann ich so bestätigen. Bisher sieht es für mich auch so aus, als ob nicht generell alle die ZFS nutzen, betroffen sind, sondern eher ganz bestimmte Konfigurationen.
Ich betreibe einige Proxmox Instanzen in verschiedenen Größenordnungen. Die meisten nutzen ZFS.
Erst letzte Woche habe ich bei einem Kunden einen Restore Test aller VM's durchgeführt unter PVE 9.2 und PBS 4.2 und die PVE und PBS Hosts laufen auf ZFS. Dabei gab es keine Probleme.
Und ich sehe auch keinen Hinweis, das bestehende Backups korrupt sind.
Absolut ein ernstes Problem, das man als Proxmox Admin im Auge behalten soll. Aber auch nicht so aufreißerisch und definitiv wie der Titel vermuten lässt.
Hallo zusammen,
mich würde es interessieren, wie sich hier andere Lösungen verhalten, bspw. Veeam in Verbindung mit Proxmox 8/9. Ich selbst nutzte dies im privaten Umfeld um auch immernoch am Ball zu bleiben, was Virtualisierung auf Server-Ebene betrifft.
Bisher ist mir ein solcher Fehler noch nicht unter gekommen, jedoch habe ich hier nicht die Hardware das der Realität entsprechend nachzubilden
Closed Source Veeam und Proxmox sollte man tunlichst nicht miteinander kombinieren. Da nutzt Du schon ein Open Source HV/ Cluster, nutz gefälligst GitOps und freie Automatisierungs-Stacks wie z.B. Ansible & andere.
Dein Ernst?
In sozialen Medien nennt man das glaube ich Ragebait.
Einfach eine möglichst wirre und steile These aufstellen, um damit Clicks und Antworten zu provozieren.
Veeam war einer ersten, die nach dem "Broadcom-Move" Proxmox unterstützt haben. Vermutlich aus der Angst heraus, bei der Abkehr von VMware selbst mit unter die Räder zu kommen.
Es gab zunächst ein Plugin als Beta, ab der 12.2 ist Proxmox offiziell unterstützt. Das war auch hier Thema.
Veeam ist auch für die tiefe Integration in die Clientsysteme bekannt. Für Linux etwa haben sie ein eigenes Kernel-Modul "veeamsnap.ko", inzwischen "blksnap.ko" entwickelt, welches über die verschiedenen Dateisysteme crash-konsistente Snapshots ermöglicht und (wenn man den Kernel mal aktualisiert) auch per DKMS neu kompiliert werden kann.
Von daher ist die Frage, ob auch Veeam den Proxmox Host-Cache nutzt und dabei vielleicht auf denselben Bug stößt nicht von der Hand zu weisen.
Mein Ernst! Vom vmware Debakel nichts gelernt?
Proprietärer und überteuerter Dreck – hat in einem offenen und automatisierten GitOps Workflow nichts zu suchen. Da hast Du schon einen hochanpassbaren und skriptfähigen HV Cluster und dann holst Du Dir so eine Reverse-Ransomware, das sind für mich proprietäre Backup-Lösungen, die mit Abo-Modellen die Hand aufhalten ins Haus? Dein Ernst?
Was bist Du? Admin oder ersetzbarer klicki-Bunti-Produktbediener?
Hier habe ich einem mitelständischen Unternehmen dezente 17K Lizenzkosten mit einem GitOps Workflow eingespart:
https://blog.jakobs.systems/blog/20240908-gitops-veeam-ersatz/
und gleichzeitig mit "digitalen zwillingen" eine automatisierte überprüfung der Backups und Hot-Stand-By Systeme beschwert:
https://blog.jakobs.systems/micro/20241016-hyperv-backups-faq/
17k für 5 Jahre, also lediglich 3.400€ pro Jahr. Und dafür den ganzen Aufriss?
Bei der Sicherung auf "externe USB-Medien" habe ich dann aufgehört zu lesen.
bei meinen Test restores verlief mit Veeam und Proxmox alles problemlos, der VM Storage läuft bei mir aber auch separat getrennt vom System und ist nicht nur Raid1
Da könnte ich mir für's Recovery nur einen temporären (häßlichen) Workaround vorstellen.
Einen zusätzlichen Host ins Cluster einhängen und die Restore Aktionen darauf machen. Anschließend die wiederhergestelle Maschine an den Ursprungsort verschieben.
Cluster? Bei Proxmox-Clustern wird Ceph genutzt. Da das Problem aber ZFS betrifft, handelt es sich um Single-Nodes.
Quark. Wir haben einige Cluster die nur mit ZFS eingerichtet sind. Solange die Pools gleich heißen kann man sogar zwischen den Nodes replizieren, aber natürlich sind das keine HA Cluster wie bei Ceph.
proxmox mit ZFS clustern? Naja, viel Spass.
Genau so betreibe ich meine Cluster, spart in kleinen Umgebungen Hardware und ist vertretbar wenn man Datenverlust der letzten 2 Minuten tolerieren kann.
Nuja, man kann auch einen PVE Cluster mit einem shared Storage betreiben. Zumindest habe ich das ne weile im Homelab so gemacht, als ich von ESXi auf PVE gewechselt bin.
Wie das ganze produktiv dann laufen würde..kp – da nutzen wir bisher noch VMWare, aber kommt halt auch auf die Umstände an.
ich habe 2 Nodes auf denen eine VM mit 80 TB Daten so synchronisiert wird, alle 2 Minuten. Der Sync dauert in der Regel ca. 5 Sekunden.
Für den Fall das das alles trotzdem zusammenbricht, haben wir noch extern ein Rsync Backup. Aber seit 1,5 Jahren läuft es problemlos auch mit Upgrade von Version 8 auf 9
Meiner Meinung nach ist das ein falsch dimensionierter Storage 2x 8TB NVMe PCI-e 4.0 in ZFS RAID 1, ich kenne jetzt zwar nicht die NVMe Modelle, würde mich auch noch interessieren, aber da wundert mich das Auftreten von I/O starvation defintiv nicht. Es ist scheinbar nicht Mal System vom VM Storage getrennt, das heißt OS kämpft mit dem VM Storage um Ressourcen.
(HW Config bezugnehmend auf den Thread starter im Proxmox Forum)
Es sollen Samsung PM9D3A sein, die dürften dem Stress gewachsen sein.
Interessant aus meiner Sicht ist eher die Virtio-Version IN den betroffenen Windows-VMs. Solange die VMs laufen und bei Proxmox-Upgrades mitgeschleppt werden, wird das Upgrade der windows-internen Virtio-Treiber gerne mal geschlampt oder vergessen.
Für die betroffene Konfiguration wird virtio 0.1.266 – 0.1.271 empfohlen, ältere und neuere Versionen gelten als problematisch.
ok die SSD an sich schon, aber im Raid1 nicht vor Allem wenn dort auch System und VM Storage zusammen liegen.
Guten Tag in die Runde,
Kann von ähnlichen Problemen berichten, wobei wir bisher keine Datenverluste festgestellt haben.
Während einer VM Wiederherstellung, aus dem PBS heraus, sind uns mehrere VMs auf dem betroffenen Node eingefroren. RDP session zu den VMs waren weg, Last auf dem Node schoß um ein vielfaches nach oben, normalerweise langweilen sich unsere CPUs, aber nicht zum Zeitpunkt des Restore Tests. Wir haben für das OS und die Daten der VMs unterschiedliche ZFS pools, von der Performance her sollte alles smooth laufen, tut es aber nicht. NVMes sind super schnell, RAM und CPU ausreichend vorhanden, trotzdem läuft das Wiederherstellen aus dem PBS nicht rund. Ganz und gar nicht. Sind mit Proxmox an der Sache dran, Ticket wurde geschrieben, hoffe auf baldige Lösung.
PVE und PBS sind auf dem neuesten sw Stand.
Mag sein, dass es nicht alle ZFS Konfigurationen betrifft, bei uns ist es leider der Fall.
Beste Grüße
Das Problem besteht in beide Richtungen, auch wenn man ein Backup macht.
Ich hab selbst vor einigen Monaten einen PBS eingerichtet und bin zu folgendem Schluss gekommen, auch mithilfe von Teilnehmern im Proxmox Forum.
Vier Probleme treffen hier zusammen:
1.) Wenn Proxmox VE einen 4 MB Datenblock liest, um ihn zum PBS zu schicken, dann wird auf diesen Datenblock der Zugriff bis zum fertigen wegschreiben gesperrt.
Das ist (halbwegs) unkritisch, sofern der PBS sehr schnell angebunden ist, weil die VM bzw. der virtio Treiber auf den Zugriff wartet, analog dazu wie ein Festplattentreiber darauf wartet, dass eine HDD den passenden Datenblock physisch angesteuert hat, bevor er geliefert wird.
Entschärfen kann man das, wenn man im Backupjob des PBS "Backup Fleecing" einschaltet, dann wird der Block lokal zwischengeschrieben, damit die Sperre des Datenblocks zeitlich deutlich kürzer ausfällt.
Mir ist aber bitter aufgestoßen, dass das Fleecing an diesem automatisierten Backup-Job hängt, den man eingerichtet hat. Mache ich ein manuelles Backup einer Maschine über den "Backup now" Button, greift das Fleecing nicht, mit der Konsequenz dass die Maschine sich aufhängt, bis hin zur Datenkorruption des Hosts (nicht nur des Backups!) Für ein "Backup-now" schon ein ziemlicher Worst Case.
2.) Die VM sollte den ZFS-Arc Cache nicht nutzen und auf No Cache eingestellt sein.
3.) Darüber hinaus hat die aktuelle Version des virtio-scsi Windows Treiber .285 einen Bug* bzgl. einer Racekondition. Die Auftrittswahrscheinlichkeit des obigen Fehlers ist dadurch erheblich erhöht und Backup-Fleecing alleine reicht nicht zuverlässig, um das Auftreten des Problems zu verhindern.
4.) Der Einsatz von Datenbanken im Allgemeinen und MSSQL im Speziellen scheint das Problem erheblich zu fördern.
Was ist die Folge?
Der virtio-Treiber steigt aus, im Ereignismanager sieht man dann "Ein E/A Vorgang konnte nicht ausgeführt werden und wurde wiederholt" oder "Der RAID Controller wurde aufgrund eines Problems zurückgesetzt".
Weitere Folgen sind das schlussendliche Einfrieren der Maschine.
Beim Einsatz von MSSQL kommt es zur Datenbankkorruption. Korruption des laufenden Hosts, wohlgemerkt. Es ist nicht nur das Backup kaputt, sondern der laufende Host – durch das Anfertigen eines Backups mit einem Backup-Server, der über 1.000 € jährlich an Lizenzkosten kostet – seit über einem Jahr [sic!]
Und nu?
Ärgerlich war bei mir, dass ich mich mit dem PBS _zusätzlich_ zum lokalen Backup absichern wollte und gleich 'als Belohnung' in die Datenbankkorruption von MSSQL gerannt bin.
Nachdem ich das Problem evaluiert hatte, habe ich den Treiber .271 installiert und Backup Fleecing eingestellt. Das Problem trat dann aber erneut auf, weil ich eine Maschine außerhalb des "Backup-Fleecing-Aktiviert"-Backup Jobs manuell gesichert hatte.
Für ein Enterprise-Produkt ist das aus meiner Sicht ein No-Go. Da sitzen Leute, die sich um mehr als ein Thema kümmern und da kann man nicht sagen: Lies halt die Anleitung, zumal das so auch aus der Anleitung nicht hervorgeht und nun schon einige Jahre so besteht.
Dass das auch in die andere Richtung beim Zurückspielen passiert macht es nicht besser.
* https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers#virtio-win_Releases
Danke für die ausführliche Darstellung. Wir erwägen nächstes Jahr 5 Cluster nach Proxmoxx zu migrieren. Das liest sich in der Tat nicht wie ein Enterprise Produkt.
Wir bleiben bei VMWare. Alternativ bestenfalls noch Hyper-V
Na gut das Vmware nie massive Probleme hatte. Ja,,ist mehr als ärgerlich aber wichtig ist jetzt eher wie der Hersteller reagiert.
Shit happens.
zu beachten auch, Proxmox beherrscht noch keine Fault Tolerance, ist im Cluster Bereich also nur bedingt einsatzfähig.
Proxmox unterstützt HA-Fencing. Aber kein Zero-Down Fault Tolerance. Das ist richtig. Aber dafür greift man auch bei VMware tief in die Tasche um das erreichen zu können. Hier sollte man mal die Kirche im Dorf lassen. Wer das unbedingt braucht, der wird auch das Geld aufbringen müssen. Aber ansonsten, für ein auf OpenSource-basierendes System, wird einem verdammt viel geboten. Wo andere Lösungen viel Geld verlangen.
Ich kann diesen Fehler beim besten Willen nicht nachstellen.
Eventuell hängt es ja mit der Archtektur der PVE zusammen. Ersten habe ich fast nur noch AMD Server im Zugriff und mein Server mit Intel in der Testumgebung hat nur eine CPU.
Das könnte einer der schönen NUMA Bugs sein.
Langsam angebundner Proxmox Backup Server mit ausgeschaltetem Backup-Fleecing, virtio Treiber .285.
Zur Krönung noch eine Datenbank.
Ohne PBS trat der Fehler trotz .285 bei mir vorher auch nicht auf, aber die I/O Last im PBS, gerade wenn er langsam angebunden ist, die ist immens.
Es ist ja gut, dass du das Problem nicht hast, aber "works on my machine" ist nicht die Lösung. Der Fehler ist eine Katastrophe
Wir haben ähnliche Beobachtungen bei der Einführung von pve und pbs gemacht, wobei auch das migrieren oder moven von vms bzw. Diskussionen solche Effekte auslöste. Symptom war immer hoher i/o Pressung Stall, denn stürzten vms ab oder reagierten nicht mehr. Wir haben dann für alles in den clusteroptionen bandwidth Limits vorgegeben, bei denen dss noch nicht passiert, und fleecing disks eingebaut. Wir haben das PVE auf LVM, storage getrennt als lokales ZFS RAID1 auf schnellen NVME oder SAS ssds. Ich muss mich da auch mal in die community einklinken, evtl kann ich da noch was beitragen. Ich war mittlerweile davon ausgegangen dass das normal ist ….
Also ich kann das bestätigen. Beim Backuppen via PBS kam es zu exorbitant hohen Loads der Server, die ich mir nicht erklären konnte. Da die Backups ja normal außerhalb der Betriebszeit läuft fiel es bislang kaum auf. Ich bin gespannt wo da die Ursache liegt.
mal dumm gefragt, ich habe das so verstanden, das der I/O load der restore Funktion, irgendwann den laufenden VMs die Luft abschnürt und diese korrupiert.
Bedeutet das als intermediäre Lösung, ich schiebe als stolzer Proxmox Cluster Besitzer, die laufenden VMs auf einen anderen Node, bevor ich ein Restore anstoße, oder anders herum, ein Restore auf einen nackten Node und dann auf den richtigen Node verschieben ist unkritisch?
Und wenn wir schon dabei sind, wenn die Restore Funktion betroffen ist kann es sein, dass dann auch das Verschieben eines Gastes innerhalb eines Clusters zu gleichen Problemen führen kann?
Also ich kann da jedem Proxmox Enterprise Nutzer nur den Daumen drücken, dass dieser Kelch an ihm vorbei geht. Als Admin für 15 Jahre und einer VMware ESX / vshere Umgebung mein 2 Cents Erlebnis :
Gestartet 2009 kurz nach nach Release von ESX 4.0
Von Dell die ersten Nehalem GameChanger Hosts R610 (2x) und MD3000i ISCSI SAN. (Dual Controller, je 2x lan je Controller)
Da machte das SAN nach einer Erweiterung um 3 weitere Platten (1x fürs raid1 und 2x raid5) Voodoo.
Im laufenden Betrieb Controller 1 reboot.. 2min später controller 2.. das dann so alle 2-3 tage…
Controller Tausch und FW Update brachten nix.. am Ende wurde nach 1,5 Monaten die SAN getauscht..
und die 4h Reaktionszeit des SLA.. die haben erst begonnen, als der Dell Support Remote den HW tausch freigab.
Aber : Trotz 16 VMs mit DC, SQL und oracle server .. alle VMs und die vranger Backups liefen dabei durch. Kein datenverlust oder gar größere Performance Einschränkung.
Würden wohl viele noch vsphere, nutzen wäre da nicht Broadcom..
Daher sollte proxmox das ASAP lösen. schon die Release Notes mit „should be solved" ist sehr viel Hoffnung.
Moin,
mir fehlen hier einige wichtige Punkte (hab ich auf die schnelle nicht gefunden).
1. PBS mit HDD (Proxmox empfiehlt SSD/NVME) im Einsatz? Hier ggfls. der Hinweis bei HDD Einsatz ist es imho zwingend erforderlich ein extra NVME (Raid1) für die Caching/Metadaten einzusetzen. Ebenfalls muss man genau überlegen (Bei ZFS) ob mehrere Raid1 (im Pool) nicht besser sind als ein einzelnes Raid5.
2. Anbindung Netzwerk (10Gbit ist imho minimum)
3. Proxmox Konfig (auch hier würde ich 2x Boot Proxmox NVME/SSD + 2xDATA nvme Raid1) oder besser 2x Boot (Proxmox) + 4xnvme im Raid-10 empfehlen).
4. kein Einsatz von irgendeiner Antivirensoftware (oder nur mit Ausnahmen)
5. ggfls. Check wg. Raid Controller (ein Nogo bei ZFS) oder prüfen ob IT Modus (und PCIe Slot) richtig geht (insbesondere mit NE-Karten).
Ich hatte auch schon NFS Systeme mit günstigen XEONs die einfach den Durchsatz nicht schafften und genau das Phänomen zeigten. Mittlerweile nutzen wir nur noch midrange CPU (bei uns AMD) mit U2/U3 Wechselrahmen und NVME. (Enterprise Micron, Samsung etc. )
Da fehlt mir Input :), aber ich hoffe mal das sich durch den Support lösen lässt, falls es doch ein ZFS oder anderer Fehler ist.
Just my 2 Cent
John
Für das Raid braucht man bei ZFS keinen Hardwarecontroller, das macht ZFS Raid Z1/-2/-3 effizienter auch im Hinblick auf schleichende Datenkorruption.
Wir haben auf unserem Main Node 3 x RaidZ1 mit je 3x 24 TB HDDs in einem 132 TB Pool.
Proxmox und Cache auf NVME, VMs sind auf lokalem ZFS Storage auf dem HDD Raid.
Auf dem "Backup Node" 16 x 14 TB HDDs in 4 RaidZ1 mit je 4 HDDs.
Das letzte mal habe ich vor ca. 2 Monaten eine VM auf einen anderen Node migriert, ohne Probleme. Ich vermute das tritt nur mit PBS auf, den wir nicht nutzen.
Proxmox VE und auch seine Backups sind übrigens storage-agnostisch. Als Workaround ließe sich das Backup einer VM auch auf ein anderes FS als ZFS zurücksichern.
Das ist aber doch für so ein Problem kein wirkliches dauerhaftes Fix. Leider gab es schon öfter Diskussionen bei Proxmox im Forum zu ähnlichen Themen. Man kann nur hoffen, dass das Problem eingrenzt werden kann im 1. Schritt.
Liebe Kollegen und Foren-Poster,
da hier viel diskutiert wird, ich bin der betroffene Verantwortliche:
a) Es ist in dem Fall sogar ein Dual AMD CPU System 96 x AMD EPYC 7443 24-Core Processor (2 Sockets).
b) Das System hat 1 TB Arbeitsspeicher bei durchschnittlich 600 GB Nutzung, d.h. hier sollte kein Problem für ZFS auftreten.
c) Es sind ausschließlich NVMe von Samsung für Datacenter verbaut. Auch getrennt für Hypervisor und Daten.
d) Das Freeze bei den Backups zum PBS können wir so partiell, bei Restore vollständig bestätigen. Die Auslastung des Hostssystem liegt nachweislich bei durchschnittlich 10% CPU und ca. Load ~ 7-10.
e) Teile der Windows-Server sind durchaus mit Datenverlust beschädigt gewesen und waren nicht mehr in der Lage, zu booten. Gleichwohl kann ich auch Probleme mit MSSQL bestätigen und auch Probleme mit einigen Debian Gästen.
Ich bin mir nicht sicher, wieso und weshalb dieser in meinen Augen recht gefährliche Fehler auftritt. Es kann "alles" sein, PBS, ZFS, VirtIO. Ich kann nur im Interesse aller darum bitten, dass wir uns hier nicht jeder gegenseitig die fachliche Kompetenz abstreiten, so klang es oft, leider, oder unterstellen, man hätte die falsche Hardware im Einsatz. Ich hoffe einfach nur, dass das Problem ernsthaft gefunden wird.
Hallo guyman,
welche virtio Version habt ihr bei den Windows VMs im Einsatz? Wie ist euer Proxmox Backup Server angebunden und aufgebaut? Sind dort ebenfalls Daten und OS auf getrennten Medien? Wie ist auf dem BS der Zpool aufgebaut? Verwendet ihr auf eurem BS im Zpool ein Special Device?
Konntet ihr nach der festgestellten Korruption der anderen VMs diese wiederherstellen aus dem Backup?
Wir haben AMD EPYC 9124, 128 GB Ram, Micron 7450 NVME und 24 TB HDDs im Einsatz, bisher ohne Probleme, aber eben kein Einsatz von PBS (Replizierung über geteilte lokale ZFS Pools), Backup über Synology Active Backup / Rsync / Band.
bei mir auch alles erst seit PBS. ohne PBS lief die virtio 285 fein, genauso wie backup mit vzdump oder dd vom zfs snapshot.
auch MySQL hat keine Probleme gemacht
Habt ihr ausgeschlossen, dass es sich um das bekannte Problem der Kombination Samsung SSDs und AMD SATA Controllern handelt? (Ich weiss nicht, ob NVME davon nicht betroffen war). Abschalten von Native Command Queuing (NCQ) hilft normalerweise, allerdings ist dann die Performance nicht gut.
Wir hatten das Problem auf älteren Epyc Systemen mit 7281 CPU und SM883 SSDs.
NVME kann nicht über SATA, NVME nutzt direkt PCIe damit sonst nix mehr dazwischen ist und Performance kosten könnte.