criei uma cópia do sistema em uma máquina virtual VMWare (v7), o tamanho é 7.11 Go compactado, 70 Go descompactado (desculpe, o sistema está em francês!) login: adminstrateur e senha: T3st https://mega.co.nz/#!l981ACQK!LnLFiUD5-MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE
Há 40 GB faltando no meu disco rígido e tentei muitas coisas para rastreá-lo sem sucesso ( chkdsk /r /f, Defrag, WinDirStat, sniffer de espaço, inicialização no Windows defender offline, remoção de rootkit GMER 2.1.1, streams, vssadmin, dism etc.). A propósito, os programas foram executados como administrador e sistema
Você pode ver os detalhes do espaço em disco aqui:
O único detalhe que consigo encontrar é do chksdsk, que diz que os 40 GB são usados pelo sistema:
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èmesignifica 46 GB usados pelo sistema)
Também não parece estar na pasta System Volume Information:
Diskpart mostra que é apenas uma partição:
Eu também tentei inicializar no linux debian live cd para verificar o arquivo do disco rígido e a integridade do NTFS:
resultado de "du -xks ./* | sort -n" (tudo está 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 diz que está tudo bem
mas o ntfsck retorna tons do seguinte erro: erro ao obter o valor do bit para o registro {valor de deslocamento}
no google há apenas 2k resultados, alguns desses resultados estão apontando para a fonte ntfsck, os outros parecem não ser revelantes ...
P: Como faço para eliminar esse espaço usado pelo sistema?
mais algumas informações:
- o sistema vem do conversor VMware, o sistema original (físico) tem o mesmo problema de espaço
- o disco foi reduzido com EASEUS Partition Master, mas o problema estava presente antes
- Quando comprimi a máquina virtual, obtive como resultado um arquivo tar.gz de tamanho 14Go, como se aqueles 40Go estivessem vazios
EDITAR:
O espaço usado foi localizado no MFT, mas nenhuma ferramenta realmente o eliminou.
Responder1
Você tentou executar spacesniffercomo administrador, como HopelessN00b sugere nos comentários à sua pergunta? Normalmente, as grandes incógnitas são esclarecidas e provavelmente você descobrirá que quem C:\Windows\WinSxSé o culpado. É aqui que o Windows mantém diferentes versões de .DLLarquivos na tentativa de evitar o inferno de DLL de antigamente. Você pode limpá-lo fazendo isso em um prompt de comando com privilégios de administrador:
Dism.exe /online /Cleanup-Image /StartComponentCleanup- isso inicia uma visualização de todos os arquivos na pasta WinSxS. Dependendo do que você realmente instalou, isso pode economizar pouco ou bastante espaço.
Confiraessa partedo MS sobre o assunto. Observe também que muitas vezes o comando falhará com algum código de erro. Isso geralmente significa que há operações pendentes na pasta (como atualizações do Windows) que precisam ser concluídas. Particularmente, se houver um arquivo chamado C:\Windows\WinSxS\pending.xml, provavelmente não funcionará. Deixe todas as atualizações serem instaladas, talvez reinicie e tente novamente. Espero que ajude!
Responder2
Baixei a VM e carreguei-a em um servidor. A primeira coisa que notei foi que a unidade C estava compactada. Se o seu servidor físico for assim, descompacte a unidade. Há pouco a ganhar fazendo isso.
Depois de descompactar, verifiquei que estou vendo o que você está vendo. Também adicionei espaço em disco para corresponder aos seus 150 GB. Instalei então o Defraggler Portable e analisei o disco. Comecei a olhar os setores para ver quais arquivos estavam lá e percebi que $MFT ocupava muito espaço. Depois de um pouco de pesquisa, descobri que o utilitário Drive Wiper do CCleaner pode corrigir isso.
Comecei a limpar o espaço livre (1 passagem). O software mostra “Wipe MFT Free Space”, mas a tarefa será executada por cerca de 24 horas. Vou deixar correr e reportar de volta.
Há muitas informações envolvendo $ MFT e CCleaner se você pesquisar. Você pode encontrar um momento 'eureka' que o levará à raiz de como isso aconteceu em primeiro lugar. Só posso especular neste momento.
Atualização 1: O processo estava demorando mais do que o esperado e tentei aumentar o desempenho da VM, mas a barra de progresso parou e o tempo restante aumentou. Reconstruí a VM com mais recursos, mas não parece fazer diferença. Uma opção disponível: faça um backup da unidade C e, se o backup estiver na faixa de 18 a 19 GB, formate ou limpe a partição C e restaure o backup. Suspeito que uma ferramenta de disco de terceiros seja responsável pelos arquivos $MFT estarem nesta condição.
Atualização 2:
Tudo o que consegui fazer foi mostrar o que está consumindo o espaço. Não consegui liberá-lo. Provavelmente existem ferramentas pagas para ajudar. Se você sabe qual software de particionamento estava no sistema antes do EASEUS, isso também pode ajudar na sua causa. Na captura de tela acima, "64% da unidade" é baseado na VM de 68 GB, não na partição completa de 150 GB que você possui.
Responder3
Este é um problema interessante. Minha suspeita aqui é que se trata de algum artefato do sistema físico que foi virtualizado, mas é indetectável porque qualquer causa física não está mais presente.
Dois exemplos poderiam ser:
- blocos defeituosos na unidade física que o VMware Converter foi capaz de reconhecer e contornar, mas agora os blocos defeituosos fazem parte do arquivo .vmdk, mas não sãorealblocos defeituosos porque o VMware Converter pode ter recorrido a uma cópia em nível de arquivo, pois uma cópia em nível de bit estava falhando
- algum tipo de cópia de sombra que pode ter ficado órfã por seu aplicativo ou irreconhecível no sistema físico devido a problemas de gravador VSS.
Aqui está o que eu tentaria:
Se você ainda possui o sistema físico, execute sua análise completa lá também. Exceto que talvez você já tenha tentado a virtualização para ver se isso corrigiria o problema.
Se você estiver fazendo backups de imagem na VM, tente restaurar totalmente a VM em uma VM de teste e fazer sua análise novamente.
Se você ainda não o estiver usando para backups, tente fazer outro backup de imagem dos sistemas físicos e de VM usando o ShadowProtect. Custa, mas você pode instalar uma avaliação totalmente funcional de 30 dias que ficará inativa após o término do período de avaliação.
Você precisará reiniciar o sistema antes que o ShadowProtect permita fazer backup do volume do sistema. Depois de obter um backup, você também pode tentar a Restauração Independente de Hardware para restaurar o sistema (você precisaria comprar o ShadowProtect IT Edition; minha empresa usa e vale a pena, mas você pode estar procurando soluções gratuitas para que o HIR não cabe nisso).
- http://www.shadowprotect.com/shadowprotect-backup-software-downloads
- http://www.storagecraft.com/support/book/storagecraft-recovery-environment-user-guide/restoring-system-volume
Duas razões para experimentar o ShadowProtect:
- ele possui gravadores VSS completamente separados que são instalados para acessar o sistema de arquivos. Usei o ShadowProtect em sistemas onde todos os outros softwares de backup que consigo imaginar não funcionarão porque os gravadores VSS nativos do Windows estão corrompidos
- ShadowProtect possui compactação extremamente poderosa que elimina dados estranhos. Normalmente vejo uma taxa de compactação entre 50% e 60% ao fazer backup de servidores virtuais. Talvez seja possível eliminar esses 40 GB de lixo também.
Estou curioso para saber se você chega ao fundo disso.
Responder4
o espaço está ocupado com certeza são os pontos de recuperação. Tente excluir os pontos de recuperação desta unidade em controle do sistema - sistema - configurações avançadas - guia proteção do computador - botão configurar - botão excluir e você verá o espaço inacessível desaparecer.