Cette commande ddrescue fait-elle quelque chose?

Au cours de la tentative de récupération des données d'un disque dur défaillant , j'exécute la commande ddrescue.

La commande est en cours d'exécution depuis 9 jours, et je pensais, d'après le son de l'activité du disque, qu'elle faisait peut-être quelque chose. La sortie de la ligne de commande a semblé plus ou moins statique tout ce temps:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

La seule partie qui a changé, c'est où il est dit iposet opos. Il a fallu 9 jours pour se lever 500000 MB, ce qui correspond à la taille du lecteur de disque défaillant. Quand il est arrivé, cependant, il est retombé 0et a recommencé à monter. Au moment où j'écris ceci, c'est à peu près 2580 MBet ça compte.

Le fichier image en cours de création a une longueur de 0 octet.

Le fichier journal a une taille d'environ 3 Mo et ressemble à ceci:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Je commence à craindre que ce ne soit qu'une perte de temps et qu'aucune donnée ne soit récupérée du tout.

Y a-t-il une indication de cette sortie que quelque chose d'utile se passe?

Y a-t-il une raison de laisser la ddrescuecommande continuer telle quelle ou dois-je l'arrêter et faire autre chose?

Ceci est le contenu le plus récent de /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

Je ne sais pas si vous essayez toujours d'extraire des données de ce disque dur ou si vous avez déjà réussi, mais au cas où vous n'auriez pas réussi et que vous souhaitez essayer de voir si vous pouvez récupérer, peut-être, perdu Bitcoins ou autre, j'ai apporté quelques modifications à vos ddrescueparamètres de ligne de commande, j'ai ajouté ce qui suit:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d qui indique à ddrescue d'utiliser l'accès direct au disque,
• --force qui dit à ddrescue d'utiliser et de lire / écrire avec force dans votre fichier journal au cas où il se plaindrait de ne pas pouvoir l'utiliser à des fins de lecture / écriture
• -R (oui, avec CAPITAL R) qui indique ddrescued'effectuer les opérations de récupération en sens inverse au lieu de lire le disque dur défaillant en mode direct. Parfois, la lecture en sens inverse aide lorsque les dommages sont importants car cela contourne le cache du disque dur au cas où il y aurait des problèmes.

Actuellement, j'utilise ces commandes (sauf que je n'utilise pas la 3commande car je ne veux pas que [ENCORE] ddrescueréessaye les secteurs défectueux, je vais laisser cela pour la fin, après mon premier balayage, et j'ai un grand succès en sauvant les données de mon disque dur Seagate 1 To ont échoué où je suppose que je détiens peut-être quelques bitcoins que j'ai pu extraire de 2009 à 2010, j'ai probablement trouvé 1 à 3 blocs de 50 BTC chacun, j'espère que c'est sur ce disque dur, eh bien, il me faudra au total plus de 15 jours pour terminer l'opération à un taux de lecture de 634 kbps en moyenne.

