unidade NTFS danificada após remoção não segura do Windows 7

Question

Primeiro, algumas informações sobre a unidade - é um disco rígido portátil USB 2.0 (PQI H560), uma partição que abrange todos os 640 GB, NTFS. Usado quase exclusivamente no Linux (arch e ubuntu), mas inicialmente formatado no Windows 7.

O disco rígido tem muitos links físicos, já que era um sistema de backup como o timemachine.

E agora o problema em si:

Hoje eu cometi o erro de tirar meu disco rígido portátil do meu sistema Linux e conectá-lo em uma caixa do Windows 7. Tudo funcionou bem, tirei um filme do drive e fiquei adormecido por mais ou menos uma hora. Depois disso, tirei a unidade (esqueci de desmontar: /) e coloquei de volta no meu Linux.

Infelizmente, ocorreu o seguinte erro:

[49162.611858] mount.ntfs[15397]: segfault at 7fff19cb1fe8 ip 00007f9fca88de4e sp 00007fff19cb1fa0 error 6 in libntfs-3g.so.79.0.0[7f9fca87f000+42000]

Ok, o suporte a Linux NTFS não é muito bom, então voltei ao Windows para fazer um scandisk ou algo assim. Sim, certo:

You need to format the disk in drive F: before you can use it.

Do you want to format it?

Não, não sei.

Clique com o botão direito em > Ferramentas - > Verifique agora (isso é chkdsk, certo?):

The disk check could not be performed because Windows can't access the disk.

De volta ao familiar Linux, fdisk -l encontra o sistema de arquivos NTFS, mas estou com um pouco de medo de fazer um fsck ou ntfsfix .

Como eu disse, o suporte a Linux NTFS está bem, faltando. Talvez tente fazer um dd da partição para outro drive e experimente lá, mas atualmente eu não tenho o hardware para isso.

Alguma idéia de por que foi tão ruim? Achei que o NTFS era durável.

Dicas sobre utilitários de recuperação de dados seriam ótimas. Melhor se houvesse algo não destrutivo (conseguir obter os dados enquanto preserva cada bit da unidade em seu estado atual - só para ter certeza de que não quebre nada)

    

Answer 1

A resposta para este problema foi restaurador final, além de alguns arquivos grandes (2GB +), logs e problemas com alguns hardlinks (tratados como duplicatas) isso corrigiu isso.

Além disso, quanto mais eu olhava do log, mais parecia que a MFT não era o problema, não a raiz da MFT, pelo menos. Algumas coisas que foram duplicadas e não binariamente iguais parecem que a unidade falhou na cópia de sombra, e talvez houvesse alguns loops ou outras estruturas realmente ruins na parte mais profunda da MFT. Olhando através de logs, parece que todas as implementações falharam fatalmente, ou seja, segfaulting. Um log interessante do MacOS X:

Interval Since Last Panic Report:  472 sec
Panics Since Last Report:          2
Anonymous UUID:                    D89B5624-FF95-48B5-8F55-0987EA2D2466

Sun Jun 26 18:02:46 2011
panic(cpu 0 caller 0x6e085e4a): "ntfs_map_runlist_nolock(): Called for $MFT/$DATA!\n"@/SourceCache/ntfs/ntfs-65.5/kext/ntfs_attr.c:245
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
 ...
  Kernel Extensions in backtrace (with dependencies):
     com.apple.filesystems.ntfs(3.4)@0x6e05a000->0x6e0b9fff

BSD process name corresponding to current thread: mount_ntfs

E então morreu.

Então, parece que eu tive um problema muito pouco frequente causado por preguiça. Para referência futura: a melhor correção é fazer o que você deve, ou seja, desmontar a unidade. Talvez também desabilitar a cópia de sombra em uma unidade externa.

Enfim, restaurador consertou, e sobre o fracasso parece janelas de alguma forma contibuído deixando uma partição em um estado que um sistema de diário não deve estar dentro Talvez montando-o no linux também contribuiu, através eu não acho provável , o ntfs3g não conserta coisas sem perguntar, geralmente não é capaz de fazer isso ou chora a atenção do usuário no syslog para isso.

    

Answer 2

A remoção insegura da unidade foi sua queda.

Você terá que executar a recuperação de dados para obter os arquivos, formatar a unidade e mover tudo de volta ou arriscar com uma das ferramentas do Linux.

Além disso, não há nada errado com o Windows 7. Você executou uma remoção insegura, portanto, não é culpa do Windows.

    

Answer 3

Bem ... Antes que as ferramentas sejam executadas, eu recomendo fazer uma imagem ... e se você não tiver o hardware para uma imagem dd em linha reta, tente inseri-la no lzma e comprimi-la o mais que puder você pode:

dd if=/dev/sdb bs=512k |lzma -7 -c - >ntfs.img.lzma

Você pode substituir sdb por qualquer coisa ... sry, se isso soa condescendente, não foi intencional. A julgar pelo seu post, você conhece a essência do dd. Se você é impaciente como eu, deve canalizá-lo para o pv e obter uma barra de progresso:

dd if=/dev/sdb bs=512k |pv |lzma -7 -c - >ntfs.img.lzma

Eu só coloco o nível de compressão de lzma em 7 porque 9 pode levar uma eternidade em um processador mais lento. Uma vez que isso esteja fora do caminho, eu recomendo testdisk e seu aplicativo irmão photorec. O Testdisk é capaz de reparar o sistema de arquivos até certo ponto ... Eu não o usei muito, no entanto, eu conheço algumas pessoas que o elogiam. O Photorec é um último esforço para recuperar todos os arquivos individuais, ele procura por dados lógicos de tipo de arquivo conhecidos, começando e terminando. No entanto, mesmo que seja demorado, você deve tentar primeiro o ntfsfix. Se isso destruir completamente qualquer coisa, basta puxar da sua imagem:

unlzma -c ntfs.img.lzma |pv |dd of=/dev/sdb bs=512k

E apenas alguns pensamentos rápidos sobre o que deu errado, eu digo, não culpe os dois sistemas operacionais, ambos fizeram o mesmo papel em danificá-lo. Ele estava sujo do sistema operacional do Windows, e ao tentar montar o ntfs-3g, ele ficou ainda mais danificado a ponto de o Windows não gostar mais dele. Isso parecerá um pouco estranho, mas procure em uma configuração do kernel, e o suporte à gravação do NTFS ainda é rotulado como experimental e À sua própria conta. Por mais que eu odeie o Windows, não posso culpá-lo desta vez. Algo estranho com o ntfs: umount sujo do windows é reparável a partir do windows, o unclean umount do linux é reparável do linux. Atravessar a linha com uma partição ntfs suja geralmente irá matá-la ... sry, apenas uma dessas coisas.