Este comando do ddrescue está fazendo alguma coisa?

9

Durante a tentativa de recuperar recuperar dados de um disco rígido com falha , estou executando o comando ddrescue .

O comando está em execução há 9 dias e, pelo som da atividade do disco, pensei que talvez estivesse fazendo alguma coisa. A saída da linha de comando pareceu mais ou menos estática todo esse tempo:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

A única parte que está mudando é onde diz ipos e opos . Demorou 9 dias para chegar a cerca de 500000 MB , que é o tamanho da unidade de disco com falha. Quando chegou lá, porém, caiu para 0 e começou a subir novamente. Enquanto eu escrevo isto, está a cerca de 2580 MB e contando.

O arquivo de imagem que está sendo criado tem 0 bytes de comprimento.

O arquivo de log tem cerca de 3 MB e é assim:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Estou começando a ficar preocupado que isso seja apenas uma perda de tempo e que nenhum dado esteja sendo recuperado.

Existe alguma indicação desta saída de que algo útil está acontecendo?

Existe alguma razão para deixar o comando ddrescue continuar como está, ou devo parar e fazer outra coisa?

Este é o conteúdo mais recente de /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
    
por Questioner 13.06.2013 / 05:41

2 respostas

7

Eu não sei se você ainda está tentando extrair dados do disco rígido ou se você já teve sucesso, mas no caso de você não ter sucesso e gostar de tentar ver se consegue se recuperar, talvez, tenha perdido Bitcoins ou qualquer outra coisa, eu fiz algumas modificações em seus parâmetros de linha de comando ddrescue , eu adicionei o seguinte:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • -d que informa ao ddrescue para usar o acesso direto ao disco,
  • - force que instrui o ddrescue a usar com força e ler / gravar em seu arquivo de registro no caso de reclamar que não pode usá-lo para fins de leitura / gravação
  • -R (sim, com CAPITAL R) que informa ddrescue para executar as operações de recuperação ao contrário, em vez de ler o disco rígido com falha no modo de encaminhamento. Às vezes, ler em sentido inverso ajuda quando o dano é substancial, pois isso ignora o cache do disco rígido, caso haja algum problema.

