Windows 2008 – 40 GB unzugänglicher Speicherplatz, vom System verwendet. Wo?

Question

Ich habe eine Kopie des Systems in einer VMWare Virtual Machine (v7) erstellt. Die Größe beträgt 7,11 GB komprimiert und 70 GB unkomprimiert (Entschuldigung, das System ist auf Französisch!) Anmeldung: adminstrateur & Passwort: T3st https://mega.co.nz/#!l981ACQK!LnLFiUD5-MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE

Auf meiner Festplatte fehlen 40 GB, und ich habe viele Dinge versucht, um sie aufzuspüren, aber ohne Erfolg ( chkdsk /r /f, Defrag, WinDirStat, Space Sniffer, Booten mit Windows Defender offline, GMER 2.1.1 Rootkit-Entfernung, Streams, vssadmin, dism usw.). Übrigens wurden die Programme als Administrator und System ausgeführt.

Den Speicherplatz können Sie hier im Detail sehen:

Die einzige Einzelheit, die ich finden kann, stammt von chksdsk, wo es heißt, dass die 40 GB vom System genutzt werden:

Le nom de volume est System.

Avertissement ! Le paramètre F n'a pas été spécifié.
Exécution de CHKDSK en mode lecture seule.

CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...
  46402816 enregistrements de fichier traités.
La vérification des fichiers est terminée.
  793 enregistrements de grand fichier traités.
  0 enregistrements de fichier incorrect traités.
  0 enregistrements EA traités.
  84 enregistrements d'analyse traités.
CHKDSK est en train de vérifier les index (étape 2 sur 3)...
  46451532 entrées d'index traitées.
La vérification des index est terminée.
  0 fichiers non indexés analysés.
  0 fichiers non indéxés récupérés.
CHKDSK est en train de vérifier les descripteurs de sécurité (étape 3 sur 3)
  46402816 SD/SID de fichiers traités.
La vérification des descripteurs de sécurité est terminée.
  24359 fichiers de données traités.
CHKDSK vérifie le journal USN...
  100 % effectués. (1212416 octets USN sur 1216272 traités)
  1216272 octets USN traités.
Vérification du journal USN terminée.
Windows a vérifié le système de fichiers sans trouver de problème.

   157701119 Ko d'espace disque au total.
    26568260 Ko dans 260039 fichiers.
      130984 Ko dans 24360 index.
           0 Ko dans des secteurs défectueux.
    46482335 Ko utilisés par le système.
       65536 Ko occupés par le fichier journal.
    84519540 Ko disponibles sur le disque.

      4096 octets dans chaque unité d'allocation.
  39425279 unités d'allocation au total sur le disque.
  21129885 unités d'allocation disponibles sur le disque.

( 46482335 Ko utilisés par le systèmebedeutet, dass 46 GB vom System genutzt werden)

Es scheint auch nicht im Ordner „System Volume Information“ zu sein:

Diskpart zeigt an, dass es sich nur um eine Partition handelt:

ich habe auch versucht, auf einer Linux-Debian-Live-CD zu booten, um die Integrität der Festplattendateien und von NTFS zu überprüfen:

Ergebnis von "du -xks ./* | sort -n" (alles ist ok)

 0          ./Documents and Settings
 1          ./autorun.inf
 1          ./boot.ini.1.cache
 1          ./boot.ini.cache
 1          ./boot.ini..cache
 8          ./BOOTSECT.BAK
 16         ./cleanmem_log.txt
 22         ./SRVPRB
 53         ./SRVLOG
 234        ./$Recycle.Bin
 376        ./bootmgr
 504        ./Config.Msi
 916        ./_icon
 971        ./SRVSCRIPT
 2443       ./SRVTOOL
 3376       ./System Volume Information
 3792       ./inetpub
 15436      ./Boot
 19636      ./SRVWEB
 169092     ./Recovery
 281139     ./ProgramData
 513829     ./SRVINFO
 1421744    ./Program Files (x86)
 1543517    ./Users
 2877066    ./Program Files
 4197856    ./SRVFPT
 14981405   ./Windows

ntfsfix & ntfsfix -d sagen, alles ist ok

aber ntfsck gibt den folgenden Fehler zurück: Fehler beim Abrufen des Bitwerts für den Datensatz {Offsetwert}

