Sauver un disque dur avec des secteurs défectueux: dd vs gddrescue

Quelque part sur les internets, j'ai lu que gddrescue est supérieur à dd au moins en termes de pouvoir distinguer la quantité de lectures de disque effectuées sur un secteur en difficulté. Est-ce vraiment le cas?

time dd if = / dev / sda skip = 900343967 of = a.bin count = 4 iflag = direct conv = noerror, sync

dd: lecture `/ dev / sda ': erreur d'entrée / sortie
2 + 0 enregistrements en
2 + 0 enregistrements en sortie
1024 octets (1.0 kB) copiés, 18.6057 s, 0.1 kB / s
3 + 1 enregistrements en
4 + 0 enregistrements en
2048 octets (2,0 ko) copiés, 18,6707 s, 0,1 ko / s

réel 0m18.672s
utilisateur 0m0.000s
sys 0m0.004s

Btw, l' indicateur direct aide vraiment, sans cela je n'ai pu lire qu'un secteur sur 4 (vs 3/4 avec). Cependant, cela ralentit sensiblement la vitesse de transfert - c'est au moins 5 fois plus lent pour moi: 5 Mo / s vs 25 Mo / s sans ce drapeau. Quoi qu'il en soit, maintenant pour la partie gddrescue (ddrescue) ..

heure ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b / dev / sda b.bin

Sur le point de copier 2048 octets de / dev / sda vers b.bin
Positions de départ: infile = 460976 Mo, outfile = 0 B
Copier la taille du bloc: 1 blocs
durs Taille du bloc dur: 512 octets
Max_retries: 0
Direct: oui Clairsemé: non Fractionné : non tronquer: non

Appuyez sur Ctrl-C pour interrompre le
sauvetage: 1536 B, taille erronée: 512 B, taux actuel: 53 B / s
ipos: 460976 Mo, erreurs: 1, taux moyen: 53 B / s
opos: 1536 B, temps depuis la dernière lecture réussie: 0 s
terminé

réel 0m18.736s
utilisateur 0m0.004s
sys 0m0.000s

Comme indiqué ci-dessus, l'exécution a pris exactement le même temps. Comme prévu - mêmes statistiques: 3/4. Cependant, alors que je pouvais remplir les secteurs en difficulté avec 0x00 pour dd (conv = sync), gddrescue semble manquer cette fonctionnalité? Au lieu de cela, il saute simplement le secteur en difficulté sans écrire quoi que ce soit à sa position et continue avec le secteur suivant (si j'ai déjà des données écrites sur ce secteur dans le fichier de sortie - elles ne seront pas écrasées: parfois cela pourrait ne pas être souhaitable ). Je ne sais pas comment fonctionne l'option -t (tronquer) pour un périphérique bloc avec gddrescue(je suppose, il le remplacera complètement avec 0x00), mais sur un fichier normal, il tronquera, comme prévu, tout le fichier sans le faire uniquement dans les dimensions de décalage (c'est-à-dire -o1). Donc, c'est un peu similaire à dd sync , mais loin d'être le même car il ne reproduira que la fonctionnalité d'identicle SI vous êtes prêt à écraser l'ensemble du périphérique / fichier de sortie.

Bien que, grâce à la présence d'une option verbeuse et à la possibilité de consigner les secteurs / blocs défectueux , gddrescue semble être un meilleur choix. Il est important de noter que les deux applications ont été lancées avec (à peu près) des paramètres identiques.

La sortie de

diff? .bin

est vide (exit 0), ce qui signifie que les fichiers sont exactement les mêmes.

Maintenant, c'est la partie que je ne comprends pas :

dd est lent même sur les trucs sans erreur car il fait de minuscules lectures et écritures. Cela passe beaucoup de temps à mâcher les parties erronées du lecteur, plutôt que de lire autant de trucs sans erreur que possible, puis de revenir pour faire les choses difficiles.

Qu'est-ce que ça signifie? Surtout la partie " ça passe beaucoup de temps à mâcher les parties erronées du disque, plutôt que de lire autant de trucs sans erreur que possible, PUIS de revenir pour faire les choses difficiles "? Cela a pris le même temps que celui indiqué ci-dessus (même si j'ai inspecté une très petite partie des données, mais cela devrait-il être important?).

gddrescue propose le commutateur -r , qui devrait contrôler le nombre de relectures sur un "secteur défectueux", cependant, dd semble toujours fonctionner avec le -r0 (car cela a pris le même temps). Alors, cette option est-elle uniquement destinée au "post-traitement"? Ce que je veux en venir, c'est qu'à l'origine, dd et gddrescue semblent fonctionner avec -r0 et dd ne semble pas mâcher les parties erronées plus que gddrescue (ils semblent tous deux s'arrêter sur un mauvais bloc pendant 15-18 donner ou prendre des secondes, alors quel est le problème, comment gddrescue est- il plus rapide ???)

En outre, à quoi sert l' option -D (utiliser des écritures synchrones pour le fichier de sortie)? Je n'ai remarqué aucune différence avec certains des tests effectués.

Quelqu'un peut-il commenter le tout? Merci.

Je ne sais pas comment l'auteur cité est parvenu à sa conclusion. Je ne discute pas s'il a raison ou non, je n'ai tout simplement pas cette expérience.

En revanche, en ce qui concerne cette déclaration ...

gddrescue est supérieur à dd au moins en termes de capacité à distinguer la quantité de lectures de disque effectuées sur un secteur en difficulté.

La vraie "au moins" raison d'utiliser gddrescue est que gddrescue ne tronque pas la sortie lors de tentatives répétées de lecture / écriture. gddrescue est également entièrement automatique, en ce qui concerne certaines erreurs de lecture qui arrêteraient dd.

Donc, l'auteur cité peut avoir raison, il peut ne pas ... mais toute la déclaration manque le point de gddrescue.

MISE À JOUR: Différences détaillées entre dd et gddrescue.

dd conv = noerror, continuera après une erreur, mais il sautera simplement le mauvais bloc. même l'ajout de l'option de synchronisation mettra simplement des zéros au lieu de sauter. Si vous utilisez dd pour effectuer une autre lecture en utilisant la même sortie, vous écraserez / perdrez simplement tout ce que vous avez récupéré précédemment.

gddrescue, continuera également après l'erreur. Il peut récupérer un rendement partiel d'un bloc défectueux, et va revenir en arrière et tenter le bloc secteur par secteur. gddrescue conservera un journal d'erreur détaillé, avec les bons blocs, les mauvais blocs et le secteur par secteur de tous les mauvais blocs. Si vous essayez d'effectuer à nouveau la lecture, gddrescue coupera (tronquera) et ajoutera toutes les données supplémentaires récupérées.

Gardez à l'esprit, même avec les deux outils, si un bloc entier est 100% illisible. Vous n'en obtiendrez toujours aucune donnée. gddrescue peut potentiellement obtenir plus de données, si certains secteurs du bloc restent lisibles.

Selon le moment où votre disque dur a été fabriqué ainsi que le fabricant et la version du micrologiciel qu'il exécute, avec les disques durs modernes, lorsque de mauvais secteurs sont détectés, ils sont retirés de l'utilisation par le micrologiciel et le lecteur sait ignorer les secteurs défectueux. Ainsi, la notion de «sauver» un disque dur de secteurs défectueux peut être théorique à cet égard. La question de savoir si les secteurs désormais mauvais disposaient autrefois de données valides semble être la solution de cas que vous recherchez - sans jeu de mots!

Il existe sur grc.com un logiciel appelé spinrite 6 qui prétend pouvoir réparer les disques durs avec de mauvais secteurs. C'est un logiciel payant et je ne l'ai jamais essayé. Cela vaut la peine d'être lu, surtout si l'on tente de "ressusciter" un disque dur et qu'il fonctionne réellement comme décrit. La FAQ sur grc.com concernant spinrite 6 indique qu'il y a une garantie de remboursement de 30 jours (et il n'y a pas d'essai ou de version gratuite). Remarque: je ne suis pas affilié à grc.com et je ne le recommande pas pour votre situation. Je sais juste qu'il existe et pourrait fonctionner comme annoncé, mais ne me croyez pas sur parole - caveat emptor.

En ce qui concerne l’évaluation de la supériorité de gddrescue sur dd, du moins en ce qui concerne la possibilité de distinguer la quantité de lectures de disque effectuées sur un secteur en difficulté, un nombre quelconque de lectures sur un secteur défectueux (car il est marqué comme non secteur fonctionnel dans une liste de secteurs défectueux conservés dans une liste de firmware) ne me semble pas utile dans une utilisation qualitative de gddrescue ou dd.

Vous pouvez trouver utile de lire la page Web, dd (Unix) à: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd

Vous pouvez également trouver utile de consulter: Comment créer une image d'un disque dur en panne à l'aide de l'UBCD, de dd-rescue et de P2 eXplorer sur: http://www.myfixlog.com/fix.php?fid= 21