Partition renommée automatiquement : impossible à monter

[Typhuss]

Bonsoir,

Je n'ai vu nulle part quelqu'un ayant le même problème : une partition d’un de mes disques externes a été automatiquement renommée (par le système ?) qui lui a donné le nom d’une autre partition existante sur un autre disque externe.

En clair et pour simplifier, j’ai 2 disques externes :

• un Samsung de 1To avec 2 partitions de 500Go : WIN500 (FAT) et TM5 (HFS)
• un Toshiba de 2To avec 2 partitions de 1To : HIT1TO (HFS) et HI-TM1T (HFS)

La partition TM5 a été renommée HIT1TO.
Depuis, impossible de monter cette partition, impossible de la réparer non plus. Or, il contient mes sauvegardes Time Machine.

Sauriez-vous comment faire pour le renommer ? ou réussir à monter la partition ?

Ci-dessous les résultats des commandes diskutil au niveau des disques externes puis de la partition qui pose problème. A noter d’ailleurs que le nom initial de formatage était bien « TM500 », mais que je l’ai changé il y a peu en « TM5 » qui n’apparaît nulle part.

Merci beaucoup de votre aide.
Bonne soirée

__________________________________________________
diskutil list

/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS MachintoshHD 249.5 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS MachHD 2 249.9 GB disk0s4
5: Apple_CoreStorage Data500 499.6 GB disk0s5
6: Apple_Boot Boot OS X 134.2 MB disk0s6
/dev/disk1 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_HFS HIT1TO 500.0 GB disk1s2
3: Microsoft Basic Data WIN500 499.9 GB disk1s3
/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_HFS HIT1TO 1.0 TB disk3s2
3: Apple_HFS HI-TM1T 999.9 GB disk3s3

__________________________________________________
diskutil info disk1s2

Device Identifier: disk1s2
Device Node: /dev/disk1s2
Whole: No
Part of Whole: disk1
Device / Media Name: TM500

Volume Name: HIT1TO

Mounted: No

File System Personality: HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended
Journal: Unknown (not mounted)
Owners: Disabled

Partition Type: Apple_HFS
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Volume UUID: 3E445728-CA0E-3174-82E4-5BC1FC2727AE
Disk / Partition UUID: 416C37F1-7E63-4A61-8965-75A014B69C9E

Total Size: 500.0 GB (500000002048 Bytes) (exactly 976562504 512-Byte-Units)
Volume Free Space: 0 B (0 Bytes) (exactly 0 512-Byte-Units)
Device Block Size: 512 Bytes

Read-Only Media: No
Read-Only Volume: Not applicable (not mounted)

Device Location: External
Removable Media: No

 

[Membre supprimé 1060554]

Salut Typhuss [j'espère que ton pseudo n'est pas contagieux]

Si je te fais un bout de conversation, ce n'est pas que j'aie une solution toute prête, mais que les énigmes m'intéressent. Or c'est une véritable énigme logique que tu as décrite : le renommage automatique d'une partition 2 d'un DDE A d'après le nom d'une partition 1 d'un DDE B. Suite à quoi, le système de fichiers de la partition en question ne monte plus en volume - quoique n'ayant pas perdu son nom de volume : ce qui est encore une autre énigme.

Ce qu'il y a de curieux, encore, dans le tableau de partitionnement que t'a retourné la commande diskutil list, c'est :

- la présence d'un format CoreStorage sur la /dev/disk0s5 du disque interne du Mac (accompagné de son driver sur partition conséquente : Boot OS X (/dev/disk0s6) avec un nom de Volume Logique (Data500) qui n'a pas l'air d'évoquer pourtant un OS : s'agirait-il d'un CoreStorage Chiffré destiné à sécuriser certaines données ?

