Desfazer mudanças causadas no sistema de arquivos NTFS pelo utilitário ntfsfix e recuperar arquivos perdidos

Tenho um HD externo de 1TB com o sistema de arquivos NTFS. Uso ele geralmente pra salvar arquivos de mídia etc. Moro em uma região que as vezes acontece quedas de energia repentinas. Quando isso acontece, após iniciar o Linux novamente não é possível montar a partição NTFS do HD. Para corrigir esse problema, sempre reiniciei no Windows, que de cara já consegue montar a partição mas envia a notificação de que há um problema e que é necessário corrigir etc mas nunca fui de usar a interface gráfica pra corrigir o problema, sempre rodei o comando chkdsk D: /f /x no terminal, reinicio no Linux e a partição está pronta pra ser montada e dados serem gravados novamente. Nota que nunca sequer percebi o sumiço ou corrompimento de algum arquivo após rodar o chkdsk no Windows. Ontem, mais uma vez aconteceu uma queda de energia e a partição ficou imontável no Linux. Com preguiça de reiniciar no Windows mais uma vez (que só uso pra streaming uma vez por semana ou rodar o chkdsk), decidi pesquisar se já existia alguma alternativa ao chkdsk para o Linux. Então me deparei com o ntfsfix. O uso é simples, sudo ntfsfix [partição]. A seguinte saída foi fornecida:

Resumo
Mounting volume... $MFTMirr does not match $MFT (record 3).
FAILED
Attempting to correct errors... 
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 3...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdb1 was processed successfully.

E então a partição pôde ser montada novamente. Fiquei feliz por achar que não precisaria mais reiniciar no Windows toda vez, mas a felicidade foi embora quando abri o Dolphin e percebi que todo o conteúdo de uma pasta havia sumido. Não são arquivos pessoais importantes, mas são uma centena de GB que gostaria de recuperar. Reiniciei no Windows e nem é possível entrar dentro da pasta:
Captura de tela 2023-10-08 221035

Rodei o chkdsk D: /f /x pra ver se magicamente os arquivos seriam recuperados e esse é o log:

Resumo
PS C:\Users\kamyk> chkdsk D: /f
O tipo do sistema de arquivos é NTFS.
O rótulo do volume é toshiba.

Estágio 1: examinando a estrutura básica do sistema de arquivos...
  228096 de registros de arquivos processados.
Verificação de arquivos concluída.
 Duração da fase (Verificação de registro de arquivo): 11.96 segundos.
  851 registros de arquivos grandes processados.
 Duração da fase (Recuperação de registro de arquivo órfão): 1.08 milissegundos.
  0 registros de arquivos inválidos processados.
 Duração da fase (Verificação de registro de arquivo incorreto): 0.33 milissegundos.

Estágio 2: examinando a ligação do nome do arquivo...
  116 registros de novas análises processados.
Corrigindo erro no índice $I30 para arquivo 19CBA.
CHKDSK descobriu espaço disponível marcado como alocado no bitmap do índice $I30 do arquivo 19CBA.
Falha ao corrigir erros no índice $I30 do arquivo 19CBA.
Corrigindo erro no índice $I30 para arquivo 1A47F.
CHKDSK descobriu espaço disponível marcado como alocado no bitmap do índice $I30 do arquivo 1A47F.
Classificando índice $I30 no arquivo 1A47F.
  232936 de entradas de índice processadas.
Verificação de índices concluída.
 Duração da fase (Verificação de índice): 11.35 segundos.