Atualmente, estou usando esses comandos (exceto que não estou usando o comando 3 , pois não quero que [YET] ddrescue tente novamente setores defeituosos, deixarei isso por último, depois que minha primeira varredura estiver concluída e estou tendo um grande sucesso salvando dados do meu disco rígido com falha da 1TB da Seagate, onde eu ASSUME poderia estar segurando alguns bitcoins que eu estive minerando em 2009 a 2010, provavelmente encontrei de 1 a 3 blocos de 50 BTC cada, eu Espero que seja neste disco rígido, bem, vai demorar-me um total de mais de 15 dias para concluir a operação a uma taxa de leitura de média de 634 kbps.

Além disso, gostaria de acrescentar que você pode e provavelmente, com base em seu histórico anterior de mais de 9 DIAS de "última atividade de leitura", encontrar uma situação em que o disco rígido se recusará a ler mais , nessa situação, basta pressionar CTRL + C para cancelar desde que você está usando um arquivo de log, remova o cabo SATA do disco rígido com falha, mas não o controlador USB da porta USB (sim, use um controlador USB SATA em vez de conectando-o a uma placa-mãe para que ele não bloqueie todo o seu computador, forçando uma reinicialização, e conecte novamente a energia SATA para reiniciar o disco rígido, dê 10 segundos e pressione a seta para cima ou para baixo para recarregar seu comando de terminal anterior e reinicie a operação ddrescue , graças ao seu registro anterior, ele deve continuar de onde parou e haverá leitura sendo feita e a "última leitura bem-sucedida" deve permanecer sempre em "0s" (zero segundos) onde deveria, indicando que ddrescue está sendo bem sucedido em re acessando a partir do disco rígido, e se você perceber que a "última leitura de" começa a contar os segundos, basta finalizar novamente ddrescue com CTRL + C , ciclo de energia No disco rígido, e reinicie o ddrescue , não faz sentido esperar para ver se a "última leitura de" reinicia a 0 por conta própria, com base na minha experiência, isso nunca vai acontecer, você estará esperando pela eternidade. Eu tive que ligar e desligar o meu disco rígido de 1 TB cerca de 20 vezes no total, tem sido como 7 dias e estou muito perto de atingir a marca de 500GB recuperada, a meio caminho para ir ainda, espero não encontrar grandes falhas como Eu estou perto de 100%, como tem sido impecável nos últimos 3 dias, novamente em mais de 634 kbps.

Além disso, não seja ávido em tentar obter uma taxa de leitura de dados mais rápida, já que minha tentativa de testar vários parâmetros e tamanhos de blocos quase me deixou com um disco rígido completamente inoperante que parará de funcionar em mais de um segundo após power cycle it (isso foi 5 dias atrás) mas felizmente ele apenas começou mais uma vez mostrando sinal de vida, inicialmente lendo a 2.000 bs (sim BYTES por segundo) um pouco menos de 2kbps, fiquei muito desapontado, mas depois de cancelar ddrescue com CTRL + C e apenas reiniciá-lo novamente (em sentido inverso com o parâmetro -R) adicionado, então a velocidade voltou para 630, antes de eu estar lendo para frente a 930 kbps, pelo menos estou contente que estou fazendo 630 kbps em reverso e não ter que adiar com 2kbps, então se você obtiver sucesso em qualquer velocidade de leitura, como na faixa de 500 kbps e não tentar nada para aumentar a velocidade, pode ser sua última tentativa bem-sucedida de ganhar qualquer velocidade de leitura.

Alternativamente, se ddrescue não for bom para você porque você não consegue ler nada independentemente dos parâmetros que você tentar, você pode querer considerar substituir a placa lógica do disco rígido, como 90% do tempo é a placa lógica que vai mal, mas primeiro, tire a placa lógica e limpe todos os contatos que fazem contato com os pinos do disco rígido, algumas vezes esses contatos ficam com uma mistura pegajosa, cortando o contato que poderia ser a fonte de sua falha. Mas esteja ciente de que se você tiver que substituir a placa lógica do seu disco rígido, você terá que obter uma das mesmas marcas, número de série (próximo a), número do modelo, número de revisão, pois tem que ser o mais próximo do original. o conselho de doadores para trabalhar.

    
por 17.10.2014 / 01:35
5

Você deve ser capaz de parar ddrescue quando usar o arquivo de log para poder reiniciar sua operação (fechar) para o local de onde saiu. No entanto, eu verificaria se o arquivo de log foi atualizado recentemente, observando o timestamp ou fazendo tail -f /home/dave/recovery_usb500.logfile .

O fato de seu arquivo de imagem ainda ser pequeno talvez tenha sido feito sem que blocos tenham sido recuperados da unidade ainda. Isso, no entanto, seria um resultado ruim depois de todo esse tempo. Supondo que haja apenas alguns blocos ruins no dispositivo e que eles não estejam no início, o status de suas primeiras entradas seria + . IIRC ddrescue começa a ler até encontrar um erro e depois começa a dividir o resto do disco. Seu disco parece falhar desde o começo.

A menos que haja (várias) + entradas no log e , o tamanho do arquivo ainda será 0 , não acho que ddrescue esteja errado. Nenhum + s significa que nada do seu disco foi recuperável. Isso pode significar eletrônicos fritos ou uma cabeça ruim, como no caso de apenas alguns setores estarem com defeito, você teria resultados muito mais rápidos.

Quanto a fazer outra coisa. Eu suponho que você já tentou ler alguns blocos com dd normal. Você viu o syslog baseado nele e pesquisou no Google todas as mensagens que encontrou lá?

Procurando por "Resultado: hostbyte = driverbyte inválido = DRIVER_SENSE" resulta em algumas leituras interessantes (parcialmente em alemão) com mais algumas sugestões:

  • Tente conectar via USB 1.1 em vez de 2.0
  • A unidade pode ficar quente, portanto, envolva-a em plástico e coloque-a na geladeira por 10 minutos, isso dá algum tempo de leitura antes de a unidade aquecer novamente.
  • alternar entre o SMART no BIOS (e conectar-se ao SATA).
  • Verifique se a unidade USB tem energia suficiente (fonte de alimentação extra)
  • Se a leitura por USB falhar após algum tempo, use um Hub USB controlado remotamente, onde você alterna programaticamente a energia do HUB USB para a unidade por alguns segundos.

Além de resfriar um disco ilegível (com spray de resfriamento), eu não tentei nada disso.

    
por 13.06.2013 / 07:07