- anomalie qui s'enchaîne avec la précédente : lorsqu'un CoreStorage existe sur une partition du disque interne (/dev/disk0) comme ici, un Volume Logique se trouve exporté qui prend régulièrement le statut de "couche logique de second ordre" par rapport au plan de des partitions de la Table GUID. Ce qui veut dire, en clair : qu'un disque (virtual, internal) se trouve généré, qui a toujours le statut de /dev/disk1 (disque virtuel de second ordre) par rapport au /dev/disk0 (disque physique de premier ordre). Or, d'après le tableau retourné par diskutil list, aucun dispositif de ce type n'est exporté, mais c'est un DDE (physical, external) qui se retrouve listé en tant que /dev/disk1.

- anomalie qui complexifie la précédente encore : si le premier DDE se trouve donc identifié comme /dev/disk1, le second DDE, lui, devrait logiquement être identifié comme device immédiatement suivant, càd. en tant que /dev/disk2. Or il n'en est rien, mais c'est en tant que /dev/disk3 qu'il est identifié => il manque donc à l'appel un device (càd. une entité-disque) au rang /dev/disk2.​

Comment rendre raison de ces anomalies surprenantes ? Le premier argument serait que le tableau restitué ici serait seulement un tableau sélectif, et non le tableau intégral retourné par la commande diskutil list. Admettons néanmoins, pour l'amour des énigmes, qu'il n'en soit rien. Alors, je pourrais encore supposer que, si le disque (virtual, internal) correspondant au Volume Logique monté du CoreStorage de la partition /dev/disk0s5 n'apparaît pas, ce n'est pas parce qu'il n'a pas pu apparaître, mais parce que ce Volume Logique, Chiffré, soit n'aurait pas été monté, soit aurait été démonté après avoir été monté avec un mot-de-passe ad-hoc.

Imaginons alors ceci : le disque (virtual, internal) du Volume Logique Chiffré n'aurait pas été monté d'entrée et le seul DDE n° 1 aurait été attaché au Mac. Logiquement, le disque physique du Mac serait identifié comme /dev/disk0 (physical, internal) et le DDE n°1 comme /dev/disk1 (physical, external). Supposons alors que le disque du Volume Logique Chiffré soit monté seulement => il serait alors identifié comme /dev/disk2 (virtual, internal). Si le DDE n°2 était alors attaché, il serait enfin listé comme /dev/disk3 (physical, external). Supposons alors que le Volume Logique soit démonté, mais pas les 2 DDE, et qu'un nouveau diskutil list soit passé => alors le /dev/disk2 correspondant au device (virtual, internal) du Volume Logique Chiffré disparaîtrait de la liste, mais les identifications des 2 DDE demeureraient constantes : /dev/disk1 (physical, external) pour le DDE n°1 et /dev/disk3 (physical, external) pour le DDE n°2.

Je suis en train de me forlonger hors de la piste directe du lièvre levé dans ce fil, pour suivre quelque passée de dahu complètement hors-sujet, n'est-ce pas ? - ne peut s'empêcher de penser très fort le lecteur que j'imagine perché sur mon épaule droite...

Peut-être pas tant que ça, car le scénario imaginaire que j'ai décrit dans mon § précédent repose sur une condition logique : c'est la « mémoire résiliente du kernel ». La distribution des devices, en effet, se trouve chargée dans la « mémoire du kernel » (le noyau opérateur), de telle sorte que des modifications à la volée (en mode "live" - sans re-démarrage) de cette distribution peuvent très bien ne pas se trouver chargées dans la « mémoire du kernel », ou peuvent donner lieu à une espèce de « mixage » ne correspondant pas avec l'état des lieux à l'instant T. Ainsi, il m'est arrivé de supprimer expérimentalement en mode "live" un CoreStorage réversible dont le kernel avait chargé en mémoire la distribution, sans re-démarrage, et qu'un diskutil list dans la foulée persiste à me renvoyer la trace résiduelle d'un CoreStorage - seulement par effet de « résilience logique » dans la « mémoire du kernel ».

Tu vois où je veux en venir, Typhuss : il s'agit rien de moins que d'une hypothèse de travail, que j'ai pris largement le temps de construire même si elle est vaine => et si le problème que tu as soumis provenait de ce que je viens de décrire = un chargement « inactualisé » dans la « mémoire du kernel » de la distribution logique des partitions-disques à un instant T ? Cela pourrait-il rendre compte de l'aberration concernant le nom de la partition TM5 remplacée par un HIT1TO emprunté à l'identique à une partition-disque montée en parallèle ? - bref : un ratatouillage du kernel ?

