testdisk está mostrando o tamanho errado da unidade [duplicado]

Question

Estou tentando recuperar os dados de um disco rígido danificado usando testdisk . Fiz tudo de bom, fiz a pesquisa rápida, a pesquisa mais profunda e, depois de confirmar que meus arquivos haviam sido encontrados por testdisk , escrevi a tabela de partições. e reiniciei o computador. Então, agora eu acho que tenho um problema ainda maior. O disco rígido agora está semeando em testdisk como uma unidade de 2199 GB, e se eu conectá-lo diretamente na porta SATA, como recomendado no FAQ do testdisk, até mesmo meu BIOS não pode reconhecê-lo corretamente, e não posso executar testdisk novamente, já que não reconhece a unidade com o tamanho normal (500 GB).

Tentando montar a unidade para leitura somente para uma tentativa de recuperar dados também não está funcionando, recebo a mensagem de que "NTFS is inconsistent" .

Eu tentei ver a unidade no Gerenciador de discos do Windows, mas demorou muito tempo para aparecer e continuar aparecendo como cru, sem informações sobre seu tamanho.

a saída do testdisk no reconhecimento da unidade. Você pode ver meu disco rígido pessoal (sda) e a unidade que desejo recuperar (sdb) deve ser listada como 500GiB.

Uma coisa a notar é que o espaço em disco ocupado na lista por sda (meu disco rígido) é o espaço em disco ocupado pelo disco rígido que eu quero recuperar. Na verdade, a quantidade de espaço em disco ocupada no meu HD é de 110 GB.

Posso confirmar que a unidade não está morta porque os LEDs acendem e sinto o disco em funcionamento.

se eu usar o smartmontools ou o gsmartcontrol para ver o status do disco rígido, recebo isso como resultado:

a tela de detalhes da unidade

É muito importante para mim recuperar esses dados porque ele evolui material de faculdade e mestrado, e meu último backup é de 1 mês atrás (não posso fazer isso todos os dias devido ao espaço disponível em meu backup External USB Drive).

Espero que alguém possa ajudar, e sei que muitas pessoas também têm esse problema.

Fatos que podem ser de conhecimento útil:

• A demonstração do R-Studio foi inútil em meu teste, se eu tentar abri-lo com o drive conectado, o programa simplesmente não funciona / não responde.

• O WD Lifeguard Diagnostic também não é útil, já que não mostra a unidade na tabela.

• O disco não parece estar danificado fisicamente.

EDIT 1:

Conforme solicitado, a tela [ Geometry ] :

Devo tentar ajustar o número para mostrar a capacidade real do disco ou a opção de recuperação?

EDIT 2: A unidade é um WD Blue, modelo WD500LPVX

EDIT 3: O comando parted -l /dev/sdb output é o seguinte:

a saída do comando sudo grep -abiro "NTFS " /dev/sdb me deu, após algum tempo de execução:

grep: /dev/sdb: Input/output error

Corrigindo a impressão, parece que o sdb foi desmontado antes do comando parted, a imagem acima é a saída real.

Uma coisa a notar, o comando grep após a primeira saída, que leva cerca de 20 segundos, fornece instantaneamente a mesma saída se eu executar o comando novamente sem desconectar a unidade.

EDIT 4:

ddrescue já está funcionando há algumas horas, mas estou encontrando alguns pontos estranhos no comportamento das saídas, como segue:

Primeiro, uma amostra de algumas linhas do arquivo status.log :

# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue /dev/sdc /media/sidious/Supply/dotk/bkpHD/copy.img /media/sidious/Supply/dotk/bkpHD/status.log
# Start time:   2016-07-29 01:05:36
# Current time: 2016-07-29 01:30:51
# Copying non-tried blocks... Pass 1 (forwards)
# current_pos  current_status
0x8482360000     ?
#      pos        size  status
0x00000000  0x00010000  *
0x00010000  0x00010000  ?
0x00020000  0x00010000  *
0x00030000  0x00020000  ?
0x00050000  0x00010000  *
0x00060000  0x00040000  ?