En outre, je voudrais ajouter que vous pouvez et très probablement, sur la base de votre historique de plus de 9 jours de «dernière activité de lecture», vous rencontrerez une situation où le disque dur refusera simplement de lire plus loin, dans ce situation, appuyez simplement sur les touches CTRL + C pour annuler car vous utilisez un fichier journal, retirez le câble SATA du disque dur défectueux, mais pas le contrôleur USB du port USB (oui, utilisez un contrôleur USB SATA au lieu de le connecter à une carte mère pour ne pas verrouiller tout votre ordinateur, vous obligeant à redémarrer dur, puis rebranchez l'alimentation SATA pour redémarrer le disque dur, donnez-lui environ 10 secondes, puis appuyez sur la flèche haut ou bas pour recharger votre terminal précédent commander et redémarrer leddrescueopération, grâce à votre journal précédent, il continuera là où il s'était arrêté pour la dernière fois et il y aura une lecture en cours et la "dernière lecture réussie" restera toujours à "0s" (zéro seconde) où elle devrait, indiquant que la ddrescueréussite est lecture à partir du disque dur, et si jamais vous remarquez que la "dernière lecture de" commence à compter les secondes, il suffit de terminer à nouveau ddrescueavec CTRL+ C, de redémarrer le disque dur et de redémarrerddrescue, il ne sert à rien d'attendre de voir si la "dernière lecture de" redémarre à 0 par elle-même, d'après mon expérience, cela ne se produira jamais, vous attendez l'éternité. J'ai dû éteindre et rallumer mon mauvais disque dur de 1 To environ 20 fois au total, cela fait 7 jours et je suis très proche d'atteindre la barre des 500 Go, à mi-chemin, j'espère que je ne rencontrerai pas d'échecs majeurs car Je suis proche de 100% car cela fonctionne parfaitement depuis 3 jours, toujours à plus de 634 kbps.

En outre, ne soyez pas gourmand en essayant d'obtenir un taux de lecture de débit de données plus rapide, car ma tentative d'essayer de nombreux paramètres et différentes tailles de bloc m'a presque laissé avec une rive complètement morte qui cessera de fonctionner en plus d'une seconde après la mise hors puis sous tension. (c'était il y a 5 jours) mais heureusement, cela a recommencé à montrer des signes de vie, lisant initialement à 2000 bs (oui BYTES par seconde) un peu moins de 2 kbps, j'ai été très déçu, mais après avoir annuléddrescueavec CTRL + C et juste le redémarrer à nouveau (en sens inverse avec le paramètre -R) ajouté, puis la vitesse est revenue à 630, avant de lire en avant à 930 kbps, au moins je suis content que je fais 630 kbps en sens inverse et ne pas avoir à différer avec 2 kbps, donc si vous réussissez à n'importe quelle vitesse de lecture, comme dans la gamme de 500 kbps, n'essayez pas de pousser les vitesses plus haut, cela peut être votre dernière tentative réussie de gagner toute vitesse de lecture.

Alternativement, si cela ne vous ddrescueest pas utile parce que vous ne pouvez rien lire, quels que soient les paramètres que vous essayez, vous pouvez envisager de remplacer la carte logique du disque dur, car 90% du temps, c'est la carte logique qui va mauvais, mais d'abord, retirez la carte logique et nettoyez tous les contacts qui établissent des contacts avec les broches du disque dur, parfois ces contacts contiennent un mélange gluant noirâtre, coupant le contact qui pourrait être la source de votre échec. Mais sachez que si vous devez remplacer la carte logique de votre disque dur, vous devrez obtenir une même marque, numéro de série (proche), numéro de modèle, numéro de révision car il doit être aussi proche que l'original pour le conseil des donateurs pour travailler.

Vous devriez pouvoir arrêter ddrescuecar il utilise le fichier journal pour pouvoir redémarrer son opération (près) à l'endroit où il est parti. Je vérifierais cependant si le fichier journal a été récemment mis à jour en regardant l'horodatage ou en faisant tail -f /home/dave/recovery_usb500.logfile.

Le fait que votre fichier image soit toujours aussi petit pourrait avoir à voir avec aucun bloc ayant été récupéré avec succès depuis le lecteur. Ce serait cependant un mauvais résultat après tout ce temps de course. En supposant qu'il n'y a que quelques blocs défectueux sur l'appareil, et qu'ils ne le sont pas au début, votre premier état d'entrées serait +. IIRC ddrescuecommence la lecture jusqu'à ce qu'il trouve une erreur, puis commence à diviser le reste du disque. Votre disque semble échouer dès le début.

À moins qu'il n'y ait (plusieurs) +entrées dans le journal et que la taille de votre fichier soit toujours, 0je ne pense pas que ce ddrescuesoit faux. Pas +de dire que rien de votre lecteur était récupérable. Cela pourrait signifier de l'électronique frite ou une mauvaise tête, car si seulement quelques secteurs étaient défectueux, vous auriez eu des résultats beaucoup plus rapidement.

Quant à faire autre chose. Je suppose que vous avez déjà essayé de lire quelques blocs avec un dd normal. Avez-vous regardé le syslog sur cette base et googlé tous les messages que vous y avez trouvés?

La recherche de "Résultat: hostbyte = driverbyte non valide = DRIVER_SENSE" donne lieu à quelques lectures intéressantes (en partie allemandes) avec quelques suggestions supplémentaires:

• Essayez de vous connecter via USB 1.1 au lieu de 2.0
• Le lecteur peut devenir chaud, alors enveloppez-le dans du plastique et mettez-le au réfrigérateur pendant 10 minutes, ce qui donne un certain temps de lecture avant que le lecteur ne chauffe à nouveau.
• commutateur de SMART dans le BIOS (et connectez-vous avec SATA).
• Assurez-vous que la clé USB est suffisamment alimentée (alimentation supplémentaire)
• Si la lecture sur USB échoue après un certain temps, utilisez un concentrateur USB contrôlé à distance où vous basculez par programme l'alimentation du concentrateur USB vers le lecteur pendant quelques secondes.

Hormis le refroidissement d'un disque illisible (avec un spray de refroidissement), je n'en ai pas essayé moi-même.