bei Google gibt es nur 2.000 Ergebnisse, einige dieser Ergebnisse verweisen auf eine NTFSK-Quelle, die anderen scheinen nicht relevant …

F: Wie kann ich diesen vom System verwendeten Speicherplatz beseitigen?

einige weitere Infos:

1. Das System kommt vom VMware-Konverter, das Originalsystem (physisch) hat das gleiche Platzproblem
2. Die Festplatte wurde mit EASEUS Partition Master verkleinert, aber das Problem bestand schon vorher
3. Wenn ich die virtuelle Maschine komprimiere, erhalte ich als Ergebnis ein 14 GB großes Tar.gz-Archiv, als ob die 40 GB leer wären

BEARBEITEN:

Der belegte Speicherplatz wurde in MFT gefunden, aber es gibt kein Tool, das ihn tatsächlich freimachen kann.

Answer 1

Haben Sie versucht, spacesnifferals Administrator zu arbeiten, wie HopelessN00b in den Kommentaren zu Ihrer Frage vorschlägt? Normalerweise klären sich die großen Unbekannten und Sie werden wahrscheinlich herausfinden, wer C:\Windows\WinSxSder Übeltäter ist. Hier speichert Windows verschiedene Versionen von .DLLDateien, um die DLL-Hölle alter Zeiten zu vermeiden. Sie können es etwas bereinigen, indem Sie dies von einer Eingabeaufforderung mit Administratorrechten aus tun:

• Dism.exe /online /Cleanup-Image /StartComponentCleanup- Dadurch wird eine Bereinigung aller Dateien im WinSxS-Ordner gestartet. Je nachdem, was Sie tatsächlich installiert haben, kann dies ein wenig oder ziemlich viel Platz sparen.

Kassedieses bisschenvon MS zu diesem Thema. Beachten Sie auch, dass der Befehl häufig mit einem Fehlercode fehlschlägt. Dies bedeutet normalerweise, dass im Ordner noch ausstehende Vorgänge (wie Windows-Updates) ausgeführt werden müssen. Insbesondere wenn eine Datei mit dem Namen vorhanden ist C:\Windows\WinSxS\pending.xml, funktioniert es wahrscheinlich nicht. Lassen Sie alle Updates installieren, führen Sie möglicherweise einen Neustart durch und versuchen Sie es dann erneut. Ich hoffe, es hilft!

Answer 2

Ich habe die VM heruntergeladen und auf einen Server geladen. Als erstes fiel mir auf, dass das Laufwerk C komprimiert war. Wenn Ihr physischer Server so ist, dekomprimieren Sie das Laufwerk. Dadurch ist wenig zu erreichen.

Nach dem Dekomprimieren habe ich überprüft, ob ich das sehe, was Sie sehen. Ich habe auch Speicherplatz hinzugefügt, um Ihren 150 GB zu entsprechen. Dann habe ich Defraggler Portable installiert und die Festplatte analysiert. Ich habe angefangen, mir die Sektoren anzusehen, um zu sehen, welche Dateien dort waren, und habe festgestellt, dass $MFT viel Speicherplatz einnimmt. Nach ein wenig Suchen habe ich festgestellt, dass das Dienstprogramm Drive Wiper von CCleaner das Problem beheben könnte.

Ich habe mit dem Löschen des freien Speicherplatzes begonnen (1 Durchgang). Die Software zeigt „MFT-freien Speicherplatz löschen“ an, aber die Aufgabe wird etwa 24 Stunden lang ausgeführt. Ich lasse sie laufen und melde mich dann wieder.

Wenn Sie suchen, finden Sie viele Informationen zu $MFT und CCleaner. Vielleicht erleben Sie einen „Heureka“-Moment, der Ihnen auf die Spur kommt, wie das überhaupt passiert ist. Ich kann an dieser Stelle nur spekulieren.

Aktualisierung 1: Der Vorgang dauerte länger als erwartet und ich habe versucht, die Leistung der VM zu steigern, aber der Fortschrittsbalken blieb stehen und die verbleibende Zeit wurde länger. Ich habe die VM mit mehr Ressourcen neu erstellt, aber es scheint keinen Unterschied zu machen. Eine verfügbare Option: Erstellen Sie eine Sicherungskopie des Laufwerks C und wenn die Sicherungskopie 18–19 GB groß ist, formatieren oder löschen Sie die C-Partition und stellen Sie die Sicherungskopie wieder her. Ich vermute, dass ein Festplattentool eines Drittanbieters für den Zustand der $MFT-Dateien verantwortlich ist.

