Назад | Перейти на главную страницу

Windows 2008 - 40 ГБ недоступного места, используемого системой. Куда?

Я создал копию системы на VMWare Virual Machine (v7), размер 7,11 в сжатом виде, 70 в несжатом состоянии (извините, система на французском!) Войдите в систему: adminstrateur и пароль: T3st https://mega.co.nz/#!l981ACQK!LnLFiUD5-MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE

На моем жестком диске не хватает 40 ГБ, и я безуспешно пробовал много вещей, чтобы их отследить (chkdsk /r /f, Defrag, WinDirStat, Space sniffer, Boot on Windows Defender offline, Удаление руткита GMER 2.1.1, потоки, vssadmin, DISM и т. Д.). Кстати программы выполнялись как admin и system

Здесь вы можете увидеть детали дискового пространства:

Единственная деталь, которую я могу найти, это из chksdsk, что говорит о том, что 40 ГБ используются системой:

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ème означает, что 46 ГБ используется системой)

Похоже, его тоже нет в папке с информацией о системном томе:

Diskpart показывает, что это только один раздел:

Я также попытался загрузиться на linux debian live cd, чтобы проверить файл жесткого диска и целостность NTFS:

результат "du -xks ./* | sort -n" (все в порядке)

 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 сказать, что все в порядке

но ntfsck возвращает сигналы следующей ошибки: ошибка при получении битового значения для записи {значение смещения}

в Google есть только 2k результатов, некоторые из них указывают на источник ntfsck, другие швы не раскрываются ...

В: Как мне устранить это пространство, используемое системой?

еще немного информации:

система исходит из конвертера VMware, исходная система (физическая) имеет такую же проблему с пространством
диск был сжат с помощью EASEUS Partition Master, но проблема была раньше
Когда я сжимаю виртуальную машину, я получил в результате архив tar.gz размером 14G, например, если бы 40Go, где пусто

РЕДАКТИРОВАТЬ :

Используемое пространство было обнаружено в MFT, но на самом деле ни один инструмент не избавился от него.

Я скачал виртуальную машину и загрузил ее на сервер. Первое, что я заметил, было сжатие диска C. Если ваш физический сервер такой, распакуйте диск. От этого мало что можно получить.

После распаковки я подтвердил, что вижу то, что видите вы. Я также добавил дисковое пространство, чтобы соответствовать вашим 150 ГБ. Затем я установил Defraggler Portable и проанализировал диск. Я начал смотреть по секторам, чтобы увидеть, какие файлы там, и заметил, что $ MFT занимает много места. После небольшого поиска я обнаружил, что утилита CCleaner Drive Wiper может это исправить.

Запустил вайп свободного места (1 проход). Программа показывает «Очистить свободное пространство MFT», но задача будет выполняться около 24 часов. Я позволю ему поработать и доложу.

Если вы выполните поиск, можно найти много информации о $ MFT и CCleaner. Вы можете найти момент «эврики», который позволит вам понять, как это вообще произошло. Я могу только предполагать на данный момент.

Обновление 1: Процесс занял больше времени, чем ожидалось, и я попытался повысить производительность виртуальной машины, но индикатор выполнения остановился, а оставшееся время увеличилось. Я восстановил виртуальную машину с дополнительными ресурсами, но, похоже, это не имеет значения. Доступен один вариант: сделайте резервную копию диска C и, если размер резервной копии составляет 18-19 ГБ, отформатируйте или сотрите раздел C и восстановите резервную копию. Я подозреваю, что за то, что файлы $ MFT находятся в таком состоянии, виноват сторонний дисковый инструмент.

Обновление 2:

Все, что я смог сделать, это показать, что занимает пространство. Я не смог его освободить. Вероятно, есть платные инструменты, которые помогут. Если вы знаете, какое программное обеспечение для разбиения на разделы было в системе до EASEUS, это тоже может помочь вам. На приведенном выше снимке экрана «64% диска» основаны на виртуальной машине емкостью 68 ГБ, а не на всем имеющемся у вас разделе 150 ГБ.

Вы пробовали бежать spacesniffer как предлагает администратор вроде HopelessN00b в комментариях к вашему вопросу? Обычно большие неизвестные проясняются, и, вероятно, вы обнаружите, что C:\Windows\WinSxS виноват. Здесь Windows хранит разные версии .DLL файлы в попытке избежать адской давности DLL. Вы можете немного очистить его, выполнив это из командной строки с правами администратора:

Dism.exe /online /Cleanup-Image /StartComponentCleanup - запускается очистка всех файлов в папке WinSxS. В зависимости от того, что вы на самом деле установили, это может сэкономить немного или довольно много места.

Проверять, выписываться этот бит от MS по теме. Также обратите внимание, что довольно часто команда завершается ошибкой с некоторым кодом. Обычно это означает, что в папке есть незавершенные операции (например, обновления Windows), которые необходимо завершить. В частности, если есть файл с именем C:\Windows\WinSxS\pending.xml, вероятно, это не сработает. Подождите, пока установятся все обновления, возможно, перезагрузите компьютер и попробуйте еще раз. Надеюсь, поможет!

Это интересная проблема. Я подозреваю, что это какой-то артефакт из физической системы, которая была виртуализирована, но не обнаруживается, потому что никакой физической причины больше нет.

Вот два примера:

плохие блоки на физическом диске, которые VMware Converter смог распознать и обойти, но теперь плохие блоки являются частью файла .vmdk, но не являются настоящий плохие блоки, потому что VMware Converter мог прибегнуть к копии на уровне файлов, поскольку копия на битовом уровне не удавалась
какие-то теневые копии, которые могли быть потеряны из-за своего приложения или были нераспознаваемыми в физической системе из-за проблем с записью VSS там

Вот что я бы попробовал:

Если у вас еще есть физическая система, запустите полный анализ и там. Кроме того, возможно, вы уже использовали и пробовали виртуализацию, чтобы увидеть, поможет ли это решить проблему.
Если вы делаете резервные копии образов внутри виртуальной машины, попробуйте полностью восстановить виртуальную машину на тестовой виртуальной машине и снова провести анализ.
Если вы еще не используете его для резервного копирования, попробуйте сделать еще одну резервную копию образа как физической, так и виртуальной системы с помощью ShadowProtect. Это стоит, но вы можете установить полнофункциональную 30-дневную пробную версию, которая просто перестанет работать после окончания пробного периода.

Вам нужно будет перезагрузить систему, прежде чем ShadowProtect позволит вам сделать резервную копию системного тома. После получения резервной копии вы также можете попробовать аппаратно-независимое восстановление для восстановления системы (вам потребуется приобрести ShadowProtect IT Edition; моя компания использует его, и оно того стоит, но вы можете искать бесплатные решения, чтобы HIR не подходят это).

Две причины попробовать ShadowProtect:

у него есть полностью отдельные писатели VSS, которые он устанавливает для работы с файловой системой. Я использовал ShadowProtect в системах, где любое другое программное обеспечение для резервного копирования, которое я могу придумать, не будет работать, потому что собственные средства записи Windows VSS повреждены.
ShadowProtect имеет чрезвычайно мощное сжатие, которое отсеивает посторонние данные. При резервном копировании виртуальных серверов я обычно вижу степень сжатия от 50% до 60%. Возможно, он также сможет отсеять эти 40 ГБ мусора.

Мне любопытно узнать, дойдете ли вы до сути, если это.

пространство занято почти наверняка точки восстановления. Попробуйте удалить точки восстановления для этого диска в разделе System Control - System - Advanced Settings - Tab computer protection - button configure - button delete, и вы увидите, что недоступное пространство исчезает.