Deveria ser assim?

Segundo, a saída do comando pode ser vista aqui:

Não tenho certeza se os valores apresentados em rescued , ipos e opos estão errados ou não, por isso peço a alguém que me diga se deveria ser assim. o drive tem uma capacidade real de 500GB, e alguns dos números mostrados são maiores que isso.

Além disso, o tamanho do arquivo copy.img é 0 bytes. Isso significa que não há dados sendo copiados ou que não há dados de sucesso para recuperar?

EDIT 5:

Após um longo processo e espera, com muita replicação da unidade para manter o processo em andamento, parece que ddrescue foi concluído, mas o arquivo .img tem 0 bytes. Eu fiz algo errado? Eu apenas segui as instruções dadas.

EDIT 6

Estou marcando essa questão como resolvida, já que o processo dado para resolver o erro funcionaria principalmente se a unidade não estivesse "morta". Obrigado a todos que deram seus pensamentos e especialmente a Andrea Lazzarotto.

    

Answer 1

  

O disco não parece psicologicamente danificado.

Felizmente, os discos rígidos não têm sentimentos. ;) No entanto, lamento informá-lo que o seu disco parece estar fisicamente danificado ou pelo menos está a falhar:

  

faz instantaneamente a mesma saída se eu executar o comando novamente sem desconectar a unidade

Isso basicamente significa "não é bom".

As coisas que você deve absolutamente fazer neste caso são:

• parando qualquer gravação na unidade (você já parou de tentar reescrever a tabela de partições com testdisk , o que é bom)
• fazendo uma cópia de bitstream (também conhecido como arquivo de imagem) da unidade com falha

Clona a unidade

Primeiro, instale a ferramenta ddrescue através do pacote gddrescue (o g é não um erro de digitação), que é usado para fazer cópias precisas de unidades com falha, clonagem como muita informação quanto possível. Basicamente vou citar esta minha resposta em uma questão relacionada:

sudo ddrescue /dev/sdb /media/user/External/copy.img /media/user/External/status.log

     

O arquivo status.log não é obrigatório, mas é necessário se você quiser pausar o processo e retomar mais tarde.

Como você pode ver, você precisará de outra unidade que seja grande o suficiente para conter uma cópia de toda a unidade de 500 GB (basicamente, um disco rígido com pelo menos 1 TB de tamanho). No meu exemplo, ele é montado em /media/user/External . Adapte o exemplo à sua situação.

A ferramenta ddrescue salva seu progresso no arquivo /media/user/External/status.log . Isso é muito útil porque a unidade pode "desaparecer" devido a erros de E / S (como aconteceu com o grepping ). O programa irá parar. Você reconectará a unidade e executará o mesmo comando novamente: continuará de onde parou.

Além disso, ddrescue lê blocos "bons" e "grandes" primeiro, depois volta para áreas mais danificadas tentando reduzir a quantidade de dados lidos em uma única operação até que todos os bits bons tenham sido isolados. / p>

Embora a unidade mostre ser uma unidade de 2 TB, ela é na verdade uma unidade de 500 GB. Portanto, o processo de copiar a unidade será interrompido em 500 GB.

Execute o TestDisk na cópia

Agora você pode usar o TestDisk como antes, mas na cópia:

sudo testdisk /media/user/External/copy.img

Quando você chegar ao ponto de ver o conteúdo da partição (com a tecla P ), não prossiga para escrever a tabela de partições. Em vez disso, use a tecla C para começar a extrair os dados que você precisa (espero que eles não estejam danificados).

Para esta operação, você precisará de espaço livre em qualquer unidade (seja aquela que você usou para armazenar a cópia de bitstream, ou uma chave USB ou qualquer outra coisa) para extrair os arquivos.

Se o TestDisk falhar

Se o TestDisk não puder acessar a unidade NTFS porque ela não está danificada, você poderá usar o RecuperaBit para reconstruir a estrutura do NTFS conforme explicado no no arquivo acima. responder .

  

Aviso: Eu sou o desenvolvedor do RecuperaBit.