CHKDSK está verificando arquivos não indexados para reconectá-los ao diretório original.
Recuperando arquivo órfão 2023-09-29_19-16-07_elegas027_42836514683-parte.mkv (5C) no arquivo da pasta 1A47F.
Recuperando arquivo órfão 2023-09-20_01-55-37_elegas027_42786994571-parte.mkv (63) no arquivo da pasta 1A47F.
Recuperando arquivo órfão 2023-09-29_23-49-21_.mkv (70) no arquivo da pasta 19CBA.
Recuperando arquivo órfão 2023-09-20_23-31-29_elegas027_49329705757-parte.mkv (171) no arquivo da pasta 1A47F.
Falha ao recuperar os dados perdidos.
Recuperando arquivo órfão 2023-09-20_23-31-29_elegas027_49329705757-parte.mkv (171) no arquivo da pasta 1A47F.
Falha ao recuperar os dados perdidos.
Recuperando arquivo órfão 2023-09-21_02-01-05_elegas027_49330609725-.mkv (1BA) no arquivo da pasta 1A47F.
Falha ao recuperar os dados perdidos.
Recuperando arquivo órfão 2023-09-21_02-01-05_elegas027_49330609725-.mkv (1BA) no arquivo da pasta 1A47F.
Falha ao recuperar os dados perdidos.
Recuperando arquivo órfão aqui (19CD1) no arquivo da pasta 19CBA.
Recuperando arquivo órfão 4dcc5992d0487d0517fd_40531982728_1677857115-12-45-27.log (1A037) no arquivo da pasta 19CBA.
Recuperando arquivo órfão 4dcc5992d0487d0517fd_40531982728_1677857115.mkv (1A038) no arquivo da pasta 19CBA.
Ignorando outras mensagens sobre recuperação de órfãos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
  37 arquivos não indexados verificados.
Falha ao recuperar os dados perdidos.
Falha ao recuperar os dados perdidos.
  37 arquivos não indexados recuperados no diretório original.
 Duração da fase (Reconexão órfã): 847.99 milissegundos.
  0 arquivos não indexados recuperados em achados e perdidos.
 Duração da fase (Recuperação de órfãos para achados e perdidos): 6.20 milissegundos.
  116 registros de novas análises processados.
 Duração da fase (Verificação de ponto de nova análise e ID de Objeto): 3.58 milissegundos.

Estágio 3: examinando os descritores de segurança...
Verificação de descritores de segurança concluída.
 Duração da fase (Verificação do descritor de segurança): 62.20 milissegundos.
  2421 arquivos de dados processados.
 Duração da fase (Verificação de atributo de dados): 0.40 milissegundos.
O CHKDSK está verificando o diário de USN...
Verificação do diário de USN concluída.

O Windows encontrou problemas no sistema de arquivos que não puderam ser corrigidos.

 976728060 KB de espaço total em disco.
 948693840 KB em 28496 arquivos.
      9756 KB em 2422 índices.
         0 KB em setores defeituosos.
    325172 KB em uso pelo sistema.
     65536 KB ocupados pelo arquivo de log.
  27699292 KB disponíveis em disco.

      4096 bytes em cada unidade de alocação.
Total de  244182015 unidades de alocação no disco.
   6924823 unidades de alocação disponíveis em disco.
Duração total: 24.23 segundos (24238 ms).

Como diz o log só 3 arquivos foram recuperados com sucesso.

Pra comparação, esse é um log com a saída de costume de quando rodava o chkdsk no mesmo cenário antes de conhecer o ntfsfix:

Resumo
PS C:\Users\kamyk> chkdsk /f D:
O tipo do sistema de arquivos é NTFS.
O rótulo do volume é toshiba.

Estágio 1: examinando a estrutura básica do sistema de arquivos...
  228096 de registros de arquivos processados.
Verificação de arquivos concluída.
 Duração da fase (Verificação de registro de arquivo): 12.19 segundos.
  790 registros de arquivos grandes processados.
 Duração da fase (Recuperação de registro de arquivo órfão): 1.36 milissegundos.
  0 registros de arquivos inválidos processados.
 Duração da fase (Verificação de registro de arquivo incorreto): 0.31 milissegundos.

Estágio 2: examinando a ligação do nome do arquivo...
  116 registros de novas análises processados.
  232914 de entradas de índice processadas.
Verificação de índices concluída.
 Duração da fase (Verificação de índice): 11.72 segundos.
  0 arquivos não indexados verificados.
 Duração da fase (Reconexão órfã): 38.54 milissegundos.
  0 arquivos não indexados recuperados em achados e perdidos.
 Duração da fase (Recuperação de órfãos para achados e perdidos): 5.45 milissegundos.
  116 registros de novas análises processados.
 Duração da fase (Verificação de ponto de nova análise e ID de Objeto): 3.53 milissegundos.

