Ddrescue, et après?

Signaler
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
-
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
-
Bonjour,

J'ai une carte SD de 16Go avec 2 partitions qui a planté (windows me propose un formatage).

J'ai lancé sous linux un ddrescue, j'ai un gros fichier de 16go (lorsque je l'édite avec un éditeur hexa j'ai des données dessus), mais je suis incapable d'exploiter ce fichier : je n'arrive pas à monter l'image.

Mes connaissances en hardware touchent leur limites, auriez-vous une aide à me donner svp?




Configuration: Windows / Firefox 70.0

5 réponses

Messages postés
35685
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
14 octobre 2020
5 533
Salut,
j'ai un gros fichier de 16go
Ce fichier a-t-il une extension ?
Que renvoie la commande
file ton_fichier
?

Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
19
Je n'ai pas cherché à ré-inventer l'eau chaude, j'ai suivi https://doc.ubuntu-fr.org/ddrescue : soit la commande


sudo ddrescue /dev/sdb2/ toto.img logToto


j'ai également essayé

sudo ddrescue -n /dev/sdb2/ toto2.img logToto2


Ensuite j'ai essayé de monter l'image, la dézipper, de faire "l'inverse" de ddrescue, mais je sèche : je ne comprend pas comment interpréter ce fichier toto.img.
J'ai récemment lancé un photorec directement sur la carte SD non montée, il me trouve bien 2 partitions, j'en ai pour 150h de traitement.... j’attends patiemment... Mais j'ai bien envie de lire ce fichu toto.img de 16Go!!! J'avais testé le photorec sur mon image, mais il ne trouve rien et n'a passé que 30mn dessus)

merci pour tes réponses
Messages postés
35685
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
14 octobre 2020
5 533 >
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020

Le problème c'est que ton image est vue comme "data" par file et non comme un système de fichiers.

Je viens de faire un test chez moi avec une carte SD de 4Go et voilà le résultat :

$ sudo ddrescue /dev/mmcblk0p2 rescue.img fichier.log -n
GNU ddrescue 1.22
ipos: 536805 kB, non-trimmed: 0 B, current rate: 13565 kB/s
opos: 536805 kB, non-scraped: 0 B, average rate: 17895 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 536870 kB, bad areas: 0, run time: 29s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished

$ ls
fichier.log rescue.img

$ file rescue.img
rescue.img: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (errors) (extents) (large files)


Avec ce résultat je peux monter le fichier et lire son contenu :
$ mkdir test

$ sudo mount -o loop rescue.img test/

$ ls test/
bin dev etc init lib lost+found mnt overlay proc recovery rom root sbin sys system tmp usr var www
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
19
Peut être le slash après la source qui fait défaut chez moi?
Est-ce abusé de te demander de faire ce test avec 2 partitions sur ta carte SD? je le ferais dans 120 heures au pire, en tout cas j'ai une piste à creuser...

En tout cas merci de ce temps consacré!! Photorec me reconnait une partition utilisée par android, j'ai encore de l'espoir... j'ai qu'un PC sous nunux, j'attends donc la fin du process pour lancer sans le slash en fin de source...

Merci!!
Messages postés
35685
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
14 octobre 2020
5 533 >
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020

$ sudo ddrescue /dev/mmcblk0 rescue.img fichier.log -n
GNU ddrescue 1.22
ipos: 3965 MB, non-trimmed: 0 B, current rate: 11993 kB/s
opos: 3965 MB, non-scraped: 0 B, average rate: 16521 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 3965 MB, bad areas: 0, run time: 3m 59s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished

$ ls
fichier.log rescue.img

$ file rescue.img
rescue.img: DOS/MBR boot sector; partition 1 : ID=0xc, start-CHS (0x8,0,33), end-CHS (0x210,1,1), startsector 2048, 131072 sectors; partition 2 : ID=0x83, start-CHS (0x218,1,34), end-CHS (0x259,1,37), startsector 135168, 1048576 sectors


$ sudo kpartx -a -v rescue.img 
add map loop0p1 (253:0): 0 131072 linear 7:0 2048
add map loop0p2 (253:1): 0 1048576 linear 7:0 135168

$ mkdir -v loop{1,2}
mkdir: création du répertoire 'loop1'
mkdir: création du répertoire 'loop2'

$ ls
fichier.log loop1 loop2 rescue.img


$ sudo mount -v /dev/mapper/loop0p1 loop1
mount : /dev/mapper/loop0p1 monté sur /home/jp/Téléchargements/ISO/rescue/loop1.

$ sudo mount -v /dev/mapper/loop0p2 loop2
mount : /dev/mapper/loop0p2 monté sur /home/jp/Téléchargements/ISO/rescue/loop2.

$ ls loop1/
mac_addr uEnv.txt uImage

$ ls loop2/
bin dev etc init lib lost+found mnt overlay proc recovery rom root sbin sys system tmp usr var www
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
19
bon, bin j'ai plus qu'à bosser, je te tiens au courant.

merci beaucoup pour ces infos!!!!!

bonne soirée
Erwan
Messages postés
373
Date d'inscription
vendredi 1 mai 2009
Statut
Membre
Dernière intervention
8 novembre 2019
21
Bonjour,
Je n'ai jamais fait de récupération de données. Je sous-entends cela parce que https://www.gnu.org/software/ddrescue/ddrescue_fr.html
Néanmoins, pour augmenter les chances de récupération de données sur un support de stockage, il faut éviter d'écrire dessus car une nouvelle écriture pourrait prendre la place d'un emplacement écrit, par conséquent, cet emplacement sera encore plus difficile, voire impossible, à récupérer.
Je te propose de lire le lien que je t'ai donnée, puis la documentation qui est sous forme de lien à l'intérieur.
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
19
Bonjour,