La vérification de cette conjecture est on ne peut plus simple : démarre ton Mac sans aucun des DDE attaché. Connecte alors le seul DDE n°1 (qui supporte la sauvegarde TimeMachine) => l'aberration nominale persiste-t-elle ? Avec non-montage du volume TM5 ? Re-démarre, le DDE attaché, mais pas l'autre => le problème persiste-t-il ?

 

[Typhuss]

Bonjour et merci de cette conversation. C'est passionnant et le sera encore plus lorsque nous aurons résolu cette énigme (une énigme concrète pour moi malgré tout !). J'ai déjà appris plein de choses (comme en suivant pas mal d'autres fils sur ce forum).
Quelques éléments de réponse à ce stade :
- le retour de diskutil list est bien intégral, non tronqué
- les tests étaient négatifs : mais je vais les refaire car je ne crois pas avoir testé en démarrant DDE allumé/branché.

Petite info complémentaire : le CoreStorage est sur le DD interne de mon iMac.
J'avais même testé de connecter le DDE avec la sauvegarde TimeMachine sur le MacBook Pro, sans succès alors que le CoreStorage est sur mon iMac => l'argument de rémanence/résilience logique se serait propagé dans le DDE ? (dans sa structure ?)

Voici le retour de diskutil list depuis le MB Pro, DDE connecté au démarrage :

/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 499.6 GB disk0s2
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk1
1: EFI 209.7 MB disk1s1
2: Apple_HFS HIT1TO 500.0 GB disk1s2
3: Microsoft Basic Data WIN500 499.9 GB disk1s3

Et lorsque je lance une vérification/réparation de la partition incriminée :

=> Ce qui est fou (!) c'st que lors de cette vérification, le nom TM5 ressort !
Désolé si ça complexifie encore l'énigme.

 

[Deleted member 1099514]

Salut

Je te conseillerai d'utiliser Testdisk : http://www.cgsecurity.org/wiki/TestDisk_FR pour tenter de récupérer les morceaux. Sinon il faudra réformater la partition incriminée.

Que te renvoie depuis le terminal un :

sudo gpt -r show disk1




@+

 

[Typhuss]

Pour compléter :

- la présence d'un format CoreStorage sur la /dev/disk0s5 du disque interne du Mac (accompagné de son driver sur partition conséquente : Boot OS X (/dev/disk0s6) avec un nom de Volume Logique (Data500) qui n'a pas l'air d'évoquer pourtant un OS : s'agirait-il d'un CoreStorage Chiffré destiné à sécuriser certaines données ?

C'est bien une partition chiffrée, pas d'OS dessus. L'OS est sur la partition MachintoshHD.

Alors, je pourrais encore supposer que, si le disque (virtual, internal) correspondant au Volume Logique monté du CoreStorage de la partition /dev/disk0s5 n'apparaît pas, ce n'est pas parce qu'il n'a pas pu apparaître, mais parce que ce Volume Logique, Chiffré, soit n'aurait pas été monté, soit aurait été démonté après avoir été monté avec un mot-de-passe ad-hoc.

Au démarrage, sauf erreur, cette partition est montée, mais verrouillée. Pour la démonter, il faut d'abord la déverrouiller.

Est-ce qu'il y aurait un espoir plus grand en supprimant le chiffrage de cette partition ? Temporairement, ou définitivement ?

 

[Typhuss]

Que te renvoie depuis le terminal un :
sudo gpt -r show disk1

Salut, voici le résultat (DDE branché sur le MBP, lui-même étant sous SL, pas Capitan) :

gpt show: disk1: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 976562504 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
976972144 263824
977235968 976287744 3 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
1953523712 1423
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header

 

[Deleted member 1099514]

Tu devrais tenter une réparation avec testdisk après avoir sauvegardé les élément de la partition WIN500 si nécessaire.

Tu n'aurais pas bricolé ce DDE avec bootcamp?

 

[Typhuss]

Tu devrais tenter une réparation avec testdisk après avoir sauvegardé les élément de la partition WIN500 si nécessaire.

Je vais tester, et j'ai déjà migré mes données en prévision de supprimer la partition WIN500

Tu n'aurais pas bricolé ce DDE avec bootcamp?

Non, jamais utilisé BootCamp.

 

[Deleted member 1099514]

Avant de tenter la réparation que te renvoie un :
sudo gpt -r -vv show -l disk1

 

[Typhuss]

sudo gpt -r -vv show -l disk1

gpt show: disk1: mediasize=1000204886016; sectorsize=512; blocks=1953525168
gpt show: disk1: Suspicious MBR at sector 0
gpt show: disk1: Pri GPT at sector 1
gpt show: disk1: Sec GPT at sector 1953525167
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - "EFI System Partition"
409640 976562504 2 GPT part - "TM500"
976972144 263824
977235968 976287744 3 GPT part - "WIN500"
1953523712 1423
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header

 

[Typhuss]

Mais j'avais fait tourner testdisk avant...
Voici les résultats (pas folichon, malheureusement) :


PS: c'est quoi la différence entre
/dev/disk1 et
/dev/rdisk1 ?
J'ai fait tourner testdisk sur /dev/disk1

 

[Deleted member 1099514]

Si avec Testdisk (dernier écran) tu te positionnes sur la 2ème partition (Mac HFS) puis tu tapes sur la touche "P" vois-tu tes fichiers TM?

 

[Typhuss]

Si avec Testdisk (dernier écran) tu te positionnes sur la 2ème partition (Mac HFS) puis tu tapes sur la touche "P" vois-tu tes fichiers TM?

>> Support for this filesystem hasn't been implemented.

 

[Deleted member 1099514]

Bon c'est pas de ce coté que tu vas trouver de l'aide.
J'ai testé sur une clé et même résultat.

Par contre pourquoi tu te retrouves avec le nom HIT1TO alors que gpt affiche bien TM500
Je ne pense pas que ça résolve le problème mais tu peux faire un :
diskutil rename disk1s2 TM500

 

[Membre supprimé 1060554]

Interpolations sans rapport avec la problématique de récupération des données de TestDisk :

- a) en ce qui concerne la conjecture de mon premier message (le changement de nom de la partition TimeMachine de TM5 à HIT1TO aurait été un "avatar temporaire" dû au kernel et pas une "inscription permanente" dans le système de fichiers) => conjecture INVALIDE : le DDE attaché à un autre Mac (MacBook Pro et plus iMac), la partition reste identifiée sous le même nom HIT1TO. Ce nom est donc bien inscrit dans le système de fichiers de la partition.

