O HDD USB da esposa tem um pequeno problema em que uma pasta se recusa a abrir (sistema de arquivos NTFS). Consegui criar uma imagem da unidade com Linux, mas para um setor (os setores têm 4.096 bytes). A leitura desse setor falha:
sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1 dd: erro ao ler '/dev/sdb': erro de entrada/saída 0+0 registros em 0+0 registros fora 0 bytes (0 B) copiados, 22,9317 s, 0,0 kB/s
Substituir este setor por bytes nulos leva ao mesmo sintoma do Windows, portanto o setor parece estar relacionado ao diretório problemático.
Ao acessar o referido setor, a saída dmesg diz:
[20381.842495] sd 7:0:0:0: [sdb] Código de sentido não tratado [20381.842506] sd 7:0:0:0: [sdb] [20381.842510] Resultado: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [20381.842514] sd 7:0:0:0: [sdb] [20381.842517] Chave de detecção: erro de hardware [atual] [20381.842531] sd 7:0:0:0: [sdb] [20381.842535] Adicionar. Sentido: Nenhuma informação sensorial adicional [20381.842539] sd 7:0:0:0: [sdb] CDB: [20381.842542] Leitura(10): 28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request: erro de E/S, dev sdb, setor 173177960 [20381.842572] Erro de E/S de buffer no dispositivo sdb, bloco lógico 21647245
Existe uma maneira de ler este setor, bruto, sem verificação de CRC ou qualquer outra coisa para realmente tentar recuperar alguns dos dados corrompidos?
Abri o gabinete: o HDD é USB nativo, sem conversão de USB para SATA.
Editar: Tentei o ddrescue, mas também não consegui recuperar o setor defeituoso. Ler 2Gigs em torno do setor defeituoso permite que as cabeças se estabilizem após a busca:
sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk GNU ddrescue 1.19 Pressione Ctrl-C para interromper resgatado: 2.147 MB, tamanho errado: 4.096 B, taxa atual: 0 B/s ipos: 88.667 MB, erros: 1, taxa média: 8.488 kB/s opos: 1073 MB, tempo de execução: 4,21 m, leitura bem-sucedida: 1,06 m atrás Finalizado
A leitura reversa (sinalização -R) também falhou.
Editar 2:Meu segundo passo planejado foi usar a perícia para tentar obter os arquivos perdidos. Comecei a olhar o MFT manualmente, mas isso rapidamente se tornou muito, muito tedioso. Então eu tinha as seguintes ferramentas na minha lista:
- o kit de detetive
- NTFS-3G
- bisturi
- scrounge-ntfs
O Sleuthkit não faria nada de útil, parando muito cedo reclamando de erros nas estruturas de metadados.
Com o Ntfs-3g (agora Tuxera) é possível montar a imagem com saída de depuração:
sudo mount -o loop,ro,offset=258048,debug image2 ./mnt -t ntfs-3g
Tentar entrar no diretório com defeito causaria um erro:
O buffer de índice (VCN 0x0) do inode de diretório 101874 tem um tamanho (24) diferente do tamanho especificado do diretório (4096).
Procurando esse erro no DuckduckGo me levou ao seguinte post: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 Acontece que o pessoal do Tuxera / ntfs-3g realmente incentiva o uso do CHKDSK da Microsoft para recuperar erros de NTFS
Executar o chkdsk no disco foi meu terceiro e último passo planejado, no entanto, deveria ser tentado muito antes, sabendo quePODE ser executado em uma imagem de disco, usando por exemplo OSFMount (http://www.osforensics.com/tools/mount-disk-images.html).
A maioria dos arquivos e diretórios ausentes (se não todos) foram recuperados por chkdsk /f na imagem de disco montada. Mais de cem erros (a maioria deles arquivos órfãos) foram corrigidos.
Editar 3:Estou aceitando a resposta de psusi. Embora não tenha sido provado ser impossível, tentar ler os setores defeituosos é certamente o caminho mais incerto e difícil para recuperar dados de um HDD levemente danificado.
Responder1
Não, não é possível. Existe um comando SCSI para fazer isso, mas você ainda estaria recebendo apenas lixo, e ele não é suportado em unidades de nível de consumidor, especialmente em USB. O que quer que houvesse naquele setor desapareceu.