Resgatando um disco rígido com setores defeituosos: dd vs gddrescue

Question

Em algum lugar nas internets eu li que gddrescue é superior a dd pelo menos em termos de ser capaz de distinguir entre a quantidade de leituras de disco realizadas em um setor problemático. Este é realmente o caso?

time dd if=/dev/sda skip=900343967 of=a.bin count=4 iflag=direct conv=noerror,sync

dd: reading '/dev/sda': Input/output error
2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 18.6057 s, 0.1 kB/s
3+1 records in
4+0 records out
2048 bytes (2.0 kB) copied, 18.6707 s, 0.1 kB/s

real 0m18.672s
user 0m0.000s
sys 0m0.004s

Btw, a sinalização direta ajuda muito, mas eu só consegui ler um setor de um total de 4 (contra 3/4 com ele). No entanto, isso atrasa notavelmente a velocidade de transferência - é pelo menos cerca de 5 vezes mais lento para mim: 5MB / s contra 25MB / s sem esse sinalizador. De qualquer forma, agora para a parte gddrescue (ddrescue) ..

time ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b /dev/sda b.bin

About to copy 2048 Bytes from /dev/sda to b.bin
Starting positions: infile = 460976 MB, outfile = 0 B
Copy block size: 1 hard blocks
Hard block size: 512 bytes
Max_retries: 0
Direct: yes Sparse: no Split: no Truncate: no

Press Ctrl-C to interrupt
rescued: 1536 B, errsize: 512 B, current rate: 53 B/s
ipos: 460976 MB, errors: 1, average rate: 53 B/s
opos: 1536 B, time from last successful read: 0 s
Finished

real 0m18.736s
user 0m0.004s
sys 0m0.000s

Como mostrado acima, ele tomou exatamente o mesmo tempo para execução. Como esperado - mesmas estatísticas: 3/4. No entanto, enquanto eu poderia preencher os setores problemáticos com 0x00 para dd (conv = sync), gddrescue parece estar faltando essa funcionalidade? Em vez disso, ele simplesmente salta o setor problemático sem escrever nada para sua posição e continua com o próximo setor seguinte (se eu já tiver dados escritos sobre esse setor no arquivo de saída - ele não será sobrescrito: às vezes isso pode não ser desejável ). Eu não tenho certeza de como a opção -t (truncate) funciona para um dispositivo de bloco com gddrescue (eu suponho, ele irá sobrescrever completamente com 0x00), mas em um arquivo normal, conforme previsto, trunca o arquivo inteiro sem fazê-lo somente dentro das dimensões de deslocamento (isto é, -o1). Então, isso é um pouco similar ao dd sync , mas longe de ser o mesmo, pois apenas imitará a funcionalidade do identificador SE você estiver pronto para sobrescrever todo o dispositivo / arquivo de saída.

Embora, graças à presença da opção verbose e à capacidade de registrar setores / blocos defeituosos, o gddrescue parece ser uma escolha melhor. É importante notar que ambos os aplicativos foram lançados com (praticamente) parâmetros idênticos.

A saída de

diff ?.bin

está vazio (saída 0), o que significa que os arquivos são exatamente iguais.

Agora, esta é a parte que eu NÃO entendo:

dd is slow even on the error-free stuff since it's doing tiny reads and writes. It spends a lot of time chewing through the erroneous parts of the drive, rather than reading as much error-free stuff as it can, THEN going back to do the hard stuff.

O que é isso tudo? Especialmente a parte " gasta muito tempo mastigando as partes erradas da unidade, ao invés de ler o máximo de coisas livres de erros, ENTÃO voltando para fazer as coisas difíceis "? Levou a mesma quantidade de tempo como mostrado acima (embora eu tenha inspecionado uma porção muito pequena de dados, mas isso deveria ser importante?).

O

