Perte des type de partition lors de l'utilisation de clonezilla [URGENT]

Support Debian
#1

Bonjour,

j’ai un portable avec un disque nvme et un disque sata (512Go et 1To respectivement).
Sont installé dessus principalement windows 10 et une partition pour un debian
j’ai fait une image clonée de chacun des disques:

  • le nvme s’est bien passé
  • Le Sata a affiché une erreur MBR/GPT mais a cloné le disque.

Mais apparement Cllonezilla a provoqué quelque chose au niveau MBR/GPT qui fait que desormais toutes les partition sur le SATA sont considérées comme RAW. Les type de partition affichées par fdisk ou gdisk sont pourtant corrects.

A tout hasard j’ai lancé kl’installeur windows 10 qui lui au moment de choisir les partition voit clairement les types NTFS et autres des partitions.

Quelqu’un saurait-il comment je peux récupérer les informations de systèmes de fichiers qui ont disparues?

#2

Bonjour,

peut etre du coté de testdisk pour voir si tu peut recuprer tes fichiers mais Il faut demarrer depuis un livecd de type systemrescuecd

#3

Sur quel support de destination ?

Quelle erreur ?

Comment vois-tu que les partitions sont considérées comme RAW ? Qu’est-ce que ça signifie ?

On peut voir ? Et ajoute la sortie de

blkid /dev/sd*
file -s /dev/sd*
#4

Sur un disque externe

malheureusement il l’a affiché puis passé à la suite (j’étais en mode débutant), mais il semble que c’était en lien avec le MBR et le GPT qui coexistaient

RAW c’est quand aucun système de fichier (NTFS, ETX4 ou autre) n,e peut êrtre déterminé (c’est aussi parfois un mode d’écrire de donnée sous oracle).
C’est Windows qui m’a donné cette indication, sous Gparted il me dit non défini

je te donne ça dès que possible, car en attendant je suis en train de faire une récupération de fichier

#5

Normal puisque le MBR fait partie du format GPT (MBR protecteur). Tu veux dire une table DOS et une table GPT sur le même disque ? Cela peut arriver quand on crée volontairement un MBR « hybride » dans une table de partition GPT. gdisk peut le faire. Le résultat est intéressant : Windows voit la table DOS du MBR alors que Linux voit la table GPT. Cela peut aussi arriver quand on crée une table de partition DOS sur un disque qui a une table GPT avec un programme de partitionnement qui ne connaît pas le format GPT (donc qui n’efface pas la table GPT).

Quel était le format originel de la table de partition de ce disque ?

L’un n’empêche pas l’autre.

#6

Normalement GPT avec MBR protected.

/dev/sdd: PTUUID=« b034d8d1-0fa3-11eb-b071-fc7774673bef » PTTYPE=« gpt »

/dev/sdd: 
DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 "Invalid partition table" at offset 0x17b "Error loading operating system" at offset 0x19a "Missing operating system", 
disk signature 0x8c05e4b8; 
partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x0,32,32), startsector 1, 2047 sectors; 
partition 2 : ID=0x27, start-CHS (0x0,32,33), end-CHS (0x39,126,5), startsector 2048, 921600 sectors; 
partition 3 : ID=0xc, active, start-CHS (0x46,61,56), end-CHS (0x48,71,63), startsector 1128448, 32768 sectors; 
partition 4 : ID=0x7, start-CHS (0x48,72,1), end-CHS (0x3ff,254,63), startsector 1161216, 1952362496 sectors

Intéressant comme commande je ne connaissais pas. J’ai reformaté la sortie pour la lisibilité
Apparemment, j’ai du dire à Clonezilla de corriger le boot sector, ce qui a tout foutu en l’air.
En utilisant un programme sur Windows j’ai pu récupérer les fichiers, mais j’aurais autant aimé récupérer le disque fonctionnellement tel qu’il était.

#7

Ça ressemble à un MBR hybride (plusieurs partitions dont une de type ee=partition de protection GPT). Peux-tu montrer la sortie des commandes suivantes qui affichent la table de partition DOS du MBR et la table de partition GPT :

fdisk -lt dos /dev/sdd
fdisk -lt gpt /dev/sdd
#8 
fdisk -lt dos /dev/sdd
Disque /dev/sdd : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : 2115            
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x8c05e4b8

Périphérique Amorçage   Début        Fin   Secteurs  Taille Id Type
/dev/sdd1                   1       2047       2047 1023,5K ee GPT
/dev/sdd2                2048     923647     921600    450M 27 TFS WinRE masquée
/dev/sdd3    *        1128448    1161215      32768     16M  c W95 FAT32 (LBA)
/dev/sdd4             1161216 1953523711 1952362496    931G  7 HPFS/NTFS/exFAT

fdisk -lt gpt /dev/sdd
Disque /dev/sdd : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : 2115            
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : B034D8D1-0FA3-11EB-B071-FC7774673BEF

Périphérique   Début        Fin   Secteurs Taille Type
/dev/sdd1       2048     923647     921600   450M Environnement de récupération Windows
/dev/sdd2     923648    1128447     204800   100M Système EFI
/dev/sdd3    1128448    1161215      32768    16M Réservé Microsoft
/dev/sdd4    1161216 1953523711 1952362496   931G Données de base Microsoft
#9

