[English]Information für Administratoren von Windows Server 2019, 2022, 23H2 und 2025, die Veeam Backup & Replication verwenden. Deren Veeam Agent for Microsoft Windows macht in Verbindung mit den kumulativen Updates vom März 2025 Probleme. Es kann zu einem Blue Screen of Death (BSOD) mit dem Code 0x00000149 kommen, oder es gibt einen hohen Speicherverbrauch bei ReFS-Datenträgern.
Anzeige
Blog-Leser Oliver hat mich per Mail über den Sachverhalt informiert (danke dafür). Veeam hat bereits 2018 einen Support-Beitrag ReFS Known Issues, Considerations, and Limitations zum Thema veröffentlicht, da das Problem nur Datenträger mit ReFS-Dateisystem betrifft.
In einer Aktualisierung vom 31. März 2025 heißt es im Supportbeitrag, dass die kumulativen Updates vom März 2025 für Windows Server 2025, 23H2, 2022 und 2019 bekannte Probleme haben. Diese Updates können zu einem Blue Screen of Death (BSOD) mit einem Bug-Check-Code von 0x00000149 führen. Betroffen sind folgende Updates:
- KB5053598 (Windows Server 2025)
- KB5053599 (Windows Server 23H2)
- KB5053603 (Windows Server 2022)
- KB5053596 (Windows Server 2019)
Die Auswirkungen sind unterschiedlich, je nach Update und Windows Server-Version, die mit ReFS als Dateisystem verwendet wird. Neben dem oben erwähnten BSOD kann es auch zu einem Memory Leak (wie nachfolgend beschrieben) kommen.
Microsoft hat mitgeteilt, dass an Korrekturen für dieses Problem gearbeitet wird. Voraussichtlich kommt der Fix mit den April 2025 Updates für die betreffenden Server-Versionen.
Anzeige
Windows Server 2025
Es gab mehrere Berichte über Stabilitätsprobleme im Zusammenhang mit dem Speicherverbrauch von ReFS auf Windows Server 2025, Server 23H2, Windows 11 23H2 und Azure Stack HCI 23H2 heißt es.
Für Windows Server 2025 gibt es diese Beschreibung von Dezember 2024 im Veeam-Forum. Dort verwendet ein Betroffener eine neue VM-Installation von Windows Server 2025 mit Veeam Backup & Recovery 12.3. Die alte Konfiguration wurde über ein Backup mittels iSCSI und ReFS-Formatierung darauf die neue VM migriert. Der alte Server war Windows Server 2022, wo alles funktionierte.
Nach der Migration gebe es zufällige Abstürze, der Ram-Verbrauch steigt und die CPU ist zu 100% durch den Systemprozess ausgelastet, heißt es. Vom Veeam-Support wurde vorgeschlagen, alle Veeam-Dienste zu stoppen. Das wurde versucht, aber als die iSCSI-Platte wieder angeschlossen wurde, ging die CPU-Last wieder auf 100% hoch.
Als die iSCSI-Backup-Festplatte mit ReFS-Formatierung nicht angeschlossen war und die Veeam-Dienste funktionierten, schien das System stabil zu sein. Im betreffenden Forenthread gibt es mehrere andere Nutzer, die dieses Verhalten bestätigen.
Anzeige
Kann ich bestätigen. Maschinen stürzen einfach alle paar Tage ab und werfen einen BSOD. Hatten erst in einer anderen Richtung gesucht. Auf Veeam wäre ich nicht gleich gestoßen, da der BSOD nicht immer in der Nacht zur Sicherungszeit aufgetreten ist.
Kannst du uns kurz deine Umgebung teilen und was genau abstürzt?
Kurze Frage an die Runde:
Betrifft das auch Block-Storage, der per direkt angebunden ist oder nur iSCSI und FC?
Betrifft es VM mit ReFS oder Hyper-V Hosts mit ReFS? Oder ist es wirklich nur der Windows Agent? Ich habe das Szenario für den Absturz tatsächlich noch nicht so ganz verstanden.
zwar keine Antwort auf deine Frage, eher eine Gegenfrage ;-(
Wie kann ein Windoof Patch vom März 2025 schon Probleme im Dezember 2024 verursacht haben?
"Der" Patch um den es aktuell geht – ist auf jeden Fall nicht der erste, der bei NTFS Systemen keine und bei ReFS extreme Probleme verursacht.
Aber zu deiner Frage – einen Speicher, der via ISCSI pder USB angeschlossen ist, kann man einfacher trennen, als irgendwas das per SAS/Sata angeklemmt ist.
Möglicherweise liegts aber am ReFS das ein System kennt und nicht daran, wie das Refs angeschlossen ist.
Es liest sich so, wenn das Backup Repository mit ReFS formatiert ist, dass es dann "knallt".
Dem ReFS Dateisystem wird die Anbindung des Storage egal sein.
Und wieder mal zeigt sich das refs noch weit davon entfernt ist ausgereift zu sein um sinnvoll eingesetzt zu werden – ein Job Vorgänger von mir hat eine externe Platte mit refs formatiert – sobald sich die refs build number im system an dem die Platte angeschlossen werden soll auch nur minimal unterscheidet (und das kann sich von update zu Update ändern) lässt sich die Platte nicht lesen….😂 ntfs ist vielleicht alt aber zuverlässig
ohne ReFs ist Veeam wie der Nürburgring ohne Formel 1, also sinnbefreit. Insbesondere bei GFS Strategien.
Sehr richtig. ReFS ist ein essentieller Bestandteil einer vernünftigen Backupstrategie für größere Datenmengen mit Veeam. Die Vorteile sind wirklich erheblich. Das ist sehr vermutlich auch nicht nur auf Veeam beschränkt.
Hatte bisher auch niemals Probleme.
kann ReFs denn auch immutable?
Nein – von daher Veeam Backups ohne ZFS / XFS Datenablage ist wie ein Kampf Messerjocke gegen Wolverine du weißt vorher wer gewinnt, wenn der Ransomware Vertreter dich besucht.
Wolverine ist kaputt.
Eine Backupstrategie ohne Auslagerung ist kein Backup.
Auch kann man das Repository nur für Veeam im Zugriff halten, dann kommt die Ransomware nicht dran.
Aber es soll ja Admins geben, die arbeiten am Client als Dom-Admin angemeldet und haben alle Shares verbunden.
Best practice!
Wenn du Filestrukturen mit 2 stelligen TB Mengen hast, dann wird das mit ausgelagertem Backup Repos leicht unhandlich.
"Auch kann man das Repository nur für Veeam im Zugriff halten, dann kommt die Ransomware nicht dran."
Das geht nur dann, wenn du auf dem Repo keine echtblech Systeme mitsicherst.
"Aber es soll ja Admins geben, die arbeiten am Client als Dom-Admin angemeldet und haben alle Shares verbunden."
[OT] Du liesst von jemandem, der leider Erfahrungen gemacht hat, das die Ransomwarejungs wenn die mal drin sind ziemlich alle Hebel in Bewegung setzen von denen viele nicht mal wissen, dass es diese Hebel gibt. Und die ganz schlimmen "best Pratice Besserwisser" so wie ich es einmal einer war, wissen nachher, Veeam aus der Domain nehmen, eigene Netze nutzen, Port Knocking und ähnlicher Firlefanz hält die von irgendwas ab….
Die fahren mit dem Suv zur Arbeit, nicht auf der Brennsuppe.
Die Lücke, die die finden, um sich elevated rights in deiner AD Umgebung zu besorgen nutzen die dann auch um zum Zeitpunkt, x deine Backupinfrastruktur erreichbar ist dort das gleiche zu machen.
[/OT]
Naja, also zweistellige Terrabytes auslagern ist so wild nicht. Medienbruch mit Tapes / Library sind schon ein probates Mittel.
Am Ende darf aber niemand an deine Daten ran. Sicherungen sind eben auch nur Kopien und wenn die Quelle bereits unendeckt infiziert wurde, wird es schwierig.
Veeam bietet Mittel an, aber dies ist eben auch nur ein begrenzter Schutz.
Hat da wer genauere Details zur betroffenen Systemumgebung dazu?
Denn "Veeam Agent for Microsoft Windows" hat ja nicht zwingend was mit "Veeam Backup & Replication" zu tun. Das sind ja zwei verschiedene Produkte.
Daher ist der erste Absatz in diesem Blogbeitrag für mich eher verwirrend als aufklärend.
Installiere mal Veeam Backup & Replication, dann wirst du im System auch Veeam Agent for Microsoft Windows finden.
Danke für die Aufklärung.
Ich war mit nicht sicher, ob nicht dezidiert vom Standalone-Produkt "Veeam Agent for Microsoft Windows" die Rede ist.
Ich habe das Problem auch ohne Veeam Backup & Replication auf Windows mit SSD unter hoher Last zusammen mit REFS.
nicht nur Veeam:
DZ1041341: Microsoft Defender XDR Service Health Advisory
Title: Users may experience crashes on Resilient File System (ReFS) enabled devices in Microsoft Defender
To resolve impact in the meantime, we recommended for all devices with ReFS enabled revert back to the previous update, and not utilize the KB5053606, KB5053643, KB5053602, KB5053657, KB5053603, KB5053598 or KB5053596 updates.
Was mir jetzt nicht ganz aus dem Artikel und den Kommentaren hervorgeht: Betrifft es ausschließlich die Kombi aus Veeam und ReFS oder reicht es aus, dass ein Windows Server (NTFS) den Veeam Agent installiert hat, um den BSOD auszulösen?
Wir betreiben einen Windows Server 2019 Standard als physikalischen Backup-Server. Das Betriebssystem liegt auf zwei SSDs (gespiegelt) und ist in NTFS formatiert. Dazu kommen 12 Nearline SAS Festplatten, welche zwei Veeam Repositories abbilden (je 6 SAS Festplatten im RAID-5). Diese Repos laufen unter ReFS um Deduplizierung nutzen zu können. Auf dem Server ist auch der Veeam Agent for Windows installiert, da die Systemfestplatte ebenfalls durch Veeam gesichert wird. In dieser Konstellation ist es bisher zu keinerlei Problemen gekommen. Softwareversionen:
Windows ist aktueller Patchlevel März 2025
Veeam Version ist 12.3.1.1139
Veeam Agent ist Version 6.3.1.1074
Vielleicht hilft das ganze irgendwie weiter.
Moin Zusammen,
einer unserer Kunden ist ebenfalls von diesem Problem massiv betroffen, hat jedoch kein ReFS und auf seinen HV's (WS22) ist CU 25-01 Anfang Februar installiert worden.
Weitere Details siehe …
https://administrator.de/forum/stabilitaetsprobleme-bei-windows-server-2019-bis-2025-mit-cus-ab-etwa-12-24-672317.html
Gruss Alex
Moin Moin,
bei uns kann ich es nachvollziehen, Windows Server 2025 (26100.3775) Veeam Backzup Server 12.1 mit Zugriff auf ein iSCSI Target mit ReFS formatiert, sobald ich das Target einbinde ist der Server nach 10 Minuten nicht mehr zu gebrauchen. Dasselbe mit einem NTFS Target und alles ist gut.
Gruß Jochen