Discussion :

[xounet]

Bonjour,
Suite à un problème de firmware d'un disque dur (1 To) devenu inaccessible, j'ai été contraint de sauver la partition accessible sous windows sous forme d'image disque bit à bit (cette image "image.dsk" a été stockée sur un disque formaté ntfs). Après des recherches approfondies (je passe les détails), j'ai identifié cette image "image.dsk" comme étant des données (fichiers) d'une partition du disque d'origine (il y en avait plusieurs) formatée xfs.
Or cette image aujourd'hui n'est pas reconnue ni par testdisk (la table de partition est bourrée d'erreurs et semble fausse) ni par losetup, comme étant une partition xfs, xfs repair ne donne rien et il n'est pas possible de la monter comme une partition xfs "mount -t xfs ..." indique qu'il ne reconnaît pas le format xfs. Cependant je sais qu'en grande partie cette image est valide : taille conforme à la taille d'origine de formatage de la partition, des fichiers sont toujours lisibles dessus en essayant une récupération de données par exemple, mais l'arborescence est détruite en grande partie.
Je ne comprends donc pas le problème. Comment rendre cette image accessible sous linux (ou éventuellement windows) et pouvoir visualiser les fichiers qui sont dessus ?

testdisk propose d'ouvrir des images disque/partition comme un disque non partitionné et de faire une copie sous forme d'image en tant que partion xfs est ce que cela peut marcher (cela est très long) ?
Faut il recopier l'image complète sur une nouvelle partition xfs créée sur un autre disque dur (1To) à l'aide de gparted + commande dd par exemple ?
Plutôt que de recopier l'image disque n'y a t il pas un moyen sous linux de créer une partition xfs de 1To et de faire un lien virtuel entre cette partition et les données qui sont lues directement à partir de "image.dsk".

Merci d'avance pour vos conseils.

[disedorgue]

Bonjour,

Et pourquoi ne pas faire un loop directement du disque (losetup) et ensuite monter ta partition au lieu d'extraire la partition et d'essayer de la monter ?

Autre question, est-ce que ta partition ne serait pas une partition étendue et non primaire ?

[xounet]

Merci pour ce retour.

j'ai essayé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
sudo losetup /dev/loop2 /media/sdg1/image.dsk
sudo mount -t xfs /dev/loop2

et j'ai le message d'erreur

mount : /dev/loop2 : can't find in /etc/fstab

La partition en question (image.dsk) était à l'origine une sous partition logique (je pense) xfs filesystem d'une partition étendue. Maintenant le fichier image ne contient que la partition logique xfs (je l'ai déduit en comparant la taille en octets sur le disque d'origine et sur l'image clone du disque qui est identique).
A quel endroit sont enregistrées les tables des partitions, et système de fichiers au tout début du disque il me semble ? Donc mon fichier image ne devrait contenir aucune information concernant la partition en elle même, mais uniquement des données binaires de fichiers ?

[disedorgue]

Euh, le message d'erreur que tu as, c'est parce qu'il ne trouve pas de référence à /dev/loop2 dans /etc/fstab et il ne sait donc pas où le monter...

Tu dois préciser le répertoire où tu veux monter le /dev/loop2

Après, je ne dis pas que ça résoudra le problème, mais au moins on aura un message d'erreur plus spécifique.

PS: Tu n'as pas besoin de modifier /etc/fstab

[xounet]

Effectivement, je suis allé un peu vite et j'ai oublié de spécifier l'adresse du montage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo mount -t xfs /dev/loop2 /mnt

Ne pratiquant pas souvent cela, je me suis inspiré d'exemples trouvés sur internet.

le message indique que le système de fichiers n'est pas bon :

wrong fs type, bad option, bad superblock on /dev/loop2, missing codepage or helper, or other erroe

Cela ne m'avance pas beaucoup et précédemment j'avais déjà essayé un xfs_repair, qui ne fait rien du tout...

[disedorgue]

Peux tu essayer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fdisk -l /dev/loop2

Pour voir si cela donne quelque chose...

[xounet]

Voici le resultat .

root@Microknoppix:~# sudo fdisk -l /dev/loop2
Disk /dev/loop2: 923.9 GiB, 992009862144 bytes, 1937519262 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x153d393a

Device Boot Start End Sectors Size Id Type
/dev/loop2p1 3965490019 5095136038 1129646020 538.7G 58 unknown
/dev/loop2p2 554033320 4113299557 3559266238 1.7T 60 unknown
/dev/loop2p3 1147763733 5079542493 3931778761 1.9T af HFS / HFS+
/dev/loop2p4 3955404780 8038961577 4083556798 1.9T 4 FAT16 <32M

Partition table entries are not in disk order.

[xounet]

Je me réponds :
le résultat est inutilisable, ce qui confirme à mon avis que cette image raw ne contient aucune description de partition.

[xounet]

J ai essaye la solution de creation d image disque sous testdisk maid j ai l impression que cela ne fonctionne pas car testdisk ne trouve aucune partition xfs sur l image cree alors que je viens de specifier que le disque etait sans partition et qu il fallait en cree une image de partition en xfs est ce un bug ou j ai rien compris aux menus testdisk ?

[chrtophe]

accéder à /dev/loop2 sera l'équivalent de /dev/sda. Il faut ensuite préciser la partition à monter
exemple /dev/loop2p1

Essayes avec Photorec

[xounet]

Est ce que avant de "monter" la partition je peux lui appliquer un système de fichier sans formater ou écraser les données de l'image source en faisant par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mkfs.xfs  /dev/loop2

suivi par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo mount /dev/loop2 /mnt

?

[disedorgue]

Non, si tu fais ça, c'est comme un formatage.

Si on en croit le fdisk, tu as un disk avec dessus 4 partitions, dont 2 de type inconnu, une au format fat16 et une au format macos, mais aucune au format xfs.

As-tu essayé la suggestion de chrtophe en essayant de monter l'un des loop2pX (éventuellement sans spécifier le type xfs) ?

pour changer le type d'une partition, il faut voir du coté de fdisk mais tu feras pire que mieux (donc travail sur une copie)

[xounet]

je n'arrive pas à monter les partitions loop2px, j'ai un message d'erreur.
A l'origine, l'image raw correspond à une seule partition xfs se trouvant dans une partition étendue, ces 4 partitions trouvées par fdisk ne correspondent à rien du tout, il y a une corruption de données quelques part à mon avis.
Je crois bien que le plus simple dans mon cas, pour accéder dans les meilleurs conditions à cette partition raw serait de la restaurer physiquement à son emplacement d'origine : ci dessous la structure du disque dur physique d'origine :
Partition Start End Size in sectors

1 * Linux 0 1 1 124 254 63 2008062
2 P Linux 125 0 1 747 254 63 10008495
3 E extended LBA 748 0 1 121477 254 63 1939527450
5 L Linux Swap 748 1 1 872 254 63 2008062
6 L Linux 873 1 1 121477 254 63 1937519262
On retrouve l'emplacement d'origine à la partition 6 qui est bien une partition logique xfs d'après gparted.
après montage de la partition 6 du disque physique, la commande du type :
dd if=/dev/sdaX of=/path/to/image.dsk bs=512 count=1937519262
doit permettre de restaurer les données de l'image raw dans cette partition.

[Jipété]

je n'arrive pas à monter les partitions loop2px, j'ai un message d'erreur.

Ah...

[...] doit permettre de restaurer les données de l'image raw dans cette partition.

et si jamais les données de l'image raw sont en vrac, tu vas remplir cette partition avec n'importe quoi.
Tu n'as pas une sauvegarde de ce disque/cette partition ?

Je prends le train en marche, mais si ces données t'importent, sors la monnaie, il existe des sociétés spécialisées dans la récupération, ça coûte cher mais c'est souvent efficace.
Là tu ne sais pas où tu vas, et nous non plus ; eux, c'est leur métier.

Mais si vraiment ça te démange, tente de restaurer les données raw sur un autre disque (externe, par exemple) pour voir si tu récupères des données valides.

[disedorgue]

je n'arrive pas à monter les partitions loop2px, j'ai un message d'erreur.
A l'origine, l'image raw correspond à une seule partition xfs se trouvant dans une partition étendue, ces 4 partitions trouvées par fdisk ne correspondent à rien du tout, il y a une corruption de données quelques part à mon avis.
Je crois bien que le plus simple dans mon cas, pour accéder dans les meilleurs conditions à cette partition raw serait de la restaurer physiquement à son emplacement d'origine : ci dessous la structure du disque dur physique d'origine :
Partition Start End Size in sectors

1 * Linux 0 1 1 124 254 63 2008062
2 P Linux 125 0 1 747 254 63 10008495
3 E extended LBA 748 0 1 121477 254 63 1939527450
5 L Linux Swap 748 1 1 872 254 63 2008062
6 L Linux 873 1 1 121477 254 63 1937519262
On retrouve l'emplacement d'origine à la partition 6 qui est bien une partition logique xfs d'après gparted.
après montage de la partition 6 du disque physique, la commande du type :
dd if=/dev/sdaX of=/path/to/image.dsk bs=512 count=1937519262
doit permettre de restaurer les données de l'image raw dans cette partition.

Et donc, qu'est-ce qui ne fonctionne pas dans cette action ?

Car comme le dit Jipété, on a du mal à raccrocher les wagons.

[xounet]

Ce qui ne fonctionnait pas c'est que les partitions n'étaient pas dans les "device" donc /dev/loop2p2 n'existait pas et dans tous les cas au final j'ai toujours le même message d'erreur indiquant

wrong fs type, bad option, bad superblock on /dev/loop2, missing codepage or helper, or other erroe

J'ai essayé avec un live CD la distrib ubuntu 16.0.4 qui a l'application gnome_disk_image_mounter, mais rien à faire linux n'arrive pas à monter cette image de partition même message d'erreur.

En fait je recentre le débat sur le réel problème qui est soulevé dans cette manipulation :
peu importe les données qui sont dans cette image au final qu'elles soient nulles, corrompues ou autre le problème est plus fondamental que cela, je n'arrive pas à monter cette image dont je connais précisément la structure (filesystem, blocs, size), le problème vient donc dans l'interprétation de linux pour lire cette image raw et rien d'autre, je pensais que cela pouvait être réalisé assez facilement manuellement (raz de la table de partitions avec des valeurs saisies manuellement) mais visiblement on a bien du mal à trouver comment faire ceci...

Concernant la récupération de données ni les spécialistes ni les logiciels ne garantissent quoi que ce soit et globalement ils ne s'engagent que sur la récupération de fichiers en "vrac" lorsque le disque n'est pas trop abimé, ce que j'ai déjà essayé et qui n'est pas satisfaisant.

[chrtophe]

le problème vient donc dans l'interprétation de linux pour lire cette image raw et rien d'autre

Que les données soient dans une image ou une partition réelle, si la structure du FS est trop endommagée, la réparation de celui-ci est impossible, reste la tentative de récupération de ce qui peut l'être, recherche des structures de FS, parcours de tous les secteurs à la recherche d'en-tête de fichiers reconnaissables, ce que fera un utilitaire de récupération avec plus ou moins de résultat.

Le résultat de fdisk -l /dev/loop2, visible au post 7 démontre qu'une table de partitions est visible, mais aussi qu'elle n'est pas cohérente, 1 partition de 500Go, 1 de 1,7To et 2 de 1,9To sur 1 disque de 1To

As-tu fais des modifs dans le fichier image ?

Tu parles de prob. de firmware, sans plus d'info il se peut aussi que ta copie d'image ne soit pas viable, mais on voit quand même une table de partition (même si elle est erronée).

[xounet]

Merci pour la réponse.
Oui le disque dur installé et configuré dans un NAS est devenu totalement inutilisable car il y a avait un bug sur le firmware du disque dur nécessitant une réinstallation manuelle du firmware via les connecteurs à plusieurs broches... bref le disque s'est remis à fonctionner après mise à jour (celui ci ne donnait plus aucun signe de vie j'ai cru qu'il y a avait une grosse panne physique type PCB ou tete de lecture HS), avant de le réinstaller sur le NAS j'ai fait une image de la partition qui apparaissait en RAW sous windows (linux ne voyait rien du tout à l'époque c'était finalement plus complexe que sous windows). C'est la seule chose que j'ai pu faire car testdisk ne donnait pas de résultats concluants. Rien n'a été fait sur ce disque en terme d'écriture (au pire mais je ne m'en souviens pas j'aurai peut être tenté de réécrire le MBR, mais ceci n'efface pas les données du disque donc pas irréversible). A l'époque j'ai fait une récupération brute des fichiers directement depuis le disque, mais beaucoup de répertoires sont mélangés donc pas satisfaisant pour 50% des dossiers.
Ayant une image disque complète (923 GB) j'ai réinstallé le NAS avec ce même disque dur qui tourne encore aujourd'hui et c'est en examinant la structure du DD une fois installé que j'ai compris à quoi correspondait exactement l'image RAW que j'ai faite (1 partition XFS).
Voilà l'histoire de cette image dans les grandes lignes, pour ceux qui pensent que cela peut être utile savoir tout cela ou qui pensent que je conclus un peu vite...

[chrtophe]

Si le disque provient d'un NAS, il peut y avoir une surcouche RAID ou LVM (en encapsulation), à moins qu'XFS intègre cela, je ne connais pas bien ce FS. Cela complexifie donc la structure et l'accès aux partitions.

Si tu as remonté le disque dans le NAS, celui-ci a aussi pu toucher au disque par rapport à ma phrase précédente.

Ces spéculations ne sont pas à prendre en compte si tu as fait l'image avant de remonter le disque dans le NAS.

[xounet]

Je viens de faire la restauration de l'image sur la partition du disque dur d'origine, tout s'est bien passé pendant la copie. Après reboot, je trouve bien le disque dur, les partitions, mais la partition qui m'intéresse reste inaccessible avec le même message d'erreur. Par contre je ne sais pas pourquoi testdisk trouve deux fois la partition 6 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
1 * Linux 0 1 1 124 254 63 2008062
2 P Linux 125 0 1 747 254 63 10008495
3 E extended LBA 748 0 1 121477 254 63 1939527450
5 L Linux Swap 748 1 1 872 254 63 2008062

no ext2, JFS, Reiser, cramfs or xfs marker
6 L Linux 873 1 1 121477 254 63 1937519262
6 L Linux 873 1 1 121477 254 63 1937519262

J'ai fait une image du 1er giga de la partition 6 saine (mais dont les données sont différentes) en espérant que cela pourrait débloquer quelque chose, visiblement des données en début de partitions sont nécessaires pour lire correctement la partition. Savez vous qu'elles sont ces données stockées sur ces premiers octets d'une partition xfs ? Combien faudrait il que j'en restaure pour que cette partition soit "montable" ? pourquoi à votre avis testdisk trouve deux fois la partition 6 ?