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

Em algum lugar da Internet , li que o gddrescue é superior ao dd, pelo menos em termos de ser capaz de distinguir entre a quantidade de leituras de disco executadas em um setor problemático. É este realmente o caso?

time dd if = / dev / sda skip = 900343967 of = a.bin count = 4 iflag = conv direto = noerror, sincronização

dd: lendo `/ dev / sda ': erro de entrada / saída
2 + 0 registros em
2 + 0 registros
1024 bytes (1,0 kB) copiados, 18,6057 s, 0,1 kB / s
3 + 1 registros em
4 + 0 registros
2048 bytes (2,0 kB) copiados, 18,6707 s, 0,1 kB / s

0m18.672s real
usuário 0m0.000s
sys 0m0.004s

Btw, a bandeira direta realmente ajuda, sem ela eu só conseguia ler 1 setor em 4 (vs 3/4 com ela). No entanto, isso diminui notavelmente a velocidade de transferência - é pelo menos cerca de 5 vezes mais lenta para mim: 5MB / s vs 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

Sobre a cópia de 2048 bytes de / dev / sda para b.bin
Posições iniciais : infile = 460976 MB, outfile = 0 B
Tamanho do bloco de cópias: 1 blocos
rígidos Tamanho do bloco rígido: 512 bytes Número
máximo de solicitações: 0
Direto: sim Esparso: não Divisão: não Truncar: não

Pressione Ctrl-C para interromper o
resgate: 1536 B, tamanho do erro: 512 B, taxa atual: 53 B / s
ipos: 460976 MB, erros: 1, taxa média: 53 B / s
oposto: 1536 B, tempo da última leitura bem-sucedida: 0 s
Finalizados

usuário 0m18.736s real 0m0.004s
sys 0m0.000s

Como mostrado acima, levou exatamente a mesma quantidade de 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 perdendo essa funcionalidade? Em vez disso, apenas ignora o setor problemático sem escrever nada em sua posição e continua com o próximo setor a seguir (se eu já tiver dados gravados sobre esse setor no arquivo de saída - ele não será sobrescrito: às vezes isso pode não ser desejável ) Não sei como funciona a opção -t (truncar) para um dispositivo de bloco com gddrescue(eu acho, ele o substituirá completamente com 0x00), mas em um arquivo normal, como previsto, truncará o arquivo inteiro sem fazê-lo apenas dentro das dimensões de deslocamento (ou seja, -o1). Portanto, isso é um pouco semelhante ao dd sync , mas longe de ser o mesmo, pois simulará a funcionalidade do identificador SE você estiver pronto para substituir o dispositivo / arquivo de saída inteiro.

Embora, graças à presença da opção detalhada e à capacidade de registrar setores / blocos ruins, o gddrescue pareça uma escolha melhor. É importante observar que os dois 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 NÃO compreendo:

O dd é lento, mesmo no material livre de erros, pois está fazendo pequenas leituras e gravações. Ele gasta muito tempo mastigando as partes erradas da unidade, em vez de ler o máximo possível de coisas sem erros, e depois voltar a fazer as coisas mais difíceis.

O que é isso tudo? Especialmente a parte " gasta muito tempo mastigando as partes erradas da unidade, em vez de ler o máximo possível de coisas sem erros, e depois voltar a fazer as coisas difíceis "? Demorou a mesma quantidade de tempo mostrada acima (embora eu tenha inspecionado uma porção muito pequena de dados, mas isso importa?).

O gddrescue oferece a opção -r , que deve controlar a quantidade de releituras em um "setor defeituoso"; no entanto, o dd parece estar rodando com o -r0 o tempo todo (pois levou o mesmo tempo). Então, essa opção é apenas para "pós-processamento"? O que estou entendendo é que, originalmente, o dd e o gddrescue parecem estar rodando com -r0 e o dd não parece mastigar as partes errôneas mais do que o gddrescue (ambos parecem parar em um bloco ruim por 15 a 18) segundos mais ou menos, então qual é o problema, como o gddrescue é mais rápido ???)

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

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

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

Por outro lado, em relação a esta afirmação ...

O gddrescue é superior ao dd, pelo menos em termos de capacidade de distinguir entre a quantidade de leituras de disco executadas em um setor problemático.

O verdadeiro "pelo menos" motivo para usar o gddrescue é porque o gddrescue não trunca a saída em repetidas tentativas de leitura / gravação. O gddrescue também é totalmente automático, em relação a certos erros de leitura que interromperiam o dd.

Portanto, o autor citado pode estar correto, ele pode não ... mas toda a afirmação perde o objetivo de gddrescue.

ATUALIZAÇÃO: Diferenças detalhadas entre dd e gddrescue.

dd conv = noerror, continuará após um erro, mas apenas ignorará o bloco inválido. até 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ê simplesmente substituirá / perderá o que recuperou anteriormente.

O gddrescue também continuará após o erro. Ele pode recuperar um rendimento parcial de um bloco defeituoso e voltará e tentará o setor de blocos por setor. O gddrescue manterá um registro de erros detalhado, com bons blocos, blocos ruins e o setor por setor de todos os blocos ruins. Se você tentar executar a leitura novamente, o gddrescue será cortado (truncado) e acrescentado todos os dados recuperados.

Lembre-se, mesmo com as duas ferramentas, se um bloco inteiro for 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.

Dependendo de quando o seu disco rígido foi fabricado, bem como o fabricante, e qual versão do firmware é executada, com os modernos discos rígidos, quando são detectados setores defeituosos, eles são removidos do uso pelo firmware e a unidade sabe ignorar os setores defeituosos. Portanto, a noção de "resgatar" um disco rígido de setores defeituosos pode ser discutida a esse respeito. A questão de saber se os setores agora ruins tiveram dados válidos parece ser a solução que você está procurando - sem trocadilhos!

Existe algum software no grc.com chamado spinrite 6 que afirma ser capaz de corrigir discos rígidos com setores defeituosos. É um software pago, e eu nunca tentei. Vale a pena ler sobre isso, especialmente se alguém está tentando "ressuscitar" um disco rígido e ele realmente funciona como descrito. As perguntas freqüentes no grc.com sobre o spinrite 6 indicam que há uma garantia de devolução do dinheiro em 30 dias (e não há versão de teste ou gratuita). Nota: Eu não sou afiliado ao grc.com, nem o recomendo para sua situação. Eu apenas sei que ele existe e pode funcionar como anunciado, apenas não aceite minha palavra - advertência emptor.

Com relação a avaliar se o gddrescue "é superior" ao dd, pelo menos em termos de capacidade de distinguir entre a quantidade de leituras de disco executadas em um setor problemático, qualquer número de leituras em um setor inválido (uma vez que é marcado como não- setor funcional em uma lista de setores defeituosos mantidos em uma lista de firmware) não me pareceria útil no uso qualitativo de gddrescue ou dd.

Pode ser útil ler a página da web, dd (Unix) em: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd

Você também pode considerar útil: Como criar uma imagem de um disco rígido com falha usando o UBCD, dd-rescue e P2 eXplorer em: http://www.myfixlog.com/fix.php?fid= 21