gddrescue oferece a opção -r , que deve controlar a quantidade de releituras em um "setor inválido", no entanto, dd parece estar rodando com o -r0 o tempo todo (já que levou o mesmo tempo). Então, essa opção é apenas para "pós-processamento"? O que eu estou começando, é que originalmente dd e gddrescue parecem estar rodando com -r0 e dd não parece estar mastigando as partes erradas mais do que gddrescue (ambas parecem parar em um bloco ruim por 15-18 segundos dar ou receber, então qual é o problema, como é gddrescue mais rápido ???)

Além disso, qual é a opção -D (use gravações síncronas para arquivo de saída)? Eu não notei nenhuma diferença de alguns dos testes realizados.

Alguém pode comentar sobre a coisa toda? Obrigado.

    

Answer 1

Não tenho certeza de como o autor citado chegou à sua conclusão. Eu não estou debatendo se ele está correto, ou não, eu simplesmente não tenho essa experiência.

Por outro lado, no que diz respeito a esta declaração ...

gddrescue is superior to dd at least in terms of being able to distinguish between the amount of disk reads performed on a troubled sector.

A verdadeira razão "pelo menos" para usar o gddrescue é que o gddrescue não trunca a saída em tentativas repetidas de leitura / gravação. gddrescue também é totalmente automático, no que diz respeito a certos erros de leitura que parariam dd.

Assim, o autor citado pode estar correto, ele pode não ... mas a afirmação inteira erra o ponto de gddrescue.

UPDATE: diferenças detalhadas entre dd e gddrescue.

dd conv = noerror, irá continuar depois de um erro, mas irá simplesmente ignorar o bloco defeituoso. até mesmo adicionar a opção de sincronização colocará zeros em vez de pular. Se você usar o dd para fazer outra leitura usando a mesma saída, você irá sobrescrever / perder qualquer coisa que tenha recuperado anteriormente.

O gddrescue também continuará após o erro. Pode recuperar um rendimento parcial de um bloco defeituoso, e voltará e tentará o bloco setorialmente. O gddrescue manterá um log de erros detalhado, com bom bloco, blocos defeituosos, e setor por setor de quaisquer blocos defeituosos. Se você tentar executar a leitura novamente, o gddrescue cortará (truncará) e adicionará quaisquer dados adicionais recuperados.

Tenha em mente, mesmo com as duas ferramentas, se um bloco inteiro é 100% ilegível. Você ainda não obterá dados dele. O gddrescue pode potencialmente obter mais dados, se alguns setores do bloco permanecerem legíveis.

    

Answer 2

Dependendo de quando o disco rígido foi fabricado, bem como do fabricante, e qual versão do firmware ele executa, com os hdds modernos, quando setores defeituosos são detectados, eles são removidos do uso pelo firmware e a unidade sabe ignorar os setores defeituosos . Assim, a noção de "resgatar" um disco rígido de setores defeituosos pode ser discutível nesse sentido. A questão de saber se os setores agora defeituosos já tiveram dados válidos parece ser a solução que você está procurando - sem trocadilhos!

Existe algum software em grc.com chamado spinrite 6, que afirma ser capaz de corrigir hdds com setores defeituosos. É um software pago e nunca tentei. Vale a pena ler, especialmente se alguém está tentando "ressuscitar" um disco rígido e ele realmente funciona como descrito. O FAQ em grc.com sobre o spinrite 6 indica que há uma garantia de devolução do dinheiro em 30 dias (e não há versão experimental ou gratuita). Nota: Eu não sou afiliado com grc.com, nem estou recomendando para sua situação. Eu só sei que existe e pode funcionar como anunciado, apenas não tome minha palavra para ele - caveat emptor.

Com relação a avaliar se o gddrescue "é superior" a dd pelo menos em termos de ser capaz de distinguir entre a quantidade de leituras de disco realizadas em um setor problemático, qualquer número de leituras em um setor defeituoso (já que está marcado como um setor não funcional em uma lista de setores defeituosos mantidos em uma lista de firmware) não parece ser útil em um uso qualitativo do gddrescue ou do dd.

Você pode achar útil ler a página da Web, dd (Unix) em: link

Você também pode achar útil dar uma olhada em: Como criar uma imagem de um disco rígido danificado usando o UBCD, o dd-rescue e o P2 eXplorer em: link