Respostas:
O ddrescue pode ser retomado, mas requer um arquivo de log para poder fazê-lo. O arquivo de log registrará o progresso que o ddrescue fez até agora e a reinicialização do ddrescue lerá o arquivo de log e começará de onde parou.
O arquivo de log seria o terceiro parâmetro:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log
Se você já iniciou uma execução do ddrescue sem um arquivo de log e o cancelou, na próxima vez que o ddrescue for executado, ele começará no início, pois não possui registro do que já foi recuperado.
Mesmo se você esqueceu de especificar um arquivo de log, pode haver esperança:
Então você não leu o tutorial e iniciou o ddrescue sem um arquivo de log. Agora, dois dias depois, seu computador travou e você não pode saber a quantidade de dados que o ddrescue conseguiu salvar. E pior ainda, você não pode retomar o resgate; você precisa reiniciá-lo desde o início.
Ou talvez você tenha começado a copiar uma unidade dd conv=noerror,synce agora esteja na mesma situação descrita acima. Nesse caso, observe que você não pode usar uma cópia feita por dd, a menos que tenha sido chamada com o syncargumento de conversão.
Não se desespere (ainda). Em alguns casos, o Ddrescue pode gerar um arquivo de log aproximado, a partir do arquivo de entrada e da cópia (parcial), quase tão boa quanto um arquivo de log exato. Isso é feito simplesmente assumindo que os setores que contêm todos os zeros não foram resgatados.
No entanto, se o destino da cópia era uma unidade ou uma partição (ou um arquivo normal existente e o truncamento não foram solicitados), provavelmente você precisará reiniciar o ddrescue desde o início. (Desta vez com um arquivo de log, é claro). O motivo é que os dados antigos podem estar presentes na unidade que ainda não foram sobrescritos e, portanto, podem não ser tentados, mas diferentes de zero.
Por exemplo, se você tentou um destes comandos:
ddrescue infile outfile
ou
dd if=infile of=outfile conv=noerror,sync
você pode gerar um arquivo de log aproximado com este comando:
ddrescue --generate-mode infile outfile logfile
Como já foi dito, você sempre deve especificar um arquivo de log como o terceiro parâmetro, o que permitirá a retomada. Como você não fez isso, isso não vai ajudá-lo aqui. Se você souber aproximadamente a que ponto o processo chegou, poderá usar os parâmetros --input-positione --output-positionpara iniciar a partir desse ponto (certifique-se de definir os dois parâmetros com o mesmo valor, caso contrário, a saída será corrompida).
Como você não especificou um arquivo de log como terceiro parâmetro, a retomada não pode ser feita automaticamente. Você pode criar um arquivo de log manualmente, se conhecer os setores já resgatados, a sintaxe é fácil. Basta iniciar outro resgate simulado para outro arquivo enquanto especifica um log e deixa-o ler áreas diferentes. Em seguida, edite o log para representar as áreas já resgatadas em seu primeiro arquivo. Agora, execute novamente o comando anterior, mas forneça o nome do arquivo de log como o terceiro parâmetro. O ddrescue será retomado no primeiro setor não experimentado.
Por https://wiki.archlinux.org/index.php/Disk_cloning , parece que, com a conv=noerror,syncopção, de ddfato, adiciona zeros no final de um bloco, não exatamente onde os erros de leitura ocorreram. Isso é contrário às informações da resposta de Miles Wolbe de 29/08/2013.
Por exemplo, se uma sequência correta for 198123283e houver um erro de leitura no meio, ela será gravada 198283000, não 198000283.
Portanto, no caso de realmente haver erros de leitura, o método proposto não será preciso - haverá áreas que seriam legíveis e acabarão preenchidas com zeros, mas serão consideradas "resgatadas".
A propósito, é uma boa prática iniciar essa tentativa de recuperação preenchendo a unidade de destino com zeros (ou pelo menos o espaço livre, que pode ser feito com o WinHex, por exemplo).