Estágio 3: examinando os descritores de segurança...
Verificação de descritores de segurança concluída.
 Duração da fase (Verificação do descritor de segurança): 58.51 milissegundos.
  2410 arquivos de dados processados.
 Duração da fase (Verificação de atributo de dados): 0.37 milissegundos.
O CHKDSK está verificando o diário de USN...
  5888 de bytes USN processados.
Verificação do diário de USN concluída.
 Duração da fase (Verificação do diário de USN): 43.07 milissegundos.

Não há problemas no sistema de arquivos.
Nenhuma ação necessária.

 976728060 KB de espaço total em disco.
 843213660 KB em 28421 arquivos.
      9736 KB em 2411 índices.
         0 KB em setores defeituosos.
    325648 KB em uso pelo sistema.
     65536 KB ocupados pelo arquivo de log.
 133179016 KB disponíveis em disco.

      4096 bytes em cada unidade de alocação.
Total de  244182015 unidades de alocação no disco.
  33294754 unidades de alocação disponíveis em disco.
Duração total: 24.07 segundos (24078 ms).

Apesar dos arquivos terem sumido, não ganhei o espaço de armazenamento no sistema de arquivos de volta. Gostaria de ajuda de alguém que talvez já tenha passado pelo mesmo ou tenha mais conhecimento sobre. É possível reverter o “registro” do sistema de arquivos para antes de ter rodado o ntfsfix? O NTFS mantem algum backup?

Qualquer ajuda é bem vinda, muito obrigado.

2 curtidas

Bom dia, acredito que a real causa para a perca desses dados foi as sucessivas quedas de energia, procure providenciar um No-Break pois logo vc perderá um disco e não somente arquivos. Lembre-se, NTFS EXT4 BTRFS etc são sistemas de arquivos mais robustos e menos suscetíveis a perca de dados, mas vc não pode abusar da sorte.

Sugiro vc parar de tentar corrigir o disco com e utilizar algum programa de recuperação de dados do windows ou Linux. No linux recomendo o Testdisk, mas ele não tem GUI é terminal mesmo.

@aguamole Acho que vc não soube interpretar o que eu escrevi, eu não comparei nenhum deles, apenas dei exemplos de sistemas de arquivos que são menos suscetíveis a corromper por que lda de energia. Não são como o antigo fat32 que facilmente é corrompido.

Bom, no tópico aqui abordado, o NTFS não tem demérito nenhum, afinal, nenhum sistema de arquivos foi idealizado pra estar o tempo todo sob quedas de energia. Quanto a cobrar das empresas bons produtos, concordo, mas me pergunto, qual a porcentagem de usuários/clientes de produtos MS estão realmente no direito de tal cobrança? Muita gente usa, mas não paga, e se não paga, não pode fazer cobranças…

1 curtida

O NTFS tem menor resistência a danos por queda de energia porque ele não é COW, no COW quando um arquivo vai ser modificado é feito a gravação dos locais onde o arquivo vai ser modificado em um lugar reservado onde o arquivo original não recebera as alterações de imediato, quando a gravação dessas modificações em um lugar reservado termina de ser gravado só então que acontece a modificação no arquivo que devera ser modificado e então só ao terminar a modificação é que o lugar da copia reservada é liberado, se der algum problema em algum desses passos o BTRFS consegue recuperar o arquivo e a ele mesmo devido ao backup da copia e gravação.
Mas eu não sei qual é o tamanho desta parte reservada do COW devido a que se for muito grande a gravação fica muito lenta e se for muito pequena ela da uma segurança muito baixa.
Outra vantagem do COW é que ele consegue se auto reparar não necessitando de intervenção do usuário.

Então o NTFS tem desmérito sim em segurança.