Ce constat opéré, je laisse pour l'instant entre parenthèses les 2 questions « théoriques » : 1° comment peut-il y avoir double (voire triple) intitulé de la partition => l'intitulé « manifeste » = HIT1TO vs l'intitulé « latent » = TM5 (pour diskutil) ou TM500 (pour gpt) ? 2° pourquoi cette situation (càd. quelles sont les causes, ou les raisons, qui ont amené cet état de choses) ? [une raison de cette procrastination, toute subjective, est que je ne suis absolument pas du "soir", mais du "matin"]

♤​

- b) en ce qui concerne le message d'erreur affiché dans le panneau de l'«Utilitaire de Disque» lors de l'opération de vérification/réparation du système de fichiers de la partition TimeMachine :

Vérification du fichier de catalogue.
Structure de nœud non valide
​

=> c'est ce qu'on appelle une « erreur fatale ». Ta partition TimeMachine est un secteur qui débute au bloc n°409640 du mappage de la Table de Partition GUID et qui se termine au bloc n° 976562504. Il s'agit de clusters de 512 octets chacun alignés les uns à la suite des autres, chaque donnée d'écriture de la sauvegarde TM occupant une série de ces blocs, le bloc de tête d'une série portant le titre du fichier et les blocs suivants son contenu. Le bloc suivant le dernier bloc de la donnée précédente portant le titre de fichiers d'une nouvelle donnée d'écriture etc.

