[English]In Windows Server 2025 besteht das Problem, dass ReFS-formierte Datenträger zu einer starken CPU-/RAM-Auslastung führen, so dass der Server mit der Zeit unbrauchbar wird und neu gestartet werden muss. Nun deutet sich an, dass dieser Bug im August 2025 durch ein Update gefixt werden soll.
Worum geht es beim ReFS CPU/RAM-Bug?
In Windows Server 2025 wird das bereits in Windows 8 eingeführte ReFS-Dateisystem (Resilient File System) für Datenträger unterstützt. Microsoft verspricht, neben der Kompatibilität mit dem NTFS-Dateisystem, jede Menge Vorteile wie ein Transaktionsmodell für Erhaltung der Konsistenz samt Prüfen von Daten beim Lesen und Schreiben, eine Fehlertoleranz durch Redundanz, bei erkannten Datenfehlern eine Autokorrektur, etc. Von Microsoft gibt es den Beitrag Resilient File System (ReFS) overview mit einigen Erklärungen.
Der ReFS-Bug in Windows Server 2025
Es gibt in Windows Server 2025 allerdings einen fiesen Bug im ReFS-Dateisystem. Blog-Leser Daniel A. beschreibt in diesem Kommentar von Mitte Mai 2025, dass es unter Windows Server 2025, in Verbindung mit ReFS-formatierten Laufwerken, zu einer massiven Auslastung von CPU/RAM komme. Das geht wohl soweit, dass der Server nach kurzer Zeit unbenutzbar wird, es hängt davon ab, viel CPU/RAM verbaut ist. Dann bleibt nur ein Neustart des Servers, um diesen weiter nutzen zu können. Ich hatte das Ganze im Beitrag Stiefkind ReFS-Dateisystem – CPU/RAM-Auslastungs-Bug in Windows Server 2025 ungefixt bereits Mitte Mai 2025 aufgegriffen.
Microsoft arbeitet an einem Fix
Laut Daniel wurde der Bug von Microsoft gegenüber dem Backup-Anbieter Veeam bestätigt. Im Veeam-Forum gibt es die Diskussion im Thread Server 2025 – high CPU and RAM. Der Leser merkte in seinem Kommentar noch an, dass Microsoft den Veeam-Entwicklern wohl einen nicht öffentlich verfügbaren Patch (für Tests) geschickt habe.
Kommt der Fix für ReFS-Bug im August 2025?
Im Mai 2025 beklagte sich Leser Daniel, dass der Ressource-Bug mit dem Mai 2025-Update für Windows Server 2025 nicht beseitigt worden sei. Auch im Juni 2025-Update ist mir nichts diesbezügliches aufgefallen.
Aber es tut sich scheinbar war. Zum Juli 2025-Patchday wird es meinen Informationen nach auch noch keinen Patch zur Beseitigung des CPU/RAM-Bugs in Windows Server 2025 gaben.
Blog-Leser Sam hat sich aber zum 4. Juni 2025 bei mir im englischen Blog mit diesem Kommentar gemeldet. Es sieht wohl so aus, dass Veeam-Mitarbeiter und möglicherweise Forenteilnehmer vorab den Fix in einer privaten Preview erhalten haben. Genannt wird hier das Update KB9178699 (es gibt noch keinen Microsoft Support-Artikel dazu).
Ein Veeam-Forenteilnehmer aus Österreich hat dieses Update wohl direkt von Microsoft bekommen und schreibt hier, dass mit der Update-Installation der ReFS-Bug beseitigt sei. Und er gibt an, dass der Microsoft Support davon ausgeht, dass der Fix im August 2025 als öffentlich bereitgestellt wird.
In einem weiteren Post im Thread hat Nutzer JFT eine Antwort von Microsoft aus einem Support-Fall eingestellt:
I just wanted to give you a quick update on the ongoing ReFS issue. Our Product Group (PG) team is actively working on the fix, and it looks like it might be scheduled for release at the end of July.
Auch dies interpretiere ich so, dass dieser Nutzer den Patch bereits Ende Juli 2025 erhalten soll. Öffentliche Preview-Updates für Windows Server 2025 gibt es meines Wissens nicht. Wenn es also kein Out-of-Band-Update Ende Juli 2025 gibt, kommt der Patch offiziell zum 12. August 2025.
MVP: 2013 – 2016
ReFS sollte ja mal eine tolle Sache werden, aber (ernstgemeinte Fragen):
1. Ist es so weit fertig, dass man es benutzen wagen darf?
2. Benutzt es hier schon jemand, und wenn ja, wofür?
Ich habe ReFS deinstalliert. NTFS ist stabil und zukunftssicher.
ReFS ist imho im allgemeinen produktiven Umfeld und sowieso als NTFS Ersatz kaum nutzbar:
1. Keine Dateikompression
2. Keine Dateiverschlüsselung (EFS)
3. Keine Transaktionen (TxF)
4. Keine Object IDs
5. Kein Offloaded Data Transfer (ODX)
6. Keine Short‑Names
7. Keine Extended Attributes
8. Keine Disk‑Quotas
9. Nicht bootbar
10. Nicht auf wechselbaren Medien verwendbar
ReFS liefert zwar Integritäts-Streams, automatisches Heilen via Storage Spaces, sehr hohe Skalierbarkeit und Block‑Cloning, doch all das nutzt wenig, wenn man NTFS-spezifische Features braucht. Für Backup-Ziele, große Datenarchive oder VM‑Storage ist ReFS gut geeignet, als allgemeiner NTFS-Ersatz jedoch nich.
Wir benutzen ReFS (auf Windows Server 2022) als Backup-Repository für Veeam, da ReFS halt Block-Cloning kann und somit bestimmte Backup-Typen keinen zusätzlichen Speicherplatz kosten. Allerdings nur auf den Datenplatten, nicht für das OS. Und wir haben noch ein zweites Backup-Ziel (Linux Maschine mit XFS).
Das ist aber auch der einzige Anwendungsfall. Alle anderen Windows Systeme arbeiten ausschließlich mit NTFS.
Abgesehen von dem aktuellen Windows Server 2025 Problem (was ja ein Bug ist) gibt es bei ReFS halt diverse Fallstricke bzw. Regeln die man strikt beachten muss, sonst hat man wirklich ein Problem. Dazu gehört halt, ReFS formatierte Platten niemals an eine andere Windows Version zu hängen, da bei neueren Versionen automatisch ein Upgrade der ReFS Version erfolgt, das man nicht verhindern kann. Da es zudem keine Abwärtskompatibilität gibt wird das Laufwerk damit für die ältere Windows Version unlesbar (wird als RAW angezeigt) und damit unbrauchbar.
Ich bin da auch übel reingefallen, habe eine Maschine mit Dual-Boot (Srv 2022 und Win11) Auf dem Server eine 2 TB SSD mit ReFS für ein paar VMs, nach Boot vom anderen OS nicht mehr lesbar…. Ich musste dann die gesamte Platte im Win11 wegkopieren, im Server eine neue Partition NTFS anlegen und dann alles wieder zurückschieben. Nach erneutem Start des Hyper V ging alles wieder, selbst die VM sind wieder gelaufen. War aber ein ziemlicher Kampf…..
Seit her ist ReFS für mich definitiv gestorben. (Block Cloning hätte ich zwar gerne wieder, aber das ist es mir nicht mehr wert.)
Zu 1. Bis Server 2022: Ja, Seit 2012 . Server 2025: Bestimmt, wenn der Bug gefixt ist. Server 2025 ist Beta und wird es auch einen Moment bleiben.
Zu 2. Hauptsächlich für grosse Datenbestände/Fileserver. Nach wie vor gibt es Einschränkungen gegenüber NTFS. MS verfolgt mit ReFs eher eine langfristige Strategie. Wenig Anpassungen, dafür möglichst zuverlässig. Schätze die wollen die Verbreitung noch gar nicht allzusehr forcieren.
Problem an ReFs wie auch anderen Dateisystemen dieser Art (z.B. ZFS): Genau die sicherheitsbildenden Eigenschaften solcher Dateisysteme können zu ihrem "Tod" führen. Festplatte voll ohne dass es abgefangen wird = Supergau. MS hat da mittlerweile viele Sicherheiten eingebaut, damit das nicht passiert. 2012 war das noch extrem heikel.
Aktuell meine Meinung: NTFS funktioniert schlicht zu gut, Software ist allgemein darauf ausgelegt, wozu wechseln. Ausser man möchte bestimmte Ziele erreichen die nur mit ReFs gehen oder die Nutzung tatsächlich Vorzüge hat.
Die Features/Techniken von ReFs spielen im weiten Sinne auch in Storage Spaces ein. NTFS profitiert dann indirekt davon. Meiner Erfahrung nach mit SSD's zuverlässige als ein Single RAID-Controller. Nur halt essig für das Boot-LW.
Aber auch SP ist nicht frei von mühsamen Kuriositäten, der Mehrheitsentscheid kommt meines Wissens leider nach wie vor nicht zu tragen in einem Mirror-Setup mit mehr als zwei Kopien. Das macht das ganze etwas absurd. Heisst: Zwei gleiche Sektoren aus drei Stripe-Sets gewinnen nicht gegen den einen falschen wenn von dem gelesen wird. Vermutlich aus Performance-Gründen. Ob 2025 daran etwas geändert hat, allenfalls Einstellungen hinzugekommen sind um Performance-Verluste hinzunehmen, habe ich noch nicht eruiert.
Vermute das ist der Grund, warum fast kein Hardware RAID-Hersteller mehr als einen Mirror erlaubt. Kein Mensch versteht es, wenn bei 3-Sets nicht die zwei gleichen herangezogen werden und der dritte korrigiert wird.
Wir sind von ReFS wieder weg, nachdem eine 63TB Partition mit Deduplizierung einfach über Nacht nicht mehr mountbar war. Ich konnte die Daten darauf wiederherstellen mit den Tools von MS, aber das hat über 1 Woche gedauert aufgrund der Datenmenge.
Ist jetzt wieder NTFS ohne Deduplizierung.
Darf man Fragen wie es dazu gekommen ist? Festplatte (fast) voll? OS gewechselt statt Repo neu aufgebaut?