Esse comando ddrescue está fazendo alguma coisa?

No decorrer da tentativa de 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 parecia 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 ipose opos. Demorou 9 dias para se atualizar 500000 MB, que é o tamanho da unidade de disco com falha. Quando chegou lá, porém, voltou a cair 0e começou a subir novamente. Enquanto escrevo isso, é sobre 2580 MBe contando.

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

O arquivo de log tem cerca de 3 MB e fica 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 com o fato de que isso é apenas uma perda de tempo e nenhum dado está sendo recuperado.

Existe alguma indicação nesta saída de que algo útil esteja acontecendo?

Existe alguma razão para deixar o ddrescuecomando continuar como está, ou devo pará-lo 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

Não sei se você ainda está tentando extrair dados desse disco rígido ou se já teve êxito, mas, caso não tenha tido sucesso e gostaria de tentar ver se consegue recuperar, talvez, tenha perdido Bitcoins ou qualquer outra coisa, eu fiz algumas modificações nos seus ddrescueparâmetros de linha de comando, adicionei o seguinte:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d que diz ao ddrescue para usar o acesso direto ao disco,
• --force, que diz ao ddrescue para usar e ler / gravar com força no seu arquivo de log, caso se queixe de que não pode usá-lo para fins de leitura / gravação
• -R (sim, com CAPITAL R), que informa ddrescuepara executar as operações de recuperação em sentido inverso, em vez de ler o disco rígido com falha no modo de avanço. Às vezes, a leitura inversa 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 3comando, pois não quero que [YET] ddrescuetente novamente setores defeituosos, deixarei isso por último, depois que minha primeira varredura for concluída e estou tendo um grande êxito em resgatar dados do meu disco rígido de 1 TB da Seagate falharam, onde ASSUMO podem estar guardando alguns bitcoins que eu poderia estar explorando em 2009 a 2010, provavelmente encontrei 1 a 3 blocos de 50 BTC cada, espero que esteja neste disco rígido, bem, levarei um total de mais de 15 dias para concluir a operação a uma taxa de leitura de 634 kbps em média.

Além disso, gostaria de acrescentar que você pode, e muito provavelmente, com base em seu histórico anterior de mais de 9 DIAS de "última atividade de leitura", que você encontrará uma situação em que o disco rígido se recusará a ler mais, pois situação, basta pressionar CTRL + C para cancelar, pois 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 conectá-lo ao uma placa-mãe para que não bloqueie todo o computador, forçando uma reinicialização rígida e, em seguida, conecte a alimentação SATA novamente para reiniciar o disco rígido, aguarde 10 segundos e pressione a seta para cima ou para baixo para recarregar o terminal anterior comando e reinicie oddrescueoperação, graças ao seu log anterior, ele continuará onde parou pela última vez e haverá leitura sendo feita e a "última leitura bem-sucedida" sempre permanecerá em "0s" (zero segundos) onde deveria, indicando que ddrescueestá sendo bem-sucedida em lendo a partir do disco rígido e se você notar que a "última leitura de" começa a contar segundos, basta terminar mais uma vez ddrescuecom CTRL+ C, ligar e desligar o disco rígido e reiniciarddrescue, não há nenhum ponto em esperar para ver se a "última leitura de" é reiniciada novamente em 0s, com base na minha experiência de que isso nunca acontecerá, você estará esperando pela eternidade. Eu tive que ligar e desligar meu disco rígido de 1 TB ruim cerca de 20 vezes no total, já se passaram sete dias e estou muito perto de atingir a marca de 500 GB recuperados, a meio caminho de ficar parado, espero não encontrar grandes falhas como Eu quase 100%, uma vez que está indo perfeitamente nos últimos 3 dias, novamente com mais de 634 kbps.

Além disso, não fique ganancioso ao tentar obter uma taxa de leitura mais rápida da taxa de transferência de dados, pois minha tentativa de tentar vários parâmetros e tamanhos de bloco diferentes quase me deixou com um disco rígido completamente morto que deixará de funcionar em mais de um segundo após o ciclo de energia. (isso foi há 5 dias), mas felizmente ele apenas começou a mostrar sinais de vida novamente, inicialmente lendo a 2.000 bs (sim BYTES por segundo) um pouco menos de 2kbps, fiquei muito decepcionado, mas depois de cancelarddrescuecom CTRL + C e apenas reiniciando-o novamente (no sentido inverso com -R), o parâmetro foi adicionado e a velocidade voltou para 630, antes que eu estivesse lendo a 930 kbps, pelo menos estou contente por fazer 630 kbps ao contrário e não tendo que adiar com 2kbps, por isso, se você obtiver sucesso em qualquer velocidade de leitura, como na faixa de 500 kbps, mantenha-o e não tente fazer nada para aumentar a velocidade, talvez seja sua última tentativa bem-sucedida de obter qualquer velocidade de leitura.

Como alternativa, se isso não ddrescueé bom para você, porque você não pode ler nada, independentemente de quais parâmetros você tenta, considere substituir a placa lógica do disco rígido, pois 90% das vezes é a placa lógica usada ruim, mas primeiro, retire a placa lógica e limpe todos os contatos que fazem contatos com os pinos do disco rígido, algumas vezes esses contatos ficam com uma mistura pegajosa e enegrecida, interrompendo o contato que pode ser a fonte de sua falha. Mas lembre-se de que, se você precisar substituir a placa lógica do disco rígido, precisará obter uma mesma marca, número de série (próximo a), número do modelo, número da revisão, pois deve ser o mais próximo do original para o conselho doador para trabalhar.

Você deve poder parar, ddrescuepois ele usa o arquivo de log para poder reiniciar sua operação (fechar) de onde saiu. No entanto, eu verificaria se o arquivo de log foi atualizado recentemente, observando o carimbo de data ou hora tail -f /home/dave/recovery_usb500.logfile.

O fato de seu arquivo de imagem ainda ser pequeno demais pode ter a ver com nenhum bloco recuperado com êxito da unidade ainda. No entanto, isso seria um resultado ruim depois de todo esse tempo em execução. Supondo que haja apenas alguns blocos defeituosos no dispositivo e que eles não estejam no início, seu status de primeiras entradas seria +. O IIRC ddrescuecomeça a ler até encontrar um erro e depois começa a dividir o restante do disco. Seu disco parece falhar desde o início.

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

Quanto a fazer outra coisa. Presumo que você já tentou ler alguns blocos com dd normal. Você olhou para o syslog com base nisso e pesquisou no Google todas as mensagens que encontrou lá?

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

• Tente conectar via USB 1.1 em vez de 2.0
• A unidade pode ficar quente, envolva-a em plástico e coloque-a na geladeira por 10 minutos; isso fornece algum tempo de legibilidade antes que a unidade aqueça novamente.
• switch do SMART no BIOS (e conecte-se ao SATA).
• Verifique se a unidade USB tem energia suficiente (fonte de alimentação extra)
• Se a leitura via 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 nunca tentei nenhum deles.