La gestion des écritures aux blocs de la partition s'effectue par l'intermédiaire d'une série de fichiers directeurs qu'on appelle un « système de fichiers », dont le type équivaut à un format (JHFS+ pour le standard Apple de ta partition). Ces fichiers gestionnaires de tous les événements concernant les blocs de la partition résident sur les premiers blocs de la partition, càd. son en-tête. Parmi ces fichiers gestionnaires du système de fichiers, il y en a un cardinal qui est le fichier de catalogue, intitulé « catalogue B-tree » pour ce qui est du format JHFS+.

Dans « B-tree », tu trouves la référence à un « arbre » et c'est bien d'un dispositif logique en arbre renversé qu'il s'agit. Au sommet, une racine unique d'une valeur 0 ; à l'extrémité, des feuilles multiples (images pour les données résidant sur les blocs) chacune identifiée par un nombre (par exemple 21654 ou 1320). Entre les deux, un cheminement par bifurcations (voire trifurcations) à partir de la racine, exactement comme les branches d'un arbre qui se subdivisent en rameaux etc. Cette cascade de bifurcations qui conduit de la racine aux feuilles est telle que, sur chaque point de bifurcation appelé un « nœud » réside une « clé » d'une valeur numérique donnée (par exemple 5638). Par rapport à la valeur de la clé, la branche qui mène en dernière instance à des feuilles terminales d'une valeur numérique supérieure, est la branche « haute », celle qui mène à de feuilles terminales d'une valeur numérique inférieure est la branche « basse ».

Toutes les données (feuilles) étant indexées a priori dans le répertoire du catalogue par une valeur numérique, ce qui permet à tout processus de recherche, de lecture, d'écriture ou de suppression d'atteindre une donnée déterminée est la valeur numérique de son index couplée à la structure logique B-tree par cascade de bifurcations à partir de clés numériques, une donnée d'une valeur 21654 (par exemple) impliquant automatiquement, à l'atteinte du nœud portant la clé 5638, que ce soit la branche « haute » qui soit suivie, et pas la branche « basse ». Par ce parcours en options binaires autour de chaque clé sur chaque nœud, tout processus trouve sa cible (la donnée ou feuille terminale).

Dans ce contexte que je t'ai brossé, une « erreur de nœud » signifie que la clé numérique a sauté sur un embranchement logique donné, ou qu'elle a une valeur aberrante => par voie de conséquence, toute l'arborescence qui part du nœud en branche « haute » ou « basse » est bloquée, car aucun processus ne peut dépasser le nœud erroné. Bref, tout un ensemble de données résidant sur les blocs de la partition n'est plus cherchable, atteignable, lisible, éditable ou supprimable. Ce qui suffit à invalider l'ensemble du fonctionnement dynamique du catalogue. Une erreur de « nœud » radicale est donc fatale, car le catalogue « B-tree » est invalidé et c'est un dysfonctionnement irréparable. Par suite, le système de fichiers gestionnaires ne peut plus assurer le montage en volume.

☞ Il n'y a qu'une issue connue à l'invalidation du « catalogue B-tree » : le reformatage de la partition (ce qui occasionne la perte de toutes les données antérieures - si on ne peut pas en récupérer par un logiciel de scan).