Je connais mal toutes ces commandes, du coup je prends des notes :wink:

#10

En format texte préformaté avec les espacements pour que ce soit lisible stp.

#11

Comment ça? c’est ce que j’ai fait.
Sur quelle commande tu n’arrives pas à lire?

ok… je viens de voir l’intervention de MicP

#12

Merci @MicP pour son infatigable travail de fourmi sur la présentation des messages.

A l’exception de la partition EFI, la table DOS du MBR hybride et la table GPT sont cohérentes et contiennent les mêmes partitions aux mêmes positions. J’espérais qu’elles soient différentes et que l’une des deux contiennent les bonnes partitions mais ce n’est pas le cas. Je ne comprends pas ce qu’a pu faire clonezilla, pour moi il ne devrait pas modifier le contenu du disque source. En tout cas je pense que tu peux restaurer le MBR protecteur standard avec gdisk.

Pour le moment, mes seules hypothèses sont :

  • les deux tables de partitions sont fausses et les vraies partitions sont à d’autres emplacements ; il faut utiliser un outil comme testdisk ou gpart pour tenter de les retrouver.

  • la table de partition est correcte mais les signatures des systèmes de fichiers contenus das les partitions ont été effacées ; si les autres méta-données sont toujours présentes, on peut tenter de restaurer les signatures manuellement avec un éditeur hexadécimal ou avec les outils de réparation de ces systèmes de fichiers.

  • les superblocs entiers (méta-données) des systèmes de fichiers ont été effacés ; la seule option possible consiste à tenter de récupérer des fichiers par scan systématique du contenu du disque avec photorec, foremost ou équivalent.

  • tout le contenu des partitions a été effacé ; rien n’est récupérable.

PS : tu as regardé si tu pouvais récupérer quelque chose à partir de l’image faite par clonezilla ?

#13

Dans la partition principale, qui est celle qui est la plus importante, j’ai pu récupérer la totalité des fichiers. De fait, je serais bien tenté de reformatter le disque cloné, et d’y copier les données pour voir si je retrouve le fonctionement du système (en fait le système est sur le disque nvme, mais renvoie à des répertoire users sur le deuxième disque, ainsi que des applications installées sur le deuxième disque.

A priori, à part la partition 1 qui a un problème qet que Clonezilla n’arrive pas à cloner, c’est surtout un problème de MBR/GPT j’ai l’impression.

Pour les partitions elles sont bien au bon endroit (j’ai déjà vérifié avec gpart au départ)

Mais cette option est possible en effet, du coup j’ai récupéré tous les fichiers.

#14

Comment ?

Ce n’est pas mon impression puisque les deux tables sont globalement cohérentes entre elles.

#15

Avec un logiciel de récupération de fichiers, sous Windows: Minitool Partition Wizard

Ce serait quoi alors? étant donné que je peux récupérer les fichiers?
La première partition pose un problème part contre, Clonezilla ne peut pas la cloner, sans me dire de message d’erreur

#16

Connais pas. Qu’a-t-il faut exactement ? Il a rendu le contenu de la partition lisible à nouveau ou bien il a copié les fichiers récupérés sur un autre volume ? Dans le second cas, il a récupéré l’arborescence des répertoires et les noms des fichiers ou seulement le contenu des fichiers avec des noms aléatoires (comme le ferait photorec qui fonctionne par scan systématique des données) ?

Quelle première partition ? Celle de la table de partition DOS (type ee=protection GPT de 1 Mo) ou celle de la table de partition GPT (type environnement de récupération de 450 Mo, qui apparaît en second dans la table DOS) ? Si c’est la partition de protection GPT, c’est une partition factice qui ne contient rien. Mais dans tous les cas je ne vois pas pourquoi clonezilla ne pourrait pas cloner secteur par secteur une partition dont il ne connaît pas le format.

#17

Il a récupéré l’arborescence et les fichiers avec les noms d’origine.

Une partition marquée NTFS, je ne sais pas ce qu’il y avaitdedans de façon certaine. Reservée Windows d’après la clef d’installation Windows en NTFS.

#18

En relisant les messages, il y a un détail auquel je n’avais pas fait attention et qui me laisse perplexe. Les commandes blkid et file sur /dev/sd* n’ont pas affiché d’informations sur les partitions /dev/sdd{1…4} comme elles l’ont fait pour le disque /dev/sdd. Confirmes-tu ou avais-tu tronqué les sorties ? Si elles ne l’ont pas fait, cela voudrait dire que les partitions n’existent pas pour le noyau (alors que pour fdisk elles existent bien, mais fdisk se base sur sa propre lecture de la table de partition, pas sur celle du noyau).

#19

Je n’ai pas tronqué les sorties.

mais du coup, devant l’urgence, il est plus rapide maintenant pour moi de refaire le portable.
Pour le cas où, le disque impacté est toujours dispos car je l’ai remplacé (mis un SSD à la place d’un SATA). Donc on pourra toujours lui faire subir des manipulations :slight_smile: