Réponses:
ddrescue peut être repris, mais il nécessite un fichier journal pour pouvoir le faire. Le fichier journal enregistrera la progression de ddrescue jusqu'à présent, et le redémarrage de ddrescue lira le fichier journal et commencera là où il s'était arrêté.
Le fichier journal serait le troisième paramètre:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log
Si vous avez déjà commencé une exécution ddrescue sans fichier journal et que vous l'annulez, la prochaine fois que ddrescue s'exécute, il démarre au début car il n'a aucun enregistrement de ce qui a déjà été récupéré.
Remarque : ddrescue et dd_rescue sont des programmes différents.
Même si vous avez oublié de spécifier un fichier journal, il peut y avoir de l'espoir:
Vous n'avez donc pas lu le didacticiel et lancé ddrescue sans fichier journal. Maintenant, deux jours plus tard, votre ordinateur est tombé en panne et vous ne pouvez pas savoir combien de données ddrescue a réussi à enregistrer. Et pire encore, vous ne pouvez pas reprendre le sauvetage; vous devez le redémarrer dès le début.
Ou peut-être que vous avez commencé à copier un lecteur avec dd conv=noerror,syncet que vous êtes maintenant dans la même situation que celle décrite ci-dessus. Dans ce cas, notez que vous ne pouvez pas utiliser une copie faite par dd à moins qu'elle n'ait été invoquée avec l' syncargument de conversion.
Ne désespérez pas (encore). Ddrescue peut dans certains cas générer un fichier journal approximatif, à partir du fichier d'entrée et de la copie (partielle), qui est presque aussi bon qu'un fichier journal exact. Il le fait en supposant simplement que les secteurs contenant tous les zéros n'ont pas été sauvés.
Cependant, si la destination de la copie était un lecteur ou une partition (ou si un fichier normal et une troncature existants n'ont pas été demandés), vous devrez probablement redémarrer ddrescue dès le début. (Cette fois avec un fichier journal, bien sûr). La raison en est que les anciennes données peuvent être présentes dans le lecteur qui n'ont pas encore été écrasées et peuvent donc être non essayées mais non nulles.
Par exemple, si vous avez d'abord essayé l'une de ces commandes:
ddrescue infile outfile
ou
dd if=infile of=outfile conv=noerror,sync
vous pouvez générer un fichier journal approximatif avec cette commande:
ddrescue --generate-mode infile outfile logfile
Comme d'autres l'ont dit, vous devez toujours spécifier un fichier journal comme troisième paramètre, ce qui permettra de reprendre. Puisque vous ne l'avez pas fait, cela ne vous aidera pas ici. Si vous savez approximativement à quel point le processus est arrivé, vous pouvez utiliser les paramètres --input-positionet --output-positionpour commencer à partir de ce point (assurez-vous de définir ces deux paramètres à la même valeur, sinon la sortie sera corrompue).
Étant donné que vous n'avez pas spécifié de fichier journal comme troisième paramètre, la reprise ne peut pas se faire automatiquement. Vous pouvez créer un fichier journal à la main si vous connaissez les secteurs déjà sauvés, la syntaxe est simple. Commencez simplement un autre sauvetage factice vers un autre fichier tout en spécifiant un journal et laissez-le lire différentes zones. Modifiez ensuite le journal pour représenter les zones déjà sauvées dans votre premier fichier. Réexécutez maintenant votre commande précédente mais donnez le nom du fichier journal comme troisième paramètre. ddrescue reprendra alors sur le premier secteur non testé.
Par https://wiki.archlinux.org/index.php/Disk_cloning, il semble qu'avec le conv=noerror,synccommutateur, ddajoute en fait des zéros à la fin d'un bloc, pas exactement où les erreurs de lecture se sont produites. Ceci est contraire aux informations contenues dans la réponse de Miles Wolbe du 29/08/2013.
Par exemple, si une séquence correcte est 198123283et qu'il y a une erreur de lecture au milieu, elle écrira 198283000, non 198000283.
Donc, dans le cas où il y aurait effectivement des erreurs de lecture, la méthode proposée ne sera pas précise - il y aura des zones qui auraient été lisibles qui finiront par être remplies de zéros, mais seront considérées comme "sauvées".
Soit dit en passant, c'est une bonne pratique de commencer une telle tentative de récupération en remplissant le lecteur de destination avec des zéros (ou au moins l'espace libre, ce qui peut être fait avec WinHex par exemple).