web-dev-qa-db-fra.com

GNU Résultats d'imagerie ddrescue - 116 erreurs, beaucoup?

Un peu de fond à ce sujet.

Il s'agit d'un lecteur SSD de 256 Go avec Windows SP3 32 bits et chiffré avec PGP Whole Disk Encryption. Le système de fichiers est corrompu et illisible.

J'ai d'abord lancé Clonezilla pour cloner le lecteur avec -q1 (clone de secteur) et Clonezilla n'a pas pu démarrer le processus de clonage, car il indiquait que le lecteur était endommagé (le détermine-t-il en utilisant SMART ou en regardant le G -Liste?). J'ai ensuite coché -rescue (saute les secteurs défectueux) et il a cloné.

Je voulais une meilleure image/clone, j'ai donc trouvé le CD Live de Ubuntu Rescue Remix et lancé GNU ddrescue. J'ai créé une image du lecteur SSD en utilisant la syntaxe suivante: Sudo ddrescue -r 5 -v -d {lecteur source} {dest drive/imgfile} fichier_journal (essaie 5 fois les secteurs défectueux; sortie détaillée à l'écran, mode d'accès direct à ignorer cache du noyau).

Il s'est terminé en 14h30-15h00. Le taux de transfert moyen était d'environ (25,88 Mo/s) (j'ai utilisé eSATA et SATA, respectivement, pour transférer des données). Il répertorie également "errors: 116" et "errsize: 470 kB". Pour mémoire, le programme répertorie "Taille du secteur: 512 octets" et "Taille du bloc de copie: 128 secteurs".

(Je ne peux pas poster une image car je suis nouvelle.)

Deux choses:

  1. Les résultats indiquent-ils que 116 erreurs (secteurs ou blocs?) Totalisant 470 ko ont été trouvées et transférées ou trouvées et non transférées? Si vous remarquez, le programme indique qu'il est sur le point de copier 256052 Mo et indique qu'il en a récupéré 256052. Donc, je ne suis vraiment pas sûr.
  2. 116 erreurs sont-elles considérées comme un lot et indiquant des dommages physiques?

Pour le moment, je peux confirmer qu'au moins 99% des données ont été transférées. Je dirais que c'est plutôt bien. En fait, le calcul approximatif est le suivant: 1 - (470 ko/256 Go) = ~ 0,9999981640625 -> 0,9999981640625 * 100 ~ 99,9998%.

Encore une fois, Clonezilla n'a pas pu cloner, car elle a signalé que le lecteur est physiquement endommagé. Cependant, alors que GNU ddrescue a signalé 116 erreurs, au moins la plupart des données ont été numérisées. Je sais qu'il y a des erreurs logiques sur le lecteur. Mais ce lecteur est-il physiquement endommagé sur la base de 116 erreurs totalisant 470 ko?

Enfin, quelle est une erreur? Est-ce que ce nombre de blocs défectueux, de secteurs ou autre chose? Et est-ce du tout lié à errsize. Dans mon cas, il s'agit de 116 erreurs et d'une erreur de 470 Ko. Mais j'ai vu d'autres scans sur Internet avec une erreur et une taille d'erreur de 500 Go. Donc, je ne suis pas sûr de la corrélation qui existe.

Mettre à jour

Je n'ai pas de réponse, je vais donc mettre à jour et espérer que quelqu'un plus intelligent que moi répondra avec quelques réponses.

J'ai lancé GNU ddrescue une fois de plus, les tentatives de lecture étant passées de 5 à 20. Toutes les autres tâches sont identiques, y compris les résultats (il a fallu un peu plus de temps pour l'image que la première fois, en raison de l'augmentation du nombre de tentatives de lecture). . Oui, le nombre d'erreurs et la taille de l'erreur (vous ne comprenez toujours pas leur relation ou ce qu'une erreur signifie dans ce programme) sont de 116 et 470 Ko, exactement les mêmes que la première fois que j'ai imagé avec ce programme. Qu'est-ce que cela pourrait signifier? Mettez une arme à la tête, je dirais que ce lecteur SSD n'est pas physiquement endommagé. Et si c'est le cas, c'est léger. Je ne sais toujours pas si 116 erreurs, c'est beaucoup, mais voici pourquoi je pense qu'il n'y a pas de dégâts physiques. Si tel était le cas, le nombre d'erreurs et la taille de l'erreur n'augmenteraient-ils pas la deuxième fois que j'imaginerais le lecteur, en particulier en augmentant le nombre de tentatives de lecture à 20?

Je voulais que les erreurs disparaissent, c'est pourquoi j'ai de nouveau essayé de créer des images. Je n'ai pas beaucoup d'expérience avec les SSD. Mais ils diffèrent peut-être des disques mécaniques en ce que si vous ne pouvez pas lire un bloc défectueux, vous ne pourrez probablement pas le faire, peu importe le nombre de fois que vous réessayez. Je suppose cependant que les services de récupération de données disposent d’outils logiciels et matériels nettement supérieurs, capables de lire les blocs défectueux d’un SSD.

Ce lecteur SSD a été asservi plusieurs fois pour analyser et tenter un décryptage. J'ai cloné avec Clonezilla (qui prétend être physiquement endommagé), puis je l'ai imagé deux fois avec GNU ddrescue avec une valeur de paramètre augmentée et les résultats de l'image sont exactement les mêmes. On pourrait penser qu'avec tout ce que ce disque a traversé, s'il échouait, il faudrait beaucoup de temps pour lire/écrire et le nombre d'erreurs augmenterait. Mais rien de tout cela n'est arrivé. Peut-être que je suis juste avoir de la chance et qu'il est physiquement endommagé. Mais si c'est le cas, je pense que c'est léger.

Mais je vais demander à nouveau: 116 erreurs, c'est beaucoup? Quelle est la corrélation entre les erreurs et la taille de l'erreur, lorsque j'ai lu les comptes de résultats d'image avec 1 erreur et une taille d'erreur de beaucoup, beaucoup de Go? Et est-ce une erreur ici en termes de secteurs, de blocs ou d'une autre mesure?

Je vous remercie.

2
user301234

Le section Algorithm du manuel de ddrescue décrit errsize et errors. errsize est la somme des tailles des "blocs" de secteur défectueux, où "bloc" est le terme utilisé par ddrescue pour désigner une gamme de secteurs défectueux contigus. Par contre, errors est le nombre de ces "blocs" de secteur défectueux.

Comme le décrit le manuel, à chaque passage après le premier, les "blocs" de secteur défectueux sont retentés et peuvent être scindés. Lorsque les secteurs défectueux sont lus avec succès, errsize diminuera et errors pourrait augmenter ou diminuer (puisqu'un bloc peut être divisé par un bon secteur ou que tous les secteurs défectueux d'un bloc ont été lus avec succès, respectivement) .

Donc, pour répondre à votre question, "le nombre d'erreurs numériques est-il élevé?", Vous devez regarder le errsize plutôt que le errors. Sur un SSD de 256 Go, je ne pense pas que 470 Ko (moins de 0,0002% du lecteur) soient très nombreux.

Vous devriez également regarder smartctl et le auto-tests S.M.A.R.T pour déterminer l'état de santé du lecteur. À mon humble avis, une fois que le lecteur a échoué aux tests préalables à l’échec, le risque de perte de données ne vaut généralement pas la peine de continuer à utiliser le lecteur.

3
adborden