Então ta certo, diga para o @KaMyKaSii que a culpa da perca dos dados dele é pq o NTFS é ruim, e não foi pq na casa dele tem constantes quedas de energia e ele não fez nada a respeito, apenas ficava corrigindo o sistema de arquivos sucessivas vezes( veja como é ruim o NTFS) esperando que por um milagre, nunca os dados seriam corrompidos.

1 curtida

Não é tão simples assim como você esta pensando. Eu no lugar da Microsoft também não mudaria.

Você não sai simplesmente matando um “produto” consolidado e colocando outro que não sabe se será bem aceito, quais problemas possa vir, a troco de NADA em ganhos comerciais.

Lembre-se, a maioria que compra uma Ferrari, não esta preocupado quais peças são usadas na construção do seu motor, estão preocupadas na experiencia. É o que a Microsoft foca em mudar, apenas o que é visto pelos usuários, o seu core ela é mais conservadora.

1 curtida

Ou talvez a Microsoft já sabe que não tem relevância em servidores onde os mantenedores do mesmos costumam a ter capacidade técnica para avaliar um produto o que é diferente do pessoal do desktop. E ai ela taca a goela a baixo dos Windows users de desktop.

A Apple já correu atrás do filesystem dela ela usa o “Apple File System – Wikipédia, a enciclopédia livre” em seus desktop, ele tmb tem COW.

Teve o ReFS após o NTFS, porém não foi para frente.

Não deu certo pq será, talvez o projeto dele não era bom o suficiente para disputar com o ZFS.
Mas isso é especulação minha.
O que eu sei é que o ZFS viro o universo de filesystem de cabeça para baixo.

Eu realmente não entendo muito destes sistemas (apenas mencionei que ela até tentou lançar um após o NTFS), mas por lógica, a Microsoft só lançaria um tipo de sistema novo se ele fosse muito superior aos seus concorrentes, e como você diz que este ZFS é muito superior. Talvez eles já tenham desenvolvido algo melhor, e estão lapidando ele ou esperando para ser lançado em um momento estratégico.

Que eu me lembre, a Microsoft mudou de sistema apenas quando foi obrigada a mudar por limitação do seu sistema atual, como foi o Fat32 para o NTFS.

Não foi neste sentido.

Antes de questionar o porque a empresa estar usando ainda determinada tecnologia, tem que ver qual o histórico da empresa.

Não tem como aplicar esta lógica entre a Apple e a Microsoft, visto que a Apple é historicamente uma empresa que sempre teve como uma de suas marcas a inovação, portanto ela sempre vai estar mudando para fazer jus a sua reputação.

A Microsoft já é um pouco diferente, ela é um misto, em que uma parte dos seus softwares se mantém tradicionalmente (prompt do DOS, notepad, wordpad, paint (até um tempo atrás)), ou seja ela costuma fazer mudanças no design e implementando novas funcionalidades, porém mantendo algumas coisas sem alterar, e isso tem um propósito ao meu ver, que é fazer com que a transição de um sistema para o outro não seja muito brusca.

Este problema do NTFS que você relatou, em que esta obsoleto e outros sistemas possuem versões melhores, ela esta muito ciente sobre isso, porém ela não achou necessário ainda trazer esta mudança. E talvez isso possa ser explicado com o exemplo que vem acontecendo nos últimos iPhone da Apple.

Quando você libera muitas mudanças de uma só vez, nos próximos lançamentos talvez não tenha tanta coisa para se inovar.

E convenhamos que uma mudança no sistema de arquivos é algo de destaque para o pessoal da tecnologia, gera muita curiosidade para saber se altera a performance, segurança e afins. É o famoso, tenha cartas na manga, e use quando necessário.

No Linux não existe esta demanda por inovação como na Microsoft e Apple, sem contar que o Linux ao meu ver é modular (as inovações vem de diferentes fontes que não estão relacionadas com uma mesma empresa), diferente dos sistemas proprietários.

O pessoal aqui é muito apaixonado ao defender suas opiniões com fatos.

