Lendo os blocos danificados do disco rígido muito lento no Linux

Question

Estou tentando recuperar dados de um disco rígido antigo de 320G (cheio de setores defeituosos) para um novo. Descobri que o ddrescue é uma boa ferramenta para essa tarefa, porque é inteligente algoritmo . Eu já fiz isso uma vez com o seguinte comando:

ddrescue -f -n /dev/sda /dev/sdb log

Foi completado em várias horas com 16G errs (não recuperado) que ainda pode conter dados importantes, então eu corri na próxima passagem:

ddrescue -f -d /dev/sda /dev/sdb log

mas é muito lento (avg 300B / s) porque o linux fica preso em cada setor ruim.
Na verdade, é o kernel do linux (provavelmente libata), não um disco rígido em si, porque eu tentei recuperar na ferramenta DMDE rodando no DOS limpo e não havia problema: o tempo limite do ATA pode ser ajustado lá e a recuperação geral processo é executado MUITO mais rápido.
Mas não no Linux.
Eu também tentei esses parâmetros de kernel: libata.ignore_hpa=1 libata.noacpi libata.force=noncq,norst e também libata.dma=0 passando para cmdline no bootlader, mas não teve nenhum efeito (estou usando o CD do System Rescue onde o LIBATA compilado no kernel). Também tentou alterar o tempo limite do dispositivo:

echo 1 > /sys/block/sda/device/timeout

(o padrão é 30)
mas só gera mais inundação de erros no syslog e não ajuda.
Passar por blocos ruins ainda leva de 1 a 3 minutos para cada setor, o que é incrivelmente lento. Quanto tempo precisa para analisar 16GBs de pedaços "ruins"? Uma semana? Mês?
Eu ainda prefiro ddrescue para recuperação (devido à sua funcionalidade eficiente de algoritmo e arquivo de log) e quero saber como ajustar o driver do kernel para acelerar o tratamento de erros de ata / disco. O Google e as perguntas relacionadas aqui na SU não ajudaram. Alguma idéia?

P.S. desculpe pelo meu inglês

@ ta.speot.is

Why don't you just restore from your regular backups?

Este disco rígido do meu amigo, não meu. Tão triste, ele não tem backups. Agora, após a falha do disco, ele começa a pensar em fazer backups, sim:)

UPD : 2,5 anos depois eu ainda não sei a resposta, mas acabei percebendo que ddrescue trabalha mais rápido quando o controlador sata está no modo Compatibilidade (IDE), outra dica é sempre usar -d option (acesso direto) para acelerar um pouco as coisas. Também dê uma olhada nas opções hdparm para ajustar o HDD ( -m , -D , -P ), isso pode ajudar (no hardware antigo).

UPD2 : Apenas notei a resposta do Slizzered para a questão relacionada. É ótimo! Eu tentei:

smartctl -l scterc,20,20 /dev/sda

e a recuperação foi muito mais rápida do que antes (apenas no modo IDE).

    

Answer 1

Do homem do DDRescue:

(the user may interrupt the process at any point, but be aware that a bad drive can block ddrescue for a long time until the kernel gives up)

Portanto, a resposta curta é: com DDRescue você não pode, porque você não pode alterar o tempo limite do Kernel (você precisa editar a fonte correta no lugar certo e recompilar ... não é simples!).

Eu tive bons resultados usando algum software contido na inicialização do Hiren:

• DataResque DD (criar uma imagem)
• Copiadora Imparável de Roadkil (copia os arquivos e registra os erros)

Ambos correm no MiniXP também contido na inicialização do Hiren. Ele é executado a partir da unidade de CD / DVD ou USB.

Conselho: os discos rígidos podem ficar muito quentes, isso é ruim e pior o processo. Refresque-se com um ventilador, isso prolonga a vida deles e pode acelerar o trabalho.

    

Answer 2

Pode ser útil configurar o parâmetro --skip-size= para algo maior. O padrão é algo minúsculo como 64 kB, enquanto as listras de dano em uma unidade moderna podem ser muito maiores.

Embora você ainda tenha que esperar pelo tempo limite de cada vez, haverá menos deles para esperar.

    

Answer 3

Isso ocorre alguns anos depois que a pergunta foi postada, mas ajudará outra pessoa. Eu vi a maior parte desta resposta em outro lugar e não tenho certeza se a opção -c estava disponível em ddrescue mais antiga. -c altera a quantidade de setores para copiar de cada vez.

aqui vai:

ddrescue -d -r0 -e +0 -T 1s -n /dev/sdX recover.img recover.log -c 1 -O

substitua X pela unidade que você está tentando recuperar. Os dados serão armazenados em um arquivo chamado recover.img , então você precisará de espaço suficiente.

Use o programa "watch" na frente do código acima para executar o código automaticamente quando ele falhar devido a um erro de "muitas áreas ruins".