Não, não é possível. Existe um comando SCSI para fazer isso, mas você ainda estaria recebendo apenas lixo, e não é suportado em unidades de nível de consumidor, especialmente USB. O que quer que estivesse nesse setor se foi.
O USB HDD da Wife tem um pequeno problema onde uma pasta se recusa a abrir (sistema de arquivos NTFS). Eu tenho sido capaz de imagem da unidade com o Linux, mas para um setor (setores são 4096 bytes). A leitura desse setor falha:
sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1 dd: error reading ‘/dev/sdb’: Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 22.9317 s, 0.0 kB/s
Substituir este setor por bytes nulos leva ao mesmo sintoma que no Windows, portanto, o setor parece estar relacionado ao diretório problemático.
Ao acessar o dito setor, a saída dmesg diz:
[20381.842495] sd 7:0:0:0: [sdb] Unhandled sense code [20381.842506] sd 7:0:0:0: [sdb] [20381.842510] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [20381.842514] sd 7:0:0:0: [sdb] [20381.842517] Sense Key : Hardware Error [current] [20381.842531] sd 7:0:0:0: [sdb] [20381.842535] Add. Sense: No additional sense information [20381.842539] sd 7:0:0:0: [sdb] CDB: [20381.842542] Read(10): 28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request: I/O error, dev sdb, sector 173177960 [20381.842572] Buffer I/O error on device sdb, logical block 21647245
Existe uma maneira de ler este setor, bruto, sem verificação de CRC ou o que quer que realmente tente recuperar alguns dos dados corrompidos?
Eu abri o recinto: o HDD é USB nativo, sem conversão USB para SATA.
Editar: Tentei ddrescue, mas não foi capaz de recuperar o setor ruim também. Lendo 2Gigs ao redor do setor ruim, deixe as cabeças se estabilizarem após a busca:
sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk GNU ddrescue 1.19 Press Ctrl-C to interrupt rescued: 2147 MB, errsize: 4096 B, current rate: 0 B/s ipos: 88667 MB, errors: 1, average rate: 8488 kB/s opos: 1073 MB, run time: 4.21 m, successful read: 1.06 m ago Finished
A leitura regressiva (-R flag) falhou também.
Editar 2: Meu segundo passo planejado foi usar a análise forense para tentar obter os arquivos ausentes. Eu comecei a olhar para a MFT à mão, mas isso rapidamente fica muito, muito tedioso. Então, eu tinha as seguintes ferramentas na minha lista:
O Sleuthkit não faria nada de útil, deixando de reclamar muito cedo sobre 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 inserir o diretório com falha acionaria um erro:
Index buffer (VCN 0x0) of directory inode 101874 has a size (24) differing from the directory specified size (4096).
A procura desse erro em DuckduckGo levou-me ao seguinte post: link Acontece que as pessoas no Tuxera / ntfs-3g realmente encorajam o uso do CHKDSK da Microsoft para recuperar erros NTFS
Executar chkdsk no disco foi meu terceiro e último passo planejado, no entanto, ele deve ser tentado muito antes, sabendo que PODE ser executado em uma imagem de disco , usando, por exemplo, OSFMount ( link ).
A maioria dos arquivos e diretórios ausentes (se não todos) foram recuperados pelo chkdsk / f na imagem de disco montada. Mais de cem erros (a maioria dos quais sendo arquivos órfãos) foram corrigidos.
Editar 3: Estou aceitando a resposta de psusi. Embora não seja provado ser impossível, tentar ler os setores defeituosos é certamente a rota mais incerta e difícil para recuperar dados de um HDD levemente danificado.