Edvvde 7 Geschrieben 30. Juli Melden Teilen Geschrieben 30. Juli Hallo zusammen, wir haben auf einem Windows Server 2022 das Problem, dass die Datenpartition (Volume D) als RAW angezeigt wird (nach Neustart) und ein Zugriff somit nicht mehr möglich ist. Das ursprüngliche Dateisystem war REFS. Sowohl Systemplatte C also auch Datenpartition D sind via RAID-Controller auf einem RAID10. Hat hier vielleicht jemand eine Idee? Danke euch! Zitieren Link zu diesem Kommentar
cj_berlin 1.306 Geschrieben 31. Juli Melden Teilen Geschrieben 31. Juli Patches installiert? Das hat es schon mehrmals gegeben, den letzten Patchday habe ich nicht verfolgt, wäre aber nicht undenkbar. Was sagt denn das System-Eventlog beim Booten zu dem Thema? Zitieren Link zu diesem Kommentar
Beste Lösung Edvvde 7 Geschrieben 31. Juli Autor Beste Lösung Melden Teilen Geschrieben 31. Juli vor 1 Stunde schrieb cj_berlin: Patches installiert? Das hat es schon mehrmals gegeben, den letzten Patchday habe ich nicht verfolgt, wäre aber nicht undenkbar. Was sagt denn das System-Eventlog beim Booten zu dem Thema? Es wurden in diesem Fall keine Patches installiert ... das es hier mal Probleme gab mit Updates konnte ich durch etwas Recherche auch in Erfahrung bringen. Das REFS Volume war nach einem Neustart einfach nicht mehr zugreifbar (als RAW Basisdatenpartition angezeigt). Im Anhang Screenshots aus dem Eventlog, in 12 Jahren habe ich das so noch nicht erlebt ... Lösung: Habe zwar - trotz eingelegter Nachtschicht - keinen Weg gefunden, dieses Volume ohne Formatierung wieder nutzen zu können. Jedoch konnte ich alle für uns wichtigen Daten aus diesem RAW Volume wiederherstellen. Dafür kam ein Bordmittel zum Einsatz, welches scheinbar nicht wirklich oft genutzt bzw. nur sehr sehr selten beschrieben wird: REFSUTIL Durch den "Vollständigen automatischen Modus: refsutil salvage -FA <source volume> <working directory> <target directory>" konnten alle Dateien (in diesem Fall *.vhdx) aus dem RAW Volume auf ein Netzlaufwerk wiederhergestellt werden. Es hätte hier natürlich auch ein Backup gegeben, welches jedoch den Verlust von ca. 24h an Daten zur Folge gehabt hätte. Zitieren Link zu diesem Kommentar
NilsK 2.918 Geschrieben 31. Juli Melden Teilen Geschrieben 31. Juli Moin, Hm, das ist heftig. Danke für die Rückmeldung und gut, dass es geklappt hat. Gruß, Nils 1 Zitieren Link zu diesem Kommentar
da_flo 11 Geschrieben 31. Juli Melden Teilen Geschrieben 31. Juli Ist der Server virtualisiert? Wenn ja welcher Hypervisor setzt Ihr ein? Zitieren Link zu diesem Kommentar
Edvvde 7 Geschrieben 31. Juli Autor Melden Teilen Geschrieben 31. Juli vor 1 Stunde schrieb da_flo: Ist der Server virtualisiert? Wenn ja welcher Hypervisor setzt Ihr ein? Ist ein Hyper-V Host, Server 2022 Zitieren Link zu diesem Kommentar
Weingeist 159 Geschrieben 5. August Melden Teilen Geschrieben 5. August Auch wenn als gelöst markiert, war das Volume durch 2022 erstellt worden oder hast Du es von einem älteren OS übernommen? Da habe ich mal von einem Szenario gelesen, dass dies in seltenen Fällen Probleme machen kann. Habe mich nicht näher damit befasst weil ich immer neu erstellt habe. Es würde mich aber brennend interessieren wie der exakte Werdegang war. Hatte schon ewig und retour kein zerschossenens ReFs mehr. Überhaupt braucht es dafür unter normalen Betriebsbedingungen sehr viel. Ganz am Anfang - so vor 10-12 Jahren - führte das Überlaufen eines Volumes zu einem solchen Szenario. Wobei das wenn ich mich richtig erinnere nicht durch das "normale" kopieren zustanden kam, sondern wenn eine Datei die grösser als der freie Platz war, abgeändert wurde. Mittlerweile gibt es da aber entsprechende Sicherheitsvorkehrungen. Zitieren Link zu diesem Kommentar
Edvvde 7 Geschrieben 5. August Autor Melden Teilen Geschrieben 5. August vor 4 Stunden schrieb Weingeist: Auch wenn als gelöst markiert, war das Volume durch 2022 erstellt worden oder hast Du es von einem älteren OS übernommen? Da habe ich mal von einem Szenario gelesen, dass dies in seltenen Fällen Probleme machen kann. Habe mich nicht näher damit befasst weil ich immer neu erstellt habe. Es würde mich aber brennend interessieren wie der exakte Werdegang war. Hatte schon ewig und retour kein zerschossenens ReFs mehr. Überhaupt braucht es dafür unter normalen Betriebsbedingungen sehr viel. Ganz am Anfang - so vor 10-12 Jahren - führte das Überlaufen eines Volumes zu einem solchen Szenario. Wobei das wenn ich mich richtig erinnere nicht durch das "normale" kopieren zustanden kam, sondern wenn eine Datei die grösser als der freie Platz war, abgeändert wurde. Mittlerweile gibt es da aber entsprechende Sicherheitsvorkehrungen. Der Host wurde letztes Jahr direkt unter 2022 aufgesetzt, also kein Upgrade oder sonst was ... Zitieren Link zu diesem Kommentar
Weingeist 159 Geschrieben 5. August Melden Teilen Geschrieben 5. August ReFs crasht grundsätzlich nicht einfach so, normal hat das eine gravierende Ursache und die musst Du herausfinden. Durch sein Design können sich die Sicherheitsfeatures die ein Crash des Fs verhindern sollen, aber je nach Situation nachteilig statt vorteilig auswirken. Also nur ein Reboot und dann wars Geschichte und vorher keine Probleme? Darf man fragen warum er dann einen Neustart braucht wenn man nichts gemacht hat? Crash? EventLog gab nix her? Dedupe aktiv oder nicht? Wenn das ein RAID 10 ist (Was für ein Controller? Pseudo oder richtiger?) Warum hat das OS und die Datendisc kein eigenes Volume? RAM-Probeleme könnte ich mir heute am ehesten noch vorstellen, dass es bei ReFs auch heute noch Ärger machen könnte. Zum Beispiel ein Memory-Leak oder ein RAM-Fehler. Bei ersterem Crasht normal irgendwann das OS. Erkennbar ist es daran, dass der effektiv "freie" RAM (Kontrolle z.B. mit dem Ressourcenmanager) immer kleiner wird und jener der bereinigt werden könnte, nicht bereinigt wird. Geschieht gerne mal bei langer Laufzeit. Ein abgeschossenes ReFs hatte ich deswegen aber nie. Richtige RAM-Fehler können insbesondere wenn sie nicht als solche erkannt werden, alle möglichen Auswirkungen haben. ReFs nutzt ziemlich exzessiv RAM wenn z.B. Dedupe aktiv ist. Fehlendes ECC ist dann ein Totschläger. Zitieren Link zu diesem Kommentar
Nobbyaushb 1.464 Geschrieben 6. August Melden Teilen Geschrieben 6. August Ich hatte sowas mal als die Firmware auf dem RAID-Controller ein Update bekommen hatte Bis zum Reboot war alles gut Ich weiß inzwischen, das man zuerst den neuen Treiber installieren muss... Von daher würde mich mal der Grund interessieren, wenn sowas wieder passiert hat man ja erst mal Spaß... Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.