Aktualisierung 2:

Ich konnte nur zeigen, was den Speicherplatz verbraucht. Ich konnte ihn nicht freigeben. Es gibt wahrscheinlich kostenpflichtige Tools, die helfen. Wenn Sie wissen, welche Partitionierungssoftware vor EASEUS auf dem System war, könnte Ihnen das auch helfen. Auf dem obigen Screenshot basieren die „64 % des Laufwerks“ auf der 68 GB großen VM, nicht auf der vollen 150 GB großen Partition, die Sie haben.

Answer 3

Das ist ein interessantes Problem. Ich vermute, dass es sich um ein Artefakt des physischen Systems handelt, das virtualisiert wurde, aber nicht erkannt werden kann, da die physische Ursache nicht mehr vorhanden ist.

Zwei Beispiele könnten sein:

• fehlerhafte Blöcke auf dem physischen Laufwerk, die VMware Converter erkennen und umgehen konnte, aber jetzt sind die fehlerhaften Blöcke Teil der .vmdk-Datei, jedoch nichtrealfehlerhafte Blöcke, da VMware Converter möglicherweise auf eine Kopie auf Dateiebene zurückgegriffen hat, da eine Kopie auf Bitebene fehlgeschlagen ist
• eine Art Schattenkopien, die möglicherweise von ihrer Anwendung verwaist wurden oder auf dem physischen System aufgrund von VSS-Writer-Problemen nicht erkannt wurden

Ich würde Folgendes versuchen:

1. Wenn Sie das physische System noch haben, führen Sie Ihre vollständige Analyse auch dort durch. Vielleicht haben Sie es aber bereits mit Virtualisierung versucht, um zu sehen, ob das Problem dadurch behoben wird.

2. Wenn Sie Image-Backups innerhalb der VM erstellen, versuchen Sie, die VM vollständig auf einer Test-VM wiederherzustellen und Ihre Analyse erneut durchzuführen.

3. Wenn Sie es nicht bereits für Backups verwenden, versuchen Sie, mit ShadowProtect ein weiteres Image-Backup sowohl der physischen als auch der VM-Systeme zu erstellen. Es kostet, aber Sie können eine voll funktionsfähige 30-Tage-Testversion installieren, die nach Ablauf der Testphase einfach inaktiv wird.

Sie müssen das System neu starten, bevor ShadowProtect Ihnen erlaubt, das Systemvolume zu sichern. Nachdem Sie ein Backup erhalten haben, können Sie auch versuchen, das System mit Hardware Independent Restore wiederherzustellen (Sie müssten die ShadowProtect IT Edition kaufen; meine Firma verwendet sie und sie lohnt sich, aber Sie suchen vielleicht nach kostenlosen Lösungen, sodass HIR dafür nicht in Frage kommt).

• http://www.shadowprotect.com/shadowprotect-backup-software-downloads
• http://www.storagecraft.com/support/book/storagecraft-recovery-environment-user-guide/restoring-system-volume

Zwei Gründe, ShadowProtect auszuprobieren:

• Es werden komplett separate VSS-Writer installiert, um an das Dateisystem zu gelangen. Ich habe ShadowProtect auf Systemen verwendet, auf denen jede andere Backup-Software, die mir einfällt, nicht funktioniert, weil die nativen Windows-VSS-Writer beschädigt sind.
• ShadowProtect verfügt über eine extrem leistungsstarke Komprimierung, die irrelevante Daten aussortiert. Beim Sichern virtueller Server erziele ich normalerweise eine Komprimierungsrate zwischen 50 % und 60 %. Möglicherweise kann es auch diese 40 GB Datenmüll aussortieren.

Ich bin gespannt, ob Sie der Sache auf den Grund gehen.

Answer 4

Der Speicherplatz ist mit ziemlicher Sicherheit von den Wiederherstellungspunkten belegt. Versuchen Sie, die Wiederherstellungspunkte für dieses Laufwerk unter Systemsteuerung – System – Erweiterte Einstellungen – Registerkarte Computerschutz – Schaltfläche Konfigurieren – Schaltfläche Löschen zu löschen. Sie werden sehen, dass der nicht zugängliche Speicherplatz verschwindet.