[Au cas où tu me trouverais bien loquace sur ce sujet, sache que les « erreurs de nœud » dans le « catalogue B-tree » ont été ma grande hantise depuis l'époque héroïque de Mac OS 9...]

♧​

 

[Typhuss]

Echec ! J'avais testé cette commande il y a quelques temps, avant de poster ce sujet.

Etrange : j'avais éjecté le disque et l'ai rebranché pour cette commande : le même problème que sous l'iMac est apparu, pas de disk1 => disk0 = DD interne et disk2 = DDE ! Mystère...

J'ai testé sur une clé et même résultat

??? Tu as réussi à reproduire le problème ?

 

[Deleted member 1099514]

Echec ! J'avais testé cette commande il y a quelques temps, avant de poster ce sujet.

Etrange : j'avais éjecté le disque et l'ai rebranché pour cette commande : le même problème que sous l'iMac est apparu, pas de disk1 => disk0 = DD interne et disk2 = DDE ! Mystère...


??? Tu as réussi à reproduire le problème ?

Non je parlais de testdisk qui ne sait à priori pas lire les données sur HFS+.
Tu peux tester avec une version démo de Stellar data Recovery : http://www.stellarinfo.com/mac-osx-recovery.php

 

[Typhuss]

☞ Il n'y a qu'une issue connue à l'invalidation du « catalogue B-tree » : le reformatage de la partition (ce qui occasionne la perte de toutes les données antérieures - si on ne peut pas en récupérer par un logiciel de scan).

Caramba ! c'est ce que je craignais (sans avoir préalablement la connaissance de la cause que tu expliques bien)

J'espère qu'avec la solution de jenjd63

version démo de Stellar data Recovery : http://www.stellarinfo.com/mac-osx-recovery.php

ca va me sauver quelques données.

J'ai par ailleurs l'impression, peut-être totalement infondée, que TimeMachine est un nid à problèmes : j'ai déjà perdu un disque en faisant une restauration depuis TM dont le process a planté le disque !
Et là c'est (encore) une partition qui héberge des données TimeMachine...
Je vais scruter de plus près les solutions CarbonCopy, SuperDuper ou ChronoSync.

Epilogue dans peu de temps désormais... Merci d'ores et déjà de toutes ces infos et de vos conseils.

 

[Membre supprimé 1060554]

Typhuss.

Concernant ton énigme (renommage d'une partition TM 2 d'un DDE A d'après l'intitulé d'une partition 1 d'un DDE B), je n'ai pas eu d'illumination intellectuelle entre temps.

Inutile d'invoquer des opérations magiques en coulisses : les événements qui concernent un Système informatique ont toujours une nature logique. Mais selon le beau titre de Stéphane Mallarmé : «Un coup de dés jamais n'abolira le hasard» => ce n'est pas parce que des événements ont une nature logique (et pas magique), qu'ils obéissent à un principe de « déterminisme » cohérent a priori. Ça, c'est l'idéal d'un Système non-contradictoire, proscrivant les indidents et les accidents. Mais comme le relevait le logicien Gödel à propos des mathématiques avec son théorème d'« inconsistance » : il est impossible de démontrer que le Système des mathématiques, au niveau de ses principes (axiomes), exclut entièrement la contradiction logique. Donc que des conséquences paradoxales ne puissent se produire logiquement. En d'autres termes (ceux de la « Théorie du Chaos ») : des événements accidentels se produisent toujours dans le fonctionnement d'un Système logique, parce que la contradiction ne peut être exclue du jeu de ses prémisses. Ça me paraît s'appliquer à un Système Informatique.​

L'« accident » dont tu as été victime était logiquement possible, puisqu'il s'est produit. Mais je n'ai aucune idée du concours de facteurs qui a suscité cette conséquence. Une chose est sûre : l'invalidation du catalogue B-tree rend le système de fichiers de la partition concernée irréparable.

=> As-tu réussi à récupérer des données par un logiciel de scan ? Je te signale l'existence d'un bon logiciel alternatif qui est ☞Data Rescue 4☜ (payant). Après ce type d'opération de récupération, je pense que tu es condamné au re-formatage pour restaurer ta partition...

 

[Typhuss]

Un premier scan via Stellar Phoenix Mac Data Recovery n'a pas donné grand chose. Le "advanced scan" a montré en revanche que la partition TM500 (qui porte plutôt le nom HIT1TO) avait pris la structure, les dossiers et les fichiers de la partition HIT1TO de l'autre DDE. Mais seulement une partie des données (70Go de données réellement présentes).
Ce scan a duré plus de 8 heures, et je n'ai pas encore analysé ce qu'il y a dans les dossiers qu'il appelle "lost folders" (il en a trouvé environ 250 000 ! )
Je crois bien qu'en effet je vais tout reformater, et me tourner vers des alternatives à TimeMachine.

Merci encore beaucoup a vous deux, macomaniax et jenjd63 !