j'ai trouvé équivalent en français sur https://doc.ubuntu-fr.org/ddrescue , j'ai mon image finale, je suis content, mais n'arrive pas à l'exploiter!!
ils expliquent comment faire l'image, mais une fois le fichier image obtenu, je cherche à récupérer les données qui sont dessus! :)
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
19
En tout cs merci pour vos réponses :)
Messages postés
1
Date d'inscription
mardi 9 août 2011
Statut
Membre
Dernière intervention
30 avril 2020

Est-ce que la solution a été trouvée finalement ?
Sinon, est-ce que ce fichier image a été conservé ?

Il est certes toujours sage de faire une image avant de procéder à la (tentative de) récupération proprement dite (c'est à dire la détection puis l'extraction des fichiers individuels), mais c'est surtout utile s'agissant d'un support physiquement endommagé, par exemple un disque dur présentant des secteurs défectueux. Une carte mémoire dont le contenu n'est plus accessible, c'est généralement une panne dite “logique”, pouvant correspondre à une corruption du système de fichiers (méta-données permettant au système d'exploitation d'identifier les informations d'allocation, le nom, les horodatages et attributs de chaque fichier). Un bon logiciel de récupération de données comme R-Studio parvient à lire le contenu d'une partition dont le système de fichiers a été modérément corrompu. En cas de corruption sévère, on en est réduit à extraire les données par la méthode “raw file carving”, qui consiste à détecter les “signatures” de fichiers connus (suite de caractères spécifique trouvée au début ou à la fin de chaque type de fichier) et à extraire ce qui suit, soit jusqu'à un indicateur spécifique de fin de fichier, soit jusqu'au début du fichier suivant. Ça marche très bien si les fichiers sont d'un seul bloc (à ceci près qu'on perd les noms, les horodatages, et la structure des dossiers / sous-dossiers), mais en cas de fragmentation le résultat peut être très mauvais (fichiers tronqués et illisibles). Sur une carte mémoire d'appareil photo / vidéo, si on efface régulièrement les anciens fichiers après sauvegarde, les nouveaux sont généralement écrits de façon contiguë, donc sans fragmentation, dans ce cas cette méthode marche bien, faute de mieux.

Maintenant, pour ouvrir un fichier image, si celui-ci ne peut être monté (ça peut être le cas si le secteur de démarrage est corrompu, même si le système de fichiers est par ailleurs intact), on peut utiliser :
– soit Photorec => Dans une invite de commande, taper “photorec_win.exe [nom de l'image]” (d'abord accéder au répertoire où se trouve photorec_win.exe ou ajouter le chemin complet à la commande / mettre le nom de l'image entre guillemets si celui-ci comporte des espaces) ; ou alors, autre méthode, faire un clic droit sur le fichier image, puis pointer sur “ouvrir avec”, puis cliquer sur “choisir le programme par défaut” (sous Windows 7), puis rechercher le dossier où se trouve Photorec, puis cliquer sur l'exécutable photorec_win.exe (avec cette méthode l'extension que porte le fichier image sera désormais associée par défaut à Photorec, ce qui peut être un avantage ou un inconvénient). Photorec ne permet que la méthode brute ou “raw file carving”, et à moins de spécifier le contraire, analyse l'intégralité du support, extrayant au fur et à mesure tout ce qui est identifié comme un type de fichier connu et activé dans les paramètres. Il est préférable pour améliorer le résultat de n'activer dans les paramètres que les fichiers censés se trouver sur le support et désactiver tous les autres, sinon on peut obtenir de faux fichiers (par exemple le logiciel peut détecter une fausse signature de fichier MP3 présente par hasard à l'intérieur d'un fichier vidéo MP4, et extraire ce qui suit comme si c'était un fichier audio MP3, mais le fichier ainsi extrait sera bien évidemment illisible, et pire, l'extraction du fichier MP4 sera interrompue à cet endroit, même si le fichier était encore présent en intégralité sur le support et contigü / non fragmenté).
– soit TestDisk, logiciel compagnon de Photorec => Même méthode pour ouvrir l'image, ensuite voir le manuel pour rechercher les partitions, lister et extraire le contenu.
– soit R-Studio => Cliquer sur “Open image”, ou encore plus simple, faire un glisser-déposer du fichier image vers la liste des supports détectés, le fichier image sera alors ajouté à la fin à la rubrique “Image files” ; ensuite pour l'analyser, cliquer sur “Drive” puis “Scan” puis valider et attendre la fin de l'analyse. Si on a de la chance, le contenu est détecté par la méthode basée sur le système de fichiers, donc avec la structure d'origine, les noms, les horodatages, etc. ; sinon, si le système de fichiers est sévèrement corrompu, on a quand même une liste de fichiers détectés par méthode “raw file carving” classés par type dans un dossier virtuel appelé “Extra found files” (même chose que pour Photorec, il est préférable de désactiver les types de fichiers autres que ceux recherchés) ; si rien n'est trouvé même là, c'est que le support était très sévèrement endommagé.
– WinHex peut aussi ouvrir des images de volumes, en afficher et extraire le contenu, même si ce n'est pas un logiciel de récupération dédié.
(Procédures décrites sous Windows, à adapter le cas échéant si un autre système est utilisé. Photorec existe sous Linux, R-Studio aussi, mais pas WinHex.)

Hope it helps...
Messages postés
295
Date d'inscription
samedi 20 janvier 2007
Statut
Membre
Dernière intervention
18 août 2020
19
Bonsoir,

ce n'est pas résolu, j'ai toujours mon fichier image de 16go que je regarde en espérant trouver une solution... photorec ne trouve rien, il faut que je teste Rstudio, je ne connaissais pas, merci!