Disque dur externe (3TB) corrompu - table de partition probablement endommagée

Nous l'avons réparé. Ce n'est en aucun cas une réponse canonique, mais elle peut contenir des informations utiles pour les futurs visiteurs.

Tout le monde avait suggéré d'analyser le disque avec testdisk.

Ce que fait l'analyse :

Analyse la structure de partition actuelle d'un disque et trouve les partitions, ce qui permet de récupérer les partitions perdues.

Le problème dans notre cas n'était pas qu'il nous manquait des partitions, mais que les partitions qui étaient il n'a pas été possible d'y accéder.

Nous ne connaissions rien à la récupération des données, aux tables de partition, etc. Nous avons donc commencé à faire des recherches et sommes tombés sur a Nous avons conclu qu'il n'y avait pas un problème avec les partitions, mais avec la façon dont elles sont "indexées" sur le disque. Nous pensions que cela était géré par la table de partition.

Nous avons analysé le disque avec testdisk plusieurs fois, avec différentes options pour le type de table de partition (nous ne connaissions pas le type à l'origine, mais à la fin il s'est avéré être EFI GPT), en espérant que testdisk serait en mesure de trouver des problèmes avec la table de partition qu'il pourrait restaurer afin que nous puissions à nouveau accéder aux données. Nous l'avons laissé réécrire la table de partition après l'avoir analysée plusieurs fois, mais cela n'a jamais aidé.

Avant d'essayer différentes solutions potentielles que nous ne connaissions pas encore, nous avons décidé de ne pas prendre de risques et avons acheté un nouveau disque dur de 3TB et cloné l'ancien sur celui-ci.

Une chose étrange que nous avons remarquée est que lorsque nous avons analysé le clone, testdisk n'a pris qu'une seconde pour afficher les résultats, alors qu'avec l'ancien, cela prenait plusieurs heures. Il disait également qu'il avait détecté que le type de table de partition était EFI GPT . L'ancien avait été détecté comme Linux et au moins un autre type, mais pas EFI GPT .

Cela nous a fait penser qu'il était très possible qu'il y ait un problème avec le disque d'origine, lié au matériel. Nous avons pensé Comment un clone peut-il se comporter différemment de l'original s'il n'y en a pas ?

Tout semblait donc correct, mais ce nouveau disque ne pouvait pas non plus être monté. Le message suivant s'affichait

wrong fs type, bad option, bad superblock on /dev/sdb,  
missing codepage or helper program, or other error  
In some cases useful info is found in syslog - try  
dmesg | tail  or so

et dmesg dirait

hfs: unable to find HFS+ superblock

Cette erreur a été signalée à gauche et à droite, même ici sur SU, mais aucune des solutions proposées (par exemple, "spécifier la taille et le décalage lors du montage") n'a fonctionné pour nous.

En cherchant des indices, nous avons trouvé une option dans le menu avancé de testdisk appelée "Superblock" ou quelque chose de similaire.

Dans ce menu, il y a des options pour comparer la structure du superbloc à la sauvegarde, et pour écraser la sauvegarde. La première chose que nous avons faite est de comparer les deux pour voir si elles sont identiques.

Il n'y avait pas de données dans la sauvegarde. Le vidage hexagonal ne montrait que des zéros. Nous avons pensé que ce qui pourrait mal se passer en écrasant un tas de rien. et laisser testdisk écraser la structure de sauvegarde. Il l'a fait et nous a dit de redémarrer pour que les changements prennent effet.

Après le redémarrage, ubuntu a montré le disque dans le lanceur (première fois qu'il l'a fait) et en cliquant dessus, il a été monté avec succès, nous permettant de lire les données.

Note complémentaire, comme indiqué dans les commentaires :

Ce que beaucoup de gens ignorent, c'est que vous ne devez JAMAIS essayer de restaurer des fichiers sur le même disque ! Jamais. Commencez toujours par cloner le disque. Plus correctement : N'écrivez JAMAIS sur le disque sur lequel vous essayez de récupérer des données.