Imagens NTFS recuperadas pelo ddrescue - devo executar o fsck nelas?

1

Eu tenho um disco rígido que começou a falhar recentemente, lançando erros e não conseguindo montar nenhuma de suas partições. Eu usei a incrível ferramenta ddrescue , rodando no Debian, para recuperar as três principais partições dele. Todas as três são partições NTFS e, nos três casos, ddrescue conseguiu recuperar a grande maioria dos dados. Mas nas três partições, também indicou que alguns dados foram perdidos para erros:

  • Partição 1: Tamanho: 57 GB, errsize (de ddrescue): 8 KB
  • Partição 2: Tamanho: 110 GB, errsize : 40 KB
  • Partição 3: Tamanho: 95 GB, errsize : 14,6 MB

Todas as três imagens são montadas normalmente e parecem acessíveis.

Minha pergunta é: não sei onde estão esses erros em cada imagem e não sei quais arquivos estão danificados. Faz sentido executar fsck nessas imagens para corrigir inconsistências? Ou isso pode estragar as coisas ainda mais?

    
por ShankarG 04.11.2016 / 17:32

1 resposta

2

Minha resposta para outra pergunta pode ser útil aqui. Estou colando o fragmento mais importante abaixo.

Linux is not well equipped to fix corrupted NTFS. There is ntfsfix tool, however its manual says:

ntfsfix is a utility that fixes some common NTFS problems. ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.

     

Como você pode ver, a ferramenta deixa o trabalho difícil para o Windows fazer. Parece que não há como reparar problemas graves de NTFS apenas no Linux.

     

A ferramenta certa é o Windows chkdsk com a opção /f .

Para usar chkdsk com a imagem bruta, use o ImDisk. Eu não tenho nenhuma experiência com o ImDisk, mas é recomendado aqui .

Acho que chkdsk pode corrigir inconsistências (se houver) no próprio sistema de arquivos, mas não recuperará o conteúdo dos arquivos que foi perdido (se for o caso), porque o NTFS não tem redundância para isso.

    
por 19.11.2016 / 10:29