Voltando ao problema, depois que o bit é escrito no disco, não é possível voltar atrás (teoricamente há uma remota possibilidade, mas isso não vem ao caso pra quem não é do setor de inteligência governamental e análise forense).

Fica o aprendizado de, se for utilizar sistemas de arquivos no linux, use os sistemas nativos. Se há necessidade de usar a partição em dois sistemas operacionais, aí já seria o caso de usar um sistema mais simples (fat32 ou exfat, ambos com suporte da MS nos módulos do kernel linux), mas perdendo as características avançadas de proteção de arquivos dos sistemas mais novos.

O único uso seguro para usar partições diferentes entre linux e windows, seria usar máquina virtuais e realizar a tarefa de edição de arquivos usando uma interface de rede entre os sistemas, o que é bem pouco prático, além de tomar um bom tempo para configuração e baixa performance.

Eu somente indicaria usar ntfs no linux se for somente leitura. Atualmente o módulo ntfs-3g está relativamente bom para uso simples, mas as especificações do NTFS ainda são fechadas e todo esse avanço está baseado em engenharia reversa. O problema é que no uso básico (sem problemas) vc se sentiu confortável para usar recursos mais avançados e entrou na área instável.

Nunca usei o ntfsfix, acho que deveria mostrar um aviso bem claro que o programa é incompleto, para não deixar o usuário confortável de usá-lo sem plena consciência. Se houve esse aviso, então o risco foi assumido pelo administrador da máquina, caso contrário, falha do ntfsfix…

1 curtida

@Deleterium então, mas o NTFS do Linux é diferente do NTFS da Microsoft, você pode observar isso no sobre do mkfs.ntfs.
Quando você gera um NTFS com o mkfs esse NTFS não é o mesmo do que o Windows cria.

Copyright (c) 2000-2007 Anton Altaparmakov
Copyright (c) 2001-2005 Richard Russon
Copyright (c) 2002-2006 Szabolcs Szakacsits
Copyright (c) 2005      Erik Sornes
Copyright (c) 2007      Yura Pakhuchiy
Copyright (c) 2010-2018 Jean-Pierre Andre

This program is free software, released under the GNU General Public License
and you are welcome to redistribute it under certain conditions.  It comes with
ABSOLUTELY NO WARRANTY; for details read the GNU General Public License to be
found in the file "COPYING" distributed with this program, or online at:
http://www.gnu.org/copyleft/gpl.html

É diferente, você pode perceber que quem fez o mkfs do NTFS no Linux não é a Microsoft e você pode observar que é GPL, e o código fonte do NTFS da Microsoft não é GPL então são diferentes.

O grande ponto do tópico é que estão pondo a culpa no ntfsfix e no NTFS, sendo que a causa da perda dos dados foi a insistencia em usar o PC em uma rede onde ouve sucessivas quedas de energia, onde como “solução” a cada queda e dano no sistema de arquivo, era utilizado programas de correção/verificação… Talvez se fosse a primeira ocorrencia do fato, o ntfsfix tivesse feito seu trabalho, quem garante que depois de tantos desligamentos, os danos não foram irreversíveis? As pessoas acham que existe FS e/ou HD imune a queda de energia…

1 curtida

Entendo o ponto, realmente usar sistema de proteção contra quedas de energia seria o ideal. Porém entrar na questão de no-breaks vai demandar um alto investimento para um produto de qualidade. Um nobreak senoidal puro custa o mesmo que um PC de entrada (preço surreal na minha percepção)… Daí a pessoa compra o no-break baratinho, além da zoeira que o bicho faz ainda tem a chance da fontes mais novas, com PFC ativo, não aguentarem o chaveamento arcaico e continuarem desligando (aliás esse é o meu exemplo, que comprei um no-break baratinho e joguei dinheiro no lixo). Um tópico completo: No-break Ragtech Easy Way é boa opção para proteger computadores?

Empresas sérias precisam sim investir alto na proteção de seus dados, mas não acho correto imputar essa responsabilidade a um usuário doméstico, especialmente dentro da nossa realidade no-breaks bons absurdamente caros ou no-breaks ruins a preços módicos.