Tenho que recuperar meu HD USB de 1TB. Estou usando ddrescuepara fazer isso. Existe uma maneira de retomar ddrescuedepois de iniciá-lo?
Estou usando o comando:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image
Responder1
ddrescuepode ser retomado, mas requer um arquivo de log para poder fazer isso. O arquivo de log registrará o progresso que o ddrescue fez até agora, e reiniciar o 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 cancelou-o, na próxima vez que o ddrescue for executado, ele começará do início, pois não há registro do que já foi recuperado.
Responder2
Mesmo que você tenha esquecido 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 sabe quantos dados o ddrescue conseguiu salvar. E pior ainda, você não pode retomar o resgate; você tem que 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. Neste caso, observe que você não pode usar uma cópia feita por dd a menos que tenha sido invocada 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), que é quase tão bom quanto um arquivo de log exato. Isso é feito simplesmente assumindo que os setores contendo todos zeros não foram resgatados.
No entanto, se o destino da cópia for uma unidade ou partição (ou um arquivo regular existente e o truncamento não tiver sido solicitado), provavelmente você precisará reiniciar o ddrescue desde o início. (Desta vez com um arquivo de log, é claro). A razão é que podem estar presentes na unidade dados antigos que ainda não foram substituídos e, portanto, podem não ser testados, mas diferentes de zero.
Por exemplo, se você tentou pela primeira vez 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
Responder3
Como já foi dito, você deve sempre especificar um arquivo de log como terceiro parâmetro, o que permitirá a retomada. Já que você não fez isso, isso não vai te ajudar aqui. Se você souber aproximadamente em que ponto o processo chegou, poderá usar os parâmetros --input-positione --output-positionpara iniciar a partir desse ponto (certifique-se de definir ambos os parâmetros com o mesmo valor, caso contrário, a saída será corrompida).
Responder4
Porhttps://wiki.archlinux.org/index.php/Disk_cloningparece que com a conv=noerror,syncmudança, ddde fato adiciona zerosno finalde um bloco, não exatamente onde ocorreram os erros de leitura. Isso é contrário às informações da resposta de Miles Wolbe de 29/08/2013.
Por exemplo, se houver uma sequência correta 198123283e houver um erro de leitura no meio, ela escreverá 198283000, não 198000283.
Portanto, caso realmente haja erros de leitura, o método proposto não será preciso - haverá áreas que seriam legíveis e que acabarão preenchidas com zeros, mas serão consideradas "resgatadas".
A propósito, é uma boa prática começar essa tentativa de recuperação preenchendo a unidade de destino com zeros (ou pelo menos o espaço livre, o que pode ser feito com WinHex, por exemplo).