11
Während eines Löschvorgangs ausgeschaltet - Dateisystem dauerhaft verwirrt
Moin Kollegen.
Was ich hier beschreibe, klingt oberflächlich vielleicht 0815, aber die Umstände sind doch sehr kurios, fast lustig:
Nach dem Februar-CU für Windows 11 waren auf einem System plötzlich 65 GB Platz weg (verglichen mit dem imagebackup von einem Tag zuvor) und es wurde eng auf c:
Analyse ergab: im Component Store Bereich "Cache and Temporary Data" (c:\windows\winsxs\temp\inflight) waren, warum auch immer, zeitgleich mit Installation des Updates 350.000(!) Ordner entstanden und eben diese enthielten diese 65 GB.
Das Problem ist für mich nicht ganz neu und es gibt Abhilfe, aber das bewährte Component Store Cleanup lief hier zwar ohne Fehler, brachte aber auf diesem System seltsamerweise nichts und der Platz blieb belegt. Vielleicht schlug dieser Cleanup fehl, da der Platz einfach zu eng war (<5GB Rest). Nun gut, bevor ich eine Sicherung einspiele, gebe ich mir doch mal den Spaß und boote WinPE (=Windows-Setup) und lösche die Inhalte des Ordners von dort aus auf der Kommandozeile (spart viel Zeit, da unter Windows ja zunächst der Besitz übernommen werden muss und auf allen 350.000 Ordnern und x Dateien für den Admin Schreibrechte gesetzt werden müssen - das muss WinPE nicht, da es sich nicht um Rechte schert). Seltsamerweise vergrößerte sich der freie Platz während des Vorgangs nicht. 30 Minuten gewartet, Befehl ist noch immer aktiv - nicht ein Byte gelöscht. VM ausgeschaltet, da sich (unter WinPE!) nicht einmal mehr die Kommandozeile unterbrechen oder schließen ließ.
Bis hierher ist es lediglich seltsam, aber nun kommt's: Nachdem ich dann doch in einem 2. Versuch unter Windows auf der elevated Kommandozeile mit icacls /setowner arbeiten wollte, meldete icacls, dass es auf Tausenden Ordnern den Besitzer nicht ändern kann, während es auf den meisten gelingt. Langsam wird's spooky. Ich nehme also so einen fehlgeschlagenen Ordner und mache die Besitzänderung von Hand im Explorer und es gelingt. Dann nehme ich statt icacls /setowner die takeown.exe und es gelingt ebenfalls - auf allen Ordnern! Sehr seltsam. Sei's drum, die Berechtigungen lassen sich daraufhin auch setzen, alles läuft ohne Fehler durch, nun sollte problemlos gelöscht werden können. Denkste: auf einem kleinen Teil von Ordnern fehlen mir angeblich nach wie vor die Zugriffsrechte. Manuell geprüft - stimmt. Warum icacls bei der versuchten Rechteänderung zuvor keine Fehler gemeldet hat? Weiß der Kuckuck. Egal, die verbleibenden 6 Ordner löschte ich ich dann eben manuell.
Und nun zum besten Teil: der freie Platz auf c: hat sich durch das Löschen lediglich auf 7 GB vergrößert. Wo der Rest hin ist, wüsste ich gerne.
Stirbt die Festplatte? Nein, es ist eine VM und das Plattensystem ist frisch.
Ist das Dateisystem der VM defekt? Nein, auch nicht, chkdsk c: /r meldet KEINE FEHLER.
Ist das geil, oder was? Der Platz ist futsch
58 GB sind im Nirvana verschwunden. Nehme ich Tools wie Treesize oder jdiskreport und starte diese als Systemkonto (höchste Rechte, die man ohne Weiteres erreichen kann) sieht man: Es sind nur 35 GB in Benutzung (so wie es auch zu erwarten ist!), es müssten ergo 65 GB der Platte frei sein, Windows meldet aber nur 7 GB! Auch dism.exe /online /cleanup-image /analyzecomponentstore liest völlig normale Werte aus und der Temp and Cache ist kleiner als 1 GB (vorher waren es ja 65!).
Selbst das Backupprogramm schreibt annährend soviele Daten weg, wie vor dem Update: die Inhalte der Platte sind (nach dem Löschen) also nahezu unverändert! Dennoch sagt auch das Backupprogramm, dass die ge-imagte Platte 100 GB hat und davon 93 belegt sind
Herzlichen Glückwunsch, Sie haben Windows nun komplett verwirrt!
An alle, die das nur quer lesen und die es nun juckt, Tipps loszuwerden: das ist kein größeres Problem. Ich habe ja ein Backup.
Ich schreibe dies hier nieder aus Belustigung und Verwunderung, da ich in 25 Jahren Sysadmin seltenst den Fall hatte, dass Treesize und Windows verschiedener Ansicht waren über den Füllstand einer Festplatte. Wenn, dann war stets das Dateisystem angeknackst und konnte mit chkdsk repariert werden - hier jedoch nicht.
Fragen dazu:
Schonmal erlebt, dass Rechteänderungen auf der Kommandozeile nicht gelingen, aber auf der GUI?
Ist chkdsk neuerdings unfähig?
Was ich hier beschreibe, klingt oberflächlich vielleicht 0815, aber die Umstände sind doch sehr kurios, fast lustig:
Nach dem Februar-CU für Windows 11 waren auf einem System plötzlich 65 GB Platz weg (verglichen mit dem imagebackup von einem Tag zuvor) und es wurde eng auf c:
Analyse ergab: im Component Store Bereich "Cache and Temporary Data" (c:\windows\winsxs\temp\inflight) waren, warum auch immer, zeitgleich mit Installation des Updates 350.000(!) Ordner entstanden und eben diese enthielten diese 65 GB.
Das Problem ist für mich nicht ganz neu und es gibt Abhilfe, aber das bewährte Component Store Cleanup lief hier zwar ohne Fehler, brachte aber auf diesem System seltsamerweise nichts und der Platz blieb belegt. Vielleicht schlug dieser Cleanup fehl, da der Platz einfach zu eng war (<5GB Rest). Nun gut, bevor ich eine Sicherung einspiele, gebe ich mir doch mal den Spaß und boote WinPE (=Windows-Setup) und lösche die Inhalte des Ordners von dort aus auf der Kommandozeile (spart viel Zeit, da unter Windows ja zunächst der Besitz übernommen werden muss und auf allen 350.000 Ordnern und x Dateien für den Admin Schreibrechte gesetzt werden müssen - das muss WinPE nicht, da es sich nicht um Rechte schert). Seltsamerweise vergrößerte sich der freie Platz während des Vorgangs nicht. 30 Minuten gewartet, Befehl ist noch immer aktiv - nicht ein Byte gelöscht. VM ausgeschaltet, da sich (unter WinPE!) nicht einmal mehr die Kommandozeile unterbrechen oder schließen ließ.
Bis hierher ist es lediglich seltsam, aber nun kommt's: Nachdem ich dann doch in einem 2. Versuch unter Windows auf der elevated Kommandozeile mit icacls /setowner arbeiten wollte, meldete icacls, dass es auf Tausenden Ordnern den Besitzer nicht ändern kann, während es auf den meisten gelingt. Langsam wird's spooky. Ich nehme also so einen fehlgeschlagenen Ordner und mache die Besitzänderung von Hand im Explorer und es gelingt. Dann nehme ich statt icacls /setowner die takeown.exe und es gelingt ebenfalls - auf allen Ordnern! Sehr seltsam. Sei's drum, die Berechtigungen lassen sich daraufhin auch setzen, alles läuft ohne Fehler durch, nun sollte problemlos gelöscht werden können. Denkste: auf einem kleinen Teil von Ordnern fehlen mir angeblich nach wie vor die Zugriffsrechte. Manuell geprüft - stimmt. Warum icacls bei der versuchten Rechteänderung zuvor keine Fehler gemeldet hat? Weiß der Kuckuck. Egal, die verbleibenden 6 Ordner löschte ich ich dann eben manuell.
Und nun zum besten Teil: der freie Platz auf c: hat sich durch das Löschen lediglich auf 7 GB vergrößert. Wo der Rest hin ist, wüsste ich gerne.
Stirbt die Festplatte? Nein, es ist eine VM und das Plattensystem ist frisch.
Ist das Dateisystem der VM defekt? Nein, auch nicht, chkdsk c: /r meldet KEINE FEHLER.
Ist das geil, oder was? Der Platz ist futsch
58 GB sind im Nirvana verschwunden. Nehme ich Tools wie Treesize oder jdiskreport und starte diese als Systemkonto (höchste Rechte, die man ohne Weiteres erreichen kann) sieht man: Es sind nur 35 GB in Benutzung (so wie es auch zu erwarten ist!), es müssten ergo 65 GB der Platte frei sein, Windows meldet aber nur 7 GB! Auch dism.exe /online /cleanup-image /analyzecomponentstore liest völlig normale Werte aus und der Temp and Cache ist kleiner als 1 GB (vorher waren es ja 65!).Selbst das Backupprogramm schreibt annährend soviele Daten weg, wie vor dem Update: die Inhalte der Platte sind (nach dem Löschen) also nahezu unverändert! Dennoch sagt auch das Backupprogramm, dass die ge-imagte Platte 100 GB hat und davon 93 belegt sind
Herzlichen Glückwunsch, Sie haben Windows nun komplett verwirrt!
An alle, die das nur quer lesen und die es nun juckt, Tipps loszuwerden: das ist kein größeres Problem. Ich habe ja ein Backup.
Ich schreibe dies hier nieder aus Belustigung und Verwunderung, da ich in 25 Jahren Sysadmin seltenst den Fall hatte, dass Treesize und Windows verschiedener Ansicht waren über den Füllstand einer Festplatte. Wenn, dann war stets das Dateisystem angeknackst und konnte mit chkdsk repariert werden - hier jedoch nicht.
Fragen dazu:
Schonmal erlebt, dass Rechteänderungen auf der Kommandozeile nicht gelingen, aber auf der GUI?
Ist chkdsk neuerdings unfähig?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671655
Url: https://administrator.de/forum/waehrend-eines-loeschvorgangs-ausgeschaltet-dateisystem-dauerhaft-verwirrt-671655.html
Ausgedruckt am: 20.04.2025 um 08:04 Uhr
11 Kommentare
Neuester Kommentar
Moin,
nur aus Interesse....hast Du die VM mal mit nem Knoppix gebootet um zu sehen, wie sich die Lage unter Linux darstellt?
Gruß
Looser
P.S.: Aber lustig ist es schon, was uns Winzigweich hier wieder zumutet.....
nur aus Interesse....hast Du die VM mal mit nem Knoppix gebootet um zu sehen, wie sich die Lage unter Linux darstellt?
Gruß
Looser
P.S.: Aber lustig ist es schon, was uns Winzigweich hier wieder zumutet.....
1
Jou, der Linuxtest kommt auch noch bevor das Image restored wird. Werde berichten.
Hast Du mal chkdsk /f /r versucht?
Moin @Starmanager
/r impliziert bereits /f.
/r impliziert bereits /f.
@Looser27
Wie zu vermuten war: auch Knoppix (wie treesize, wie jdiskreport, wie das Backuprogram) sieht den freien Speicher korrekt. Nur Windows selbst nicht. Schon ulkig.
Wie zu vermuten war: auch Knoppix (wie treesize, wie jdiskreport, wie das Backuprogram) sieht den freien Speicher korrekt. Nur Windows selbst nicht. Schon ulkig.
Moin,
hast du schon mal auf Schattenkopien geprüft? Nicht, dass da irgendwo ein Systemwiederherstellungspunkt meint die 65 GB zu bewahren 😬
Den Fall hatte ich nämlich letztens. 500 GB an Schattenkopien, wurden aber nur 2 Wiederherstellungspunkte mit ein paar GB gelistet. Musste dann manuell den Kram in die Tonne treten.
hast du schon mal auf Schattenkopien geprüft? Nicht, dass da irgendwo ein Systemwiederherstellungspunkt meint die 65 GB zu bewahren 😬
Den Fall hatte ich nämlich letztens. 500 GB an Schattenkopien, wurden aber nur 2 Wiederherstellungspunkte mit ein paar GB gelistet. Musste dann manuell den Kram in die Tonne treten.
Wo die Daten lagen, war schon lokalisiert worden, ist oben beschrieben. Die Daten sind gelöscht worden, wie zu lesen ist.
Moin @DerWoWusste,
sehr interessant was du da schilderst.
Ich hatte den letzten beiden Tagen auch mit einer sehr komischen Microsoft-Anomalie zu kämpfen, die so wie es aussieht, bei einem Server 2022 eher von dem CU 2025-01 ausgelöst wurde.
Und zwar hat mich vorgestern Abend ein Kunde angerufen und gemeint, dass einer seiner Server 2022 Fileserver nach dem Update auf das CU 2025-02 ständig nur noch in die Wiederherstellungskonsole booten würde.
Ich habe dann selber versucht über eine Stunde das Problem zu lösen, doch egal was ich gemacht habe, die entsprechende VM wollte einfach nicht mehr sauber booten.
Da es sich um einen wichtigen produktiven Server handelte, sprich, nicht wirklich viel Zeit für eine Analyse zur Verfügung stand, habe ich nach Rücksprache mit dem Kunden beschlossen die C: Platte des Servers aus einem Backup von Dienstag wiederherzustellen, sprich, dem Tag vor dem Update.
Die Wiederherstellung der entsprechenden vhdx dauerte lediglich ein paar Minuten, danach ist mir jedoch sofort aufgefallen, dass die wiederhergestellte vhdx viel kleiner war als die Defekte.
Ich habe mir dann die Backuplogs angesehen und laut diesen wurde auch eine vhdx mit ~50GB gesichert, wiederhergestellt wurde jedoch eine mit ~28GB.
Da die Zeit drängte, bin ich der Sache nicht weiter nachgegangen und habe als nächstes die defekte vhdx gegen die wiederhergestellte in der Konfig der VM kurz getauscht und habe danach die entsprechende VM wieder gestartet.
Zu meiner Überraschung startete der Server mit der wiederhergestellten vhdx, jedoch mit demselben Fehlerbild, sprich, er bootete sofort in die Wiederherstellungskonsole. 😬
Dann habe ich als nächstes die C: vhdx aus einem Backup vom letzten Samstag wiederhergestellt, habe dann diese an die VM gebunden, VM gestartet, selbes Problem. 😭
Als nächstes wurde die Boot-VXDX von einem Backup von vor 14 Tagen wiederhergestellt, selbes Fehlerbild. Auch der Restore eines Backups von vor 30 Tagen, also, bevor auf diesem Server damals das CU 2025-01 eingespielt wurde, war leider genauso erfolglos.
By the way, die VM wurde mit Veeam gesichert und laut den entsprechenden Logs, gab es bei den entsprechenden Sicherungen, nicht eine einzige Warnung.
Dann haben wir beschlossen mal die C: Platte aus einem Backup von vor ca. 60 Tagen einzuspielen, sprich, bevor das CU 2025-01 auf diesem Server eingespielt wurde und siehe da, mit dieser bootete die VM nun endlich so wie sie sollte.
Die Bewegungsdaten dieses Fileservers liegen übrigens auf anderen xhdx, daher war der Restor einer älteren C: Partition, auch absolut unkritisch.
Übrigens, auch bei diesem Restore wurden die vhdx mit nur ~28GB zurückgesichert, laut den Logs für diesen Job, wurden damals aber auch nur ~28GB gesichert.
Sprich, woher die ~22GB aus den späteren Sicherungen kamen und warum diese nicht wiederhergestellt werden konnten, wird wohl für immer ein Geheimnis von Microsoft bleiben. 🙃
By the way. Ich habe nach dem Restore gleich ein Update der VM auf CU 2025-02 versucht, jedoch ist der erste Installationsversuch auf einen Fehler gelaufen. Dann habe ich die Installation per Windofs-Update erneut angeschmissen und beim zweiten Versuch ist diese dann ohne Probleme durchgelaufen.
Ich habe die VM anschliessend gründlichst durchgeprüft und bis auf ein paar Dateifehler auf der C: Partition, die jedoch mit chkdsk behoben werden konnten, habe ich keine weiteren Probleme auf dieser VM bisher gefunden.
Habe dann noch eine Datenträgerbereinigung ausgeführt, bei der mitunter noch ein paar GB’s an Windofs-Updates bereinigt wurden und nun beträgt der Füllstand von C: nur noch ~20GB. 😁
Also nein @DerWoWusste, du bist ganz sicher nicht der einzige, dessen Windows etwas verwirrt/wirr ist. 😔
Das ist nach mehr als 10 Jahren bei uns nun übrigens der aller erste Fall gewesen, wo man aus einer Veeam Sicherung, die zuvor absolut fehlerfrei durchgelaufen ist, keine funktionsfähige VM wiederherstellen konnte. 😭
Gruss Alex
sehr interessant was du da schilderst.
Ich hatte den letzten beiden Tagen auch mit einer sehr komischen Microsoft-Anomalie zu kämpfen, die so wie es aussieht, bei einem Server 2022 eher von dem CU 2025-01 ausgelöst wurde.
Und zwar hat mich vorgestern Abend ein Kunde angerufen und gemeint, dass einer seiner Server 2022 Fileserver nach dem Update auf das CU 2025-02 ständig nur noch in die Wiederherstellungskonsole booten würde.
Ich habe dann selber versucht über eine Stunde das Problem zu lösen, doch egal was ich gemacht habe, die entsprechende VM wollte einfach nicht mehr sauber booten.
Da es sich um einen wichtigen produktiven Server handelte, sprich, nicht wirklich viel Zeit für eine Analyse zur Verfügung stand, habe ich nach Rücksprache mit dem Kunden beschlossen die C: Platte des Servers aus einem Backup von Dienstag wiederherzustellen, sprich, dem Tag vor dem Update.
Die Wiederherstellung der entsprechenden vhdx dauerte lediglich ein paar Minuten, danach ist mir jedoch sofort aufgefallen, dass die wiederhergestellte vhdx viel kleiner war als die Defekte.
Ich habe mir dann die Backuplogs angesehen und laut diesen wurde auch eine vhdx mit ~50GB gesichert, wiederhergestellt wurde jedoch eine mit ~28GB.
Da die Zeit drängte, bin ich der Sache nicht weiter nachgegangen und habe als nächstes die defekte vhdx gegen die wiederhergestellte in der Konfig der VM kurz getauscht und habe danach die entsprechende VM wieder gestartet.
Zu meiner Überraschung startete der Server mit der wiederhergestellten vhdx, jedoch mit demselben Fehlerbild, sprich, er bootete sofort in die Wiederherstellungskonsole. 😬
Dann habe ich als nächstes die C: vhdx aus einem Backup vom letzten Samstag wiederhergestellt, habe dann diese an die VM gebunden, VM gestartet, selbes Problem. 😭
Als nächstes wurde die Boot-VXDX von einem Backup von vor 14 Tagen wiederhergestellt, selbes Fehlerbild. Auch der Restore eines Backups von vor 30 Tagen, also, bevor auf diesem Server damals das CU 2025-01 eingespielt wurde, war leider genauso erfolglos.
By the way, die VM wurde mit Veeam gesichert und laut den entsprechenden Logs, gab es bei den entsprechenden Sicherungen, nicht eine einzige Warnung.
Dann haben wir beschlossen mal die C: Platte aus einem Backup von vor ca. 60 Tagen einzuspielen, sprich, bevor das CU 2025-01 auf diesem Server eingespielt wurde und siehe da, mit dieser bootete die VM nun endlich so wie sie sollte.
Die Bewegungsdaten dieses Fileservers liegen übrigens auf anderen xhdx, daher war der Restor einer älteren C: Partition, auch absolut unkritisch.
Übrigens, auch bei diesem Restore wurden die vhdx mit nur ~28GB zurückgesichert, laut den Logs für diesen Job, wurden damals aber auch nur ~28GB gesichert.
Sprich, woher die ~22GB aus den späteren Sicherungen kamen und warum diese nicht wiederhergestellt werden konnten, wird wohl für immer ein Geheimnis von Microsoft bleiben. 🙃
By the way. Ich habe nach dem Restore gleich ein Update der VM auf CU 2025-02 versucht, jedoch ist der erste Installationsversuch auf einen Fehler gelaufen. Dann habe ich die Installation per Windofs-Update erneut angeschmissen und beim zweiten Versuch ist diese dann ohne Probleme durchgelaufen.
Ich habe die VM anschliessend gründlichst durchgeprüft und bis auf ein paar Dateifehler auf der C: Partition, die jedoch mit chkdsk behoben werden konnten, habe ich keine weiteren Probleme auf dieser VM bisher gefunden.
Habe dann noch eine Datenträgerbereinigung ausgeführt, bei der mitunter noch ein paar GB’s an Windofs-Updates bereinigt wurden und nun beträgt der Füllstand von C: nur noch ~20GB. 😁
Also nein @DerWoWusste, du bist ganz sicher nicht der einzige, dessen Windows etwas verwirrt/wirr ist. 😔
Das ist nach mehr als 10 Jahren bei uns nun übrigens der aller erste Fall gewesen, wo man aus einer Veeam Sicherung, die zuvor absolut fehlerfrei durchgelaufen ist, keine funktionsfähige VM wiederherstellen konnte. 😭
Gruss Alex
@DerWoWusste
Zeigt das Windows inzwischen wieder korrekt den freien Platz an?
Ich habe einen Windows Server 2016, bei welchem seit gestern der freie Platz der Systemplatte um 20 GB weiniger ist (laut Windows), wo aber z.B. Treesize (voll eleviert ausgeführt) nur die Hälfte als belegt anzeigt.
Laut Monitoring ist das Laufwerk in ca. 20h um ca. 20GB voller geworden.
Chkdsk meckert nichts an.
Edit:
Nach dem Neustart des Server hat er mir dann ein 25GB(!) Logfile offenbart. Keine Ahnung, warum das nicht vorher angezeigt wurde.
Das Problem ist damit erstmal gelöst. Jetzt muss ich nur noch die Ursache finden, warum dieses spezielle Logfile deartig explodiert ist.
Zeigt das Windows inzwischen wieder korrekt den freien Platz an?
Ich habe einen Windows Server 2016, bei welchem seit gestern der freie Platz der Systemplatte um 20 GB weiniger ist (laut Windows), wo aber z.B. Treesize (voll eleviert ausgeführt) nur die Hälfte als belegt anzeigt.
Laut Monitoring ist das Laufwerk in ca. 20h um ca. 20GB voller geworden.
Chkdsk meckert nichts an.
Edit:
Nach dem Neustart des Server hat er mir dann ein 25GB(!) Logfile offenbart. Keine Ahnung, warum das nicht vorher angezeigt wurde.
Das Problem ist damit erstmal gelöst. Jetzt muss ich nur noch die Ursache finden, warum dieses spezielle Logfile deartig explodiert ist.
1
Hab den Edit gelesen.
Nein, zeigt er nicht an bei mir. Jedoch war das nur ein Client von 100 und die Umstände waren ja auch besonders.
Nein, zeigt er nicht an bei mir. Jedoch war das nur ein Client von 100 und die Umstände waren ja auch besonders.
(voll eleviert ausgeführt)
Als Systemkonto? Sieht mehr als der elevierte Admin.
Ich hatte beides versucht.
Ich schätze mal, das Logfile war derart blockiert, dass dessen Größe nicht in der MFT aktualisiert wurde. Oder irgendwie so. Beim Neustart habe ich CHKDSK ausführen lassen und dies wird das Problem beseitigt haben.
Ich schätze mal, das Logfile war derart blockiert, dass dessen Größe nicht in der MFT aktualisiert wurde. Oder irgendwie so. Beim Neustart habe ich CHKDSK ausführen lassen und dies wird das Problem beseitigt haben.
