testdisk montre une taille de lecteur incorrecte
J'essaie de récupérer les données d'un disque dur endommagé avec testdiskname__. Je me suis bien débrouillé, j'ai fait une recherche rapide, une recherche approfondie, puis, après avoir confirmé que mes fichiers avaient été trouvés par testdiskname__, j'ai écrit la table de partition. et redémarré l'ordinateur. Donc, maintenant je pense avoir un problème encore plus grand. Le disque dur sème maintenant testdisken tant que lecteur de 2 999 Go, et si je le branche directement sur le port SATA, comme recommandé dans la FAQ du testdisk, même mon BIOS ne le reconnaît pas correctement et je ne peux plus exécuter testdiskcar il ne reconnaît pas le disque avec sa taille normale (500 Go).
Essayer de monter le lecteur en lecture seule pour tenter de récupérer des données ne fonctionne pas non plus, je reçois le message que le "NTFS is inconsistent".
J'ai essayé de voir le lecteur dans le Gestionnaire de disque Windows, mais cela prend beaucoup de temps avant de s'afficher, et toujours sous forme brute, sans information sur sa taille.
la sortie de testdisk en reconnaissant le lecteur. Vous pouvez voir mon disque dur personnel (sda) et le lecteur que je veux récupérer (sdb). Les deux doivent être répertoriés comme 500GiB.
Une chose à noter est que l’espace disque occupé dans la liste par sda (mon disque dur) est l’espace disque occupé par le disque dur que je veux récupérer. En réalité, la quantité d'espace disque occupé dans mon disque dur est de 110 Go.
Je peux confirmer que le lecteur n'est pas mort car les voyants s'allument et je peux sentir le disque fonctionner.
si j'utilise smartmontools ou gsmartcontrol pour connaître l'état du disque dur, le résultat est le suivant:
l'écran de détails pour le lecteur
Il est très important pour moi de récupérer ces données car le matériel de niveau universitaire et de maîtrise y est en cours de développement. Ma dernière sauvegarde date d'il y a un mois (je ne peux pas le faire tous les jours en raison de l'espace disponible sur ma clé USB externe de sauvegarde).
J'espère que quelqu'un pourra vous aider et je sais que beaucoup de gens ont aussi ce problème.
Faits pouvant apporter une connaissance utile:
La démonstration de R-Studio était inutile lors de mon test. Si j'essaie de l'ouvrir avec le lecteur branché, le programme ne fonctionne tout simplement pas/ne répond pas.
Le diagnostic de WD Lifeguard Diagnostic n'est pas utile non plus, car il ne montre pas le lecteur sur sa table.
Le lecteur n'a pas l'air psychiquement endommagé.
EDIT 1:
Comme demandé, l'écran [ Geometry ]: 
Devrais-je essayer d'ajuster le nombre pour qu'il indique la véritable capacité du disque ou existe-t-il une option de récupération?
EDIT 2: Le lecteur est un WD Blue, modèle WD500LPVX
EDIT 3: La sortie de la commande parted -l /dev/sdb est la suivante: 
la sortie de la commande Sudo grep -abiro "NTFS " /dev/sdb m'a donné, après un certain temps d'exécution:
grep: /dev/sdb: Input/output error
En corrigeant l’impression, on dirait que sdba été démonté avant la commande Parted, l’image ci-dessus est la véritable sortie.
Une chose à noter, la commande grepaprès la première sortie prenant environ 20 secondes, donne instantanément la même sortie si je réexécute la commande sans débrancher le lecteur.
EDIT 4:
ddrescuefonctionne déjà depuis quelques heures, mais je trouve certains points bizarres dans le comportement des sorties, comme suit:
Premièrement, un échantillon de quelques lignes du fichier status.log:
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue /dev/sdc /media/sidious/Supply/dotk/bkpHD/copy.img /media/sidious/Supply/dotk/bkpHD/status.log
# Start time: 2016-07-29 01:05:36
# Current time: 2016-07-29 01:30:51
# Copying non-tried blocks... Pass 1 (forwards)
# current_pos current_status
0x8482360000 ?
# pos size status
0x00000000 0x00010000 *
0x00010000 0x00010000 ?
0x00020000 0x00010000 *
0x00030000 0x00020000 ?
0x00050000 0x00010000 *
0x00060000 0x00040000 ?
Est-ce que ça devrait être comme ça?
Deuxièmement, la sortie de la commande peut être vue ici: 
Je ne sais pas si les valeurs présentées dans rescuedname__, iposet opossont erronées ou non. Je demande donc à quelqu'un de me dire si cela devrait être ainsi. le disque a une capacité réelle de 500 Go, et certains des chiffres indiqués sont plus grands que cela.
La taille du fichier copy.img est également égale à 0 octet. Cela signifie-t-il qu'aucune donnée n'est copiée ou qu'il n'y a aucune donnée réussie à récupérer?
EDIT 5:
Après un long processus et patientez, avec beaucoup de modifications apportées au lecteur pour que le processus continue, ressemble à ddrescueterminé, mais le fichier .img contient 0 octets. Ai-je fait quelque chose de mal? Je viens de suivre les instructions données.
EDIT 6
Je marque cette question comme résolue, car le processus donné pour résoudre l'erreur fonctionnerait surtout si le lecteur n'était pas "mort". Merci à tous ceux qui ont réfléchi et surtout à Andrea Lazzarotto .
Le lecteur n'a pas l'air psychiquement endommagé.
Heureusement, les disques durs n'ont pas de sentiments. ;) Cependant, je suis désolé de vous informer que votre disque a été physiquement endommagé ou du moins qu'il est en panne:
donne instantanément le même résultat si je lance à nouveau la commande sans débrancher le lecteur
Cela signifie fondamentalement "pas bon".
Les choses que vous devez absolument faire dans ce cas sont:
- arrêter toute écriture sur le lecteur (vous avez déjà arrêté de tenter de réécrire la table de partition avec
testdisk, ce qui est bien) - faire une copie bitstream (aka fichier image) du lecteur en panne
Cloner le lecteur
Tout d’abord, installez l’outil ddrescue par le biais du package gddrescue (le g est et non une faute de frappe), qui permet de créer des copies précises des lecteurs défaillants. cloner autant d'informations que possible. Je vais essentiellement citer ma réponse sur une question connexe:
Sudo ddrescue /dev/sdb /media/user/External/copy.img /media/user/External/status.logLe fichier
status.logn'est pas obligatoire, mais il est nécessaire si vous souhaitez suspendre le processus et le reprendre plus tard.
Comme vous pouvez le constater, vous aurez besoin d’un autre lecteur suffisamment grand pour contenir une copie de l’ensemble du lecteur de 500 Go (en gros, un disque dur d’au moins 1 To). Dans mon exemple, il est monté sur /media/user/External. Adaptez l'exemple à votre situation.
L'outil ddrescue enregistre sa progression dans le fichier /media/user/External/status.log. Ceci est très utile car le lecteur peut "disparaître" à cause d'erreurs d'E/S (comme ce fut le cas avec grepping ). Le programme va s'arrêter. Vous reconnectez le lecteur et exécutez à nouveau la même commande: il continuera là où il avait été arrêté.
De plus, ddrescue lit d'abord les "bons" et les "gros" blocs, puis revient aux zones les plus endommagées en essayant de réduire la quantité de données lues en une seule opération jusqu'à ce que tous les bons bits aient été isolés.
Même si le lecteur indique qu'il s'agit d'un lecteur de 2 To, il s'agit en réalité d'un lecteur de 500 Go. Par conséquent, le processus de copie du lecteur s’arrête à 500 Go.
Exécuter TestDisk sur la copie
Vous pouvez maintenant utiliser TestDisk comme avant, mais sur la copie:
Sudo testdisk /media/user/External/copy.img
Quand vous arrivez au point de voir le contenu de la partition (avec le P clé), ne continuez pas à écrire la table de partition. Au lieu de cela, utilisez le C clé pour commencer à extraire les données dont vous avez besoin (espérons-le, elles pourraient ne pas être endommagées).
Pour cette opération, vous aurez besoin d'espace libre sur n'importe quel lecteur (soit celui sur lequel vous avez stocké la copie bitstream, soit une clé USB, etc.) pour extraire les fichiers.
Si TestDisk échoue
Si TestDisk ne peut pas accéder au lecteur NTFS parce qu'il n'est pas endommagé, vous pouvez utiliser RecuperaBit pour reconstruire la structure NTFS comme expliqué dans la réponse susmentionnée .
Avertissement: Je suis le développeur de RecuperaBit.