Eu preciso resgatar dados de um disco rígido grande de 2 TB e estou fazendo isso em alguns Live-Linux em algumas VMs, onde o problemático disco rígido está conectado ao uso de USB 3 e a VM fornece um disco virtual do disco rígido. tamanho necessário localmente para receber os dados. Em seguida, executei a seguinte chamada, simplesmente para ver como estão as coisas:
ddrescue -f /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
sdc é o dispositivo quebrado em USB, sdb é o disco virtual para receber os dados, sda1 é para armazenamento temporário e formatado usando Ext4.
As coisas começaram a funcionar rapidamente, ddrescue conseguiu ler ~ 45 GB de dados em minutos e, em seguida, as coisas ficaram mais lentas, lendo apenas alguns bytes por segundo durante dias. Então o dispositivo foi obviamente quebrado nessas partes e eu tentei simplesmente pular aqueles usando várias invocações diferentes de --input-position=[...]GB após a outra. Dependendo de onde eu pulei, as coisas começaram a ler rápido novamente, até que eles ficaram lentos novamente e eu pulei novamente usando outra invocação. O importante é notar que a posição de entrada e saída impressa por ddrescue sempre esteve em sincronia! Eu também não alterei manualmente nada no arquivo de mapeamento fornecido ou o excluí ou o que quer que seja, sempre foi um e o mesmo arquivo e somente gerenciado pelo ddrescue em si.
Depois, mudei a abordagem um pouco e decidi não usar o --input-position manualmente, mas o seguinte:
ddrescue -f --min-read-rate=1MB --skip-size=1MB /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
Portanto, sempre que ddrescue reconhecesse partes lentas, ignorava blocos de dados quebrados e continuava a leitura. Novamente, a posição de entrada e saída estava em sincronia e o contador de dados lidos e resgatados aumentava o tempo todo. Até o ponto foram ddrescue terminados e dizem ter resgatado ~ 650 GB de dados.
O problema é que depois de finalmente olhar para os arquivos de disco virtual, parece que apenas ~ 160 GB de dados são realmente armazenados. Além disso, o último registro de data e hora da gravação foi alguns dias muito antigo. Portanto, por algum motivo, ddrescue achou que estava lendo muitos dados, mas não parecia escrevê-los corretamente nos locais do disco virtual, onde os liava do disco quebrado. No final, pelo que entendi, o disco virtual deveria ter pelo menos o tamanho ddrescue informado sobre a quantidade de dados que ele salvou.
Tenho a sensação de que ddrescue leu corretamente todos os dados que disse, mas simplesmente substituiu os dados já resgatados em invocações subsequentes. Então, enquanto eu acho que reconheci --input-position para ler, parece ter escrito sempre começando na posição 0 novamente no alvo.
Obviamente, não especifiquei a posição inicial para gravar dados, mas de acordo com os docs isso não deve ser necessário e ddrescue sempre imprimiu a posição de entrada e saída para ser a mesma de qualquer maneira.
-o bytes
--output-position=bytes
Starting position of the image of the rescue domain in outfile, in bytes.
Defaults to '--input-position'. The bytes below bytes aren't touched if
they exist and truncation is not requested. Else they are set to 0.
Claro que eu não pedi truncamento, de acordo com os documentos, ele não está habilitado por padrão e nem teria trabalhado para a unidade de destino que eu havia especificado:
-t
--truncate
Truncate outfile to zero size before writing to it. Only works for regular
files, not for drives or partitions.
Então, alguma ideia sobre o que pode ter dado errado? Minhas múltiplas invocações com valores diferentes para --input-position já estão erradas? Tem a ver com ler e escrever em drives em vez de partições ou arquivos?
Talvez seja um problema gravar em algum disco virtual? Embora eu não veja por que isso faça alguma diferença, preciso gravar em algum disco virtual e não posso fornecer armazenamento bruto do tamanho necessário.
Obrigado!