Storage Spaces Direct Pool schreibgeschützt nach NVMe-Firmwarefehler: Daten da, Zugriff weg
Mehrere NVMe-SSDs fallen gleichzeitig in verschiedenen Cluster-Knoten aus, der Windows-Storage-Spaces-Direct-Pool schaltet auf schreibgeschützt und degradiert – und lässt sich nicht mehr regulär online bringen. Die Daten sind in diesem Zustand meist noch vorhanden, nur nicht mehr beschreibbar. Genau jetzt entscheidet der nächste Handgriff darüber, ob sie es bleiben.
Am 1. September 2026 hat ein Betreiber diesen Fall öffentlich in einem Microsoft-Q&A-Beitrag beschrieben: In seinem Windows-Storage-Spaces-Direct-Cluster (kurz S2D, Microsofts softwarebasierte Speicherlösung, die lokale Laufwerke mehrerer Server zu einem gemeinsamen Pool zusammenfasst) seien mehrere NVMe-Laufwerke über verschiedene Nodes hinweg gleichzeitig ausgefallen – nach seiner Einschätzung wegen eines fehlerhaften Firmwarezustands. Die betroffenen Pools seien danach read-only und degraded gewesen und hätten sich nicht mehr normal aktivieren lassen.
Wichtig zur Einordnung: Es handelt sich bislang um eine einzige öffentlich dokumentierte Meldung. Hersteller, Modellreihe, Firmwarestand, Windows-Server-Version, Resilienzlayout und Anzahl der Nodes werden in der Meldung nicht genannt. Die einzige Antwort im Thread stammt von einem als „Independent Advisor“ ausgewiesenen Community-Mitglied – nicht von Microsoft Support und nicht vom Laufwerkshersteller. Die Firmware-Ursache ist damit eine Betreiberangabe, keine unabhängig bestätigte Diagnose. Stand unserer Recherche am 5. September 2026 gibt es zu genau diesem Vorfall keinen Microsoft-KB-Artikel, keine Herstellerstellungnahme, keinen Rückruf und keinen benannten Firmwarestand.
Warum der Pool überhaupt schreibgeschützt schaltet – und warum das gut ist
Der Schreibschutz ist kein Fehler, sondern eine Schutzfunktion. Microsoft dokumentiert das eindeutig:
„When a storage pool is in the Unknown or Unhealthy health state, it means that the storage pool is read-only and can't be modified until the pool is returned to the Warning or OK health states.“ – Microsoft Learn, Storage Spaces and Storage Spaces Direct health and operational states
Zeigt der Pool zusätzlich den Zustand Read-only / Incomplete, kann laut Microsoft ein Quorumverlust vorliegen: Die Mehrheit der Poollaufwerke ist ausgefallen oder offline. Storage Spaces setzt den Pool dann automatisch auf read-only, bis wieder genügend Laufwerke erreichbar sind.
Der Hintergrund ist entscheidend für jede spätere Datenrettung: Die Poolmetadaten – also die Verwaltungsinformationen darüber, welche Datenblöcke wo liegen – werden auf jedem Laufwerk des Pools abgelegt. Fallen mehrere Laufwerke gleichzeitig aus, ist deshalb nicht nur Kapazität weg, sondern potenziell auch das Quorum und der gesicherte Zugriff auf die Metadaten. Wer in dieser Lage Schreibzugriffe erzwingt, schreibt möglicherweise auf eine inkonsistente Struktur – und macht aus „kein Zugriff, Daten intakt“ ein echtes Datenverlust-Szenario.
Gibt es einen bekannten Firmwarefehler dahinter?
Für diesen konkreten Fall: nein, nichts Belegtes. Es existieren aber dokumentierte historische Parallelen, die zeigen, dass Firmware bei NVMe-SSDs tatsächlich ganze Cluster kippen kann:
- Intel P3x00-Familie (NVMe), Firmware vor „Maintenance Release 8“: Microsoft beschreibt in der S2D-Fehlerbehebung einen kritischen Fehler mit Symptomen wie Lost Communication, IO Error, Detached und No Redundancy sowie langsamer I/O. Empfohlen wird mindestens Maintenance Release 8; wegen abweichender OEM-Versionszeichenketten verweist Microsoft ausdrücklich an den OEM. Diese Gerätefamilie wird in der aktuellen Meldung nicht genannt.
- Samsung 980 PRO, Firmware 3B2QGXA7: Puget Systems berichtete 2023 unter Berufung auf Samsung über ein Problem dieses Firmwarestands und empfahl das Update auf 5B2QGXA7. Das ist kein S2D-Fall und ebenfalls keine Identifikation der hier betroffenen Laufwerke.
Beide Fälle sind Vergleichsmaterial, keine Erklärung. Technisch kämen neben einem Firmwarefehler genauso ein gemeinsamer Backplane-, Strom-, Treiber- oder Netzwerkfehler in Frage – solange keine SMART-/NVMe-Logs, Event-IDs, Seriennummern und Firmwarestände vorliegen.
Wer und welche Geräte sind betroffen?
- Umgebung: Windows Storage Spaces Direct mit mehreren NVMe-Laufwerken in mehreren Cluster-Nodes. Windows-Server-Version nicht genannt.
- Laufwerke: Hersteller und Modelle nicht genannt, Firmwarestände nicht genannt.
- Öffentlich belegter Umfang: 1 Betreiber-Meldung vom 01.09.2026, 1 Community-Antwort, keine Kommentare. Zahl real betroffener Organisationen, Laufwerke oder Nodes: nicht öffentlich belegt.
Praktisch heißt das: Betroffen fühlen sollte sich jeder, der einen S2D-Cluster mit NVMe-SSDs betreibt und aktuell einen schreibgeschützten oder degradierten Pool sieht – unabhängig davon, ob am Ende Firmware, Hardware oder etwas anderes die Ursache ist.
So prüfen Sie, ob Ihr Storage-Spaces-Direct-Pool betroffen ist
Die folgenden Schritte sind reine Lesevorgänge und Dokumentation. Es sind ausdrücklich keine Reparaturschritte. Führen Sie keine Schreibtests, Reparatur- oder Reset-Befehle aus.
- Lage festhalten: Datum und Uhrzeit des Ausfalls, betroffene Nodes, letzte durchgeführte Änderung (Update, Wartung, Firmware, Treiber) notieren. Vorhandene Backups und Replikate sofort gegen Überschreiben schützen – Sicherungsjobs, die auf die alten Stände schreiben würden, anhalten.
- Poolzustand nur lesend abfragen: Get-StoragePool -IsPrimordial $False | Select-Object FriendlyName,HealthStatus,OperationalStatus,ReadOnlyReason,IsReadOnly. Microsoft ordnet insbesondere Read-only/Incomplete einem möglichen Quorumverlust zu.
- Virtuelle Datenträger erfassen: Get-VirtualDisk | Select-Object FriendlyName,HealthStatus,OperationalStatus,DetachedReason. Notieren, ob Degraded, Incomplete, Detached oder No Redundancy erscheint.
- Physische Laufwerke inventarisieren: Get-PhysicalDisk | Format-Table FriendlyName,SerialNumber,HealthStatus,OperationalStatus,Size -Auto sowie für Slots und Firmwareinformationen Get-PhysicalDisk | Get-StorageFirmwareInformation. Hersteller, Modell, Seriennummer und den vollständigen Firmwarestand dokumentieren.
- Resync-/Reparaturstatus nur ansehen: Get-StorageJob. Solange Repair- oder Resync-Jobs laufen, darf in der geplanten Wartungsabfolge kein weiterer Node offline gehen.
- Firmware gegen die Freigabeliste prüfen: ausschließlich gegen die Liste Ihres Cluster-OEM beziehungsweise Integrators. Bei Hardware auf Basis der Intel-P3x00-Familie ausdrücklich klären, ob die OEM-Firmware einem Stand vor Maintenance Release 8 entspricht.
- Diagnosedaten sichern – aber nicht auf den kranken Pool: Get-StorageDiagnosticInfo sammelt Ereignisprotokolle, vorhandene Traces und Live-Dumps aller Nodes; die genaue Syntax hängt von der Windows-Version ab. Zielverzeichnis muss ein unabhängiges, gesundes Speichermedium sein.
- Tickets eröffnen: mit dieser Inventur beim Hardware-/S2D-Lösungsanbieter und bei Microsoft. Microsoft fordert bei S2D-Problemen ohnehin die Prüfung des zertifizierten Modells und die Zusammenarbeit mit dem Anbieter der auffälligen Laufwerke.
Das sollten Sie jetzt tun – Schutzmaßnahmen, die nichts verschlimmern
- Schreibende Anwendungen kontrolliert anhalten. Jeder weitere Schreibversuch auf einen inkonsistenten Pool ist Risiko ohne Nutzen.
- Keine weitere Node-Wartung starten, bevor Zustand, Resilienz und Resync-Status geklärt sind. Microsofts reguläre Wartungsabfolge (prüfen, Node drainen, gegebenenfalls Storage Maintenance Mode, Node fortsetzen, alle Storage-Jobs abschließen lassen) gilt für planbare Wartung an einem gesunden Cluster – sie ist keine Freigabe, an einem bereits read-only/unhealthy Pool weiterzuarbeiten.
- Alles dokumentieren: Pool-, Virtual-Disk- und Physical-Disk-Zustände, Seriennummern, Firmwarestände, Zeitpunkte. Diese Daten entscheiden später über die Rekonstruierbarkeit.
- Backups isolieren. Prüfen Sie, welcher Sicherungsstand wirklich vollständig und lesbar ist – auf einem separaten Medium, nicht durch Rückschreiben auf den betroffenen Pool. Wer die eigene Sicherungsstrategie danach neu aufstellen will, findet Orientierung im Backup-Assistenten.
- Vor jeder Firmwareaktivierung, jedem Schreibschutz-Reset und jedem Recovery-Override OEM, Integrationspartner und Microsoft Support einbeziehen. Weil Modell- und Firmwaredaten in diesem Fall öffentlich fehlen, ist das zwingend.
- Nur freigegebene Firmware verwenden – direkt von OEM, Lösungsanbieter oder Laufwerkshersteller, nach Prüfung der Release Notes und nach Test auf identischer Hardware.
„Firmware updates are a potentially risky maintenance operation and you should only apply them after thorough testing of the new firmware image.“ – Microsoft Learn, Updating drive firmware
Das dürfen Sie auf keinen Fall tun
Dieser Abschnitt ist der wichtigste. Die folgenden Handgriffe sind es, die aus einem rettbaren Zustand einen endgültigen Datenverlust machen.
- Den Schreibschutz erzwingen. Ein pauschaler „Force-Mount“ oder ein isoliertes Set-StoragePool -IsReadOnly $false, solange Laufwerke oder Nodes weiterhin fehlen, kann Schreibvorgänge auf eine inkonsistente Struktur auslösen. Microsoft beschreibt das Zurücksetzen auf read-write bei Incomplete erst, nachdem fehlende Laufwerke wieder verbunden und bei S2D alle Server wieder online sind. Der Independent Advisor im Q&A formuliert es so: „There is no supported ‚force-mount‘ switch to override that protection, because doing so risks corruption.“
- Reset-PhysicalDisk auf einem betroffenen Laufwerk. Microsoft beschreibt den Vorgang als Löschen aller Daten auf dem Laufwerk. Niemals als erster Reparaturversuch.
- Clear-Disk, Initialisieren, Partitionen oder Volumes löschen, formatieren. Das löscht Volumes und damit Daten – unwiderruflich.
- S2D deaktivieren, Cluster oder Pool neu aufbauen, Clusterressourcen entfernen, solange eine Analyse oder Datenrettung offen ist. Microsofts Anleitung zum Zerstören eines bestehenden S2D-Clusters dient der Wiederverwendung von Laufwerken – nicht der Datenrettung.
- DiskRecoveryAction, DiskRunChkDsk, Data Integrity Scan und andere Recovery-Overrides ohne Diagnose. Microsoft dokumentiert diese nur für ganz bestimmte Zustände; DiskRecoveryAction kann ein Volume ohne Prüfungen read-write online bringen. Ein laufender Crash-Recovery-Scan beginnt zudem nach Abbruch oder Node-Neustart wieder von vorn.
- Ungeprüfte Firmware oder Images aus Drittquellen einspielen. Bei NVMe-Firmwareaktivierungen kann ein Laufwerk wegen eines internen Resets vorübergehend nicht auf I/O reagieren; direkte Firmware-Cmdlets auf Clusterlaufwerken können laut Microsoft I/O anhalten. Auf einem bereits degradierten Pool ist das ein zusätzliches, vermeidbares Risiko.
- Symptome überdecken. Wer bei nicht mehr lesbarem Pool „einfach neu aufsetzt“, vernichtet genau die Metadatenreste, aus denen eine Rekonstruktion sonst möglich gewesen wäre.
Es sind fast nie die Ausfälle selbst, die Daten endgültig kosten – es sind die gut gemeinten Rettungsversuche danach. Der Pool war schreibgeschützt, weil das System die Daten schützen wollte. Wer diesen Schutz aushebelt, bevor die tatsächliche Lage bekannt ist, nimmt der Datenrettung die Grundlage.
Warum dieser Fall in Profihände gehört – und wie RESQ konkret hilft
Ein schreibgeschützter Storage-Spaces-Direct-Pool nach mehrfachem NVMe-Ausfall ist kein Einzelplatten-Problem, sondern ein verteiltes Metadaten- und Konsistenzproblem über mehrere Server hinweg. Genau das unterscheidet die professionelle Datenrettung vom Versuch im laufenden Betrieb:
- Arbeit an Kopien, nicht am Original. Bevor irgendetwas rekonstruiert wird, werden die betroffenen NVMe-SSDs sektorweise ausgelesen und gesichert. Jede weitere Analyse läuft auf diesen Images. Das Original bleibt unangetastet – der entscheidende Unterschied zu jedem Reparaturbefehl, der direkt auf die Laufwerke schreibt.
- Umgang mit auffälligen Laufwerken. SSDs, die sich wegen eines internen Fehlerzustands abmelden, nicht mehr sauber antworten oder nur zeitweise erreichbar sind, brauchen kontrollierte Ausleseverfahren statt wiederholter Anschaltversuche. Für Fälle mit physisch geschädigten Datenträgern steht die Reinraumumgebung zur Verfügung.
- Rekonstruktion der Verbundstruktur. Da Poolmetadaten auf jedem Laufwerk liegen, lässt sich aus den gesicherten Images die Zuordnung der Datenblöcke oft nachvollziehen – auch dann, wenn der Pool im Cluster selbst nicht mehr online geht. Das ist Detailarbeit an Strukturen, keine Klick-Lösung. Wie das bei verteilten Speicherverbünden abläuft, beschreiben wir unter Datenrettung RAID und NAS.
- Erfahrung mit genau diesem Fehlerbild: mehrere gleichzeitig ausgefallene SSDs, Verlust der Mehrheit im Verbund, degradierter und schreibgeschützter Zustand – das ist ein wiederkehrendes Muster, bei dem die Reihenfolge der Schritte über den Ausgang entscheidet.
So läuft es bei RESQ ab: Sie schildern den Fall, wir geben eine kostenlose Ersteinschätzung – inklusive einer ehrlichen Aussage dazu, was aus unserer Sicht realistisch ist und was nicht. Danach erhalten Sie einen Kostenvoranschlag, und erst dann entscheiden Sie, ob wir arbeiten sollen. Es gibt keine Vorleistungspflicht ins Blaue hinein. Was wir nicht tun: eine erfolgreiche Wiederherstellung versprechen. Jeder Speicherverbund ist ein Einzelfall, und das gilt bei mehreren gleichzeitig ausgefallenen NVMe-Laufwerken erst recht.
Wenn Sie sichergehen wollen, dass Ihre Daten nicht durch einen erzwungenen Schreibzugriff oder einen unbedachten Reset verloren gehen, lassen Sie den Fall prüfen, bevor Sie etwas verändern: Kostenlose Ersteinschätzung und Kostenvoranschlag anfordern. Einen Überblick über Leistungen und Ablauf finden Sie unter Datenrettung bei RESQ; wer den Auftrag direkt erteilen möchte, kann ihn über das Kundenkonto als Auftrag anlegen.
Fazit: Der Schreibschutz ist Ihr Zeitfenster – nutzen Sie es
Der gemeldete Vorfall vom 1. September 2026 ist bislang ein Einzelfall ohne unabhängig bestätigte Ursache, ohne benannten Hersteller, ohne konkreten Firmwarestand und ohne offiziellen Fix. Was daran belastbar ist: Ein Storage-Spaces-Direct-Pool im Zustand Unknown oder Unhealthy ist schreibgeschützt, ein Pool im Zustand Read-only/Incomplete kann sein Quorum verloren haben – und in beiden Fällen sind die Daten in aller Regel noch da, nur nicht mehr zugänglich.
Dieser Zustand ist kein Notfall, in dem Sie sofort etwas erzwingen müssen. Er ist ein Zeitfenster: dokumentieren, Diagnosedaten auf ein separates Ziel sichern, Backups schützen, OEM und Microsoft einbinden – und keine Schreibvorgänge auf den Pool. Wenn Sie nicht sicher sind, ob der nächste Befehl hilft oder schadet, ist er der falsche Befehl.
Lassen Sie den Fall prüfen, bevor Sie den Schreibschutz aufheben. Hier geht es zur kostenlosen Ersteinschätzung – mit ehrlicher Aussage zu den Aussichten und einem Kostenvoranschlag, bevor irgendjemand ein Laufwerk anfasst.
