[Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

Moimemeici · Le 07/10/2010, à 23:36

voici le lien
http://www.r-tt.com/fr/data_recovery_linux/

rmy · Le 08/10/2010, à 00:16

merci je regarde ça demain.

Bilan téléphone : 2.6Go écrasés par le dev/zero
r_linux donne un résultat partiel (voir réglages) mais donne aussi d'autres valeurs de sb (à vérifier au besoin pour un mount ou un fsck qui aurait besoin de sb valides)

chopinhauer · Le 08/10/2010, à 00:29

rmy a écrit :

Bilan téléphone : 2.6Go écrasés par le dev/zero

Enfin, entre 8.000.000 kio et 12.000.000 kio à croire le dernier message (4 * 3.000.000 kio c'est Ok).

Moimemeici: T'es sur de vouloir utiliser un logiciel assez inconnu sur tes données, qui ne donne pas de code source et tourne uniquement sous Windows? e2fsck et testdisk ne sont pas mal du tout.

rmy · Le 08/10/2010, à 00:37

chopinhauer a écrit :

rmy a écrit :
Bilan téléphone : 2.6Go écrasés par le dev/zero
Enfin, entre 8.000.000 kio et 12.000.000 kio à croire le dernier message (4 * 3.000.000 kio c'est Ok).
Moimemeici: T'es sur de vouloir utiliser un logiciel assez inconnu sur tes données, qui ne donne pas de code source et tourne uniquement sous Windows? e2fsck et testdisk ne sont pas mal du tout.

oui, j'avais pas vu que tu étais repassé avec un bs=4096 entre temps…
donc à priori les 10Gio y sont passés.

@chopinhauer : e2fsck ne doit-il pas recevoir un bs valide pour fonctionner correctement ? L'intérêt que je trouve pour l'instant à r-linux dans ce cas, c'est qu'à priori il lui retrouve des données, et lui donne d'autres valeurs que dumpe2fs pour les adresses des blocs. J'ai marqué à vérifier, car il s'agit peut-être d'une simple différence d'unité.
Ensuite, dans sa situation, si on arrive à rien avec testdisk et e2fsck, pourquoi pas r-linux puisqu'il aura une image de backup de son état initial. Il n'y a pas grand chose à risquer…

D'ailleurs, en parlant de testdisk, tu penses à nous donner un retour là-dessus ?

edit : réponse à une question que je me posais…

man e2fsck a écrit :

Normally, e2fsck will search for the superblock at various dif‐
ferent block sizes in an attempt to find the appropriate block
size.

man dumpe2fs a écrit :

-o superblock=superblock
use the block superblock when examining the filesystem. This
option is not usually needed except by a filesystem wizard who
is examining the remains of a very badly corrupted filesystem.

Dernière modification par rmy (Le 08/10/2010, à 00:49)

Moimemeici · Le 08/10/2010, à 01:11

Oui pardon l'habitude de tapé 4096 donc j'ai rectifié avec 1024 et j'ai cherché jusqu'où il n'y avait que du "zéro"
ca donne : 9859375

[root@engrenage ~]# dd if=/dev/md5 count=1 bs=1024 skip=9859375 | hexdump -C
1+0 enregistrements lus
1+0 enregistrements Ã©crits
1024 octets (1,0 kB) copiÃ©s, 2,8984e-05 s, 35,3 MB/s
00000000  33 64 30 39 32 32 37 33  35 31 34 64 34 61 32 63  |3d092273514d4a2c|
00000010  34 37 33 35 31 37 37 34  39 34 33 39 65 33 36 65  |473517749439e36e|
00000020  64 33 30 38 35 30 30 61  31 31 38 31 31 63 37 35  |d308500a11811c75|
00000030  35 66 32 39 65 65 63 64  30 66 32 64 37 64 63 0d  |5f29eecd0f2d7dc.|
00000040  0a 66 61 66 61 38 65 61  62 36 65 66 38 63 39 62  |.fafa8eab6ef8c9b|
00000050  66 36 61 66 36 64 66 39  38 36 36 39 35 64 63 61  |f6af6df986695dca|
00000060  66 65 33 64 38 34 32 64  61 39 37 35 64 61 36 33  |fe3d842da975da63|
00000070  38 32 64 36 64 36 31 33  62 36 34 62 39 38 62 37  |82d6d613b64b98b7|
00000080  32 38 61 64 65 66 64 64  31 36 33 33 34 30 32 61  |28adefdd1633402a|
00000090  33 31 31 31 38 38 64 63  30 36 38 30 34 37 65 35  |311188dc068047e5|
000000a0  30 34 36 36 30 33 38 31  62 33 36 39 63 63 37 38  |04660381b369cc78|
000000b0  30 64 39 64 37 61 64 34  39 37 66 36 65 37 39 66  |0d9d7ad497f6e79f|
000000c0  34 0d 0a 35 66 64 39 66  63 38 36 61 31 30 33 63  |4..5fd9fc86a103c|
000000d0  30 37 64 31 39 65 36 32  30 36 64 64 39 33 65 38  |07d19e6206dd93e8|
000000e0  61 63 66 30 66 37 31 39  30 38 30 66 31 36 62 34  |acf0f719080f16b4|
000000f0  62 39 38 30 33 61 35 30  33 32 31 33 62 36 38 39  |b9803a503213b689|
00000100  36 34 62 37 37 34 36 66  39 35 35 30 65 32 65 31  |64b7746f9550e2e1|
00000110  39 64 30 31 32 31 64 35  32 62 63 36 64 33 38 35  |9d0121d52bc6d385|
00000120  37 63 33 66 37 39 34 66  62 35 34 31 31 64 64 61  |7c3f794fb5411dda|
00000130  38 65 62 61 32 65 66 32  64 37 36 62 36 66 32 33  |8eba2ef2d76b6f23|
00000140  64 39 62 0d 0a 37 36 62  34 37 65 38 36 34 37 65  |d9b..76b47e8647e|
00000150  32 63 63 34 64 61 31 38  61 31 36 30 65 38 36 38  |2cc4da18a160e868|
00000160  37 34 31 34 31 31 63 39  61 37 30 32 38 38 36 36  |741411c9a7028866|
00000170  38 31 62 64 39 61 35 31  66 39 34 63 39 62 33 62  |81bd9a51f94c9b3b|
00000180  64 65 62 65 38 66 62 39  30 63 35 63 37 62 36 61  |debe8fb90c5c7b6a|
00000190  34 63 64 35 65 36 65 38  61 36 64 65 66 34 62 32  |4cd5e6e8a6def4b2|
000001a0  65 64 62 62 62 38 37 36  61 65 61 33 61 31 66 30  |edbbb876aea3a1f0|
000001b0  37 63 39 64 35 39 37 66  39 63 65 63 64 65 31 66  |7c9d597f9cecde1f|
000001c0  30 61 62 39 65 0d 0a 39  38 32 63 33 34 32 34 63  |0ab9e..982c3424c|
000001d0  66 63 62 66 39 33 34 66  38 62 38 63 63 37 39 34  |fcbf934f8b8cc794|
000001e0  63 63 30 62 36 38 39 65  37 63 63 66 63 37 37 39  |cc0b689e7ccfc779|
000001f0  36 38 65 37 66 36 31 66  31 63 34 30 33 64 33 35  |68e7f61f1c403d35|
00000200  65 35 61 62 33 32 33 32  37 38 64 65 30 31 36 62  |e5ab323278de016b|
00000210  61 66 30 35 31 32 31 31  66 36 30 32 61 30 39 62  |af051211f602a09b|
00000220  38 34 37 31 32 37 39 34  33 62 65 62 38 30 38 61  |847127943beb808a|
00000230  66 65 31 39 38 30 32 39  38 63 65 33 33 35 36 36  |fe1980298ce33566|
00000240  63 35 66 39 31 39 39 0d  0a 36 34 63 61 35 62 31  |c5f9199..64ca5b1|
00000250  32 31 61 65 32 65 32 63  62 37 37 36 39 32 62 61  |21ae2e2cb77692ba|
00000260  34 32 32 32 31 38 30 64  37 32 30 32 30 30 38 65  |4222180d7202008e|
00000270  32 33 63 64 37 38 38 32  61 65 30 38 61 61 33 34  |23cd7882ae08aa34|
00000280  38 35 64 36 37 36 31 63  66 30 33 64 61 38 36 34  |85d6761cf03da864|
00000290  38 34 32 30 61 37 36 32  38 32 63 65 34 63 38 38  |8420a76282ce4c88|
000002a0  66 35 33 37 38 64 38 34  31 66 64 32 30 38 37 37  |f5378d841fd20877|
000002b0  32 33 35 31 63 36 30 32  63 36 30 37 61 39 35 63  |2351c602c607a95c|
000002c0  38 61 32 30 30 31 35 36  38 0d 0a 37 63 33 37 66  |8a2001568..7c37f|
000002d0  33 65 61 63 62 36 31 64  30 63 61 37 37 65 65 33  |3eacb61d0ca77ee3|
000002e0  65 66 38 61 65 39 64 65  38 38 39 62 34 31 33 64  |ef8ae9de889b413d|
000002f0  38 62 65 35 61 38 31 34  31 31 34 36 34 36 31 62  |8be5a8141146461b|
00000300  31 64 32 62 37 36 36 35  33 32 35 30 30 65 31 32  |1d2b766532500e12|
00000310  61 31 33 36 66 39 61 65  38 62 34 38 32 38 33 32  |a136f9ae8b482832|
00000320  34 33 63 32 64 30 61 62  64 65 35 63 62 32 66 33  |43c2d0abde5cb2f3|
00000330  63 66 65 63 35 64 66 62  64 65 64 64 64 31 66 33  |cfec5dfbdeddd1f3|
00000340  33 37 62 33 66 30 32 33  30 31 34 0d 0a 32 61 39  |37b3f023014..2a9|
00000350  35 35 34 36 62 33 36 63  31 32 38 39 66 66 30 61  |5546b36c1289ff0a|
00000360  61 39 33 36 65 66 34 38  36 64 31 30 38 66 63 32  |a936ef486d108fc2|
00000370  30 38 63 34 30 62 39 30  62 31 33 65 39 32 36 30  |08c40b90b13e9260|
00000380  65 30 30 66 65 34 66 65  30 32 37 32 33 36 39 34  |e00fe4fe02723694|
00000390  39 33 39 36 61 34 61 39  35 63 63 34 63 34 36 62  |9396a4a95cc4c46b|
000003a0  64 32 34 64 65 61 34 31  62 32 36 39 61 33 33 61  |d24dea41b269a33a|
000003b0  37 31 66 39 62 37 62 65  36 65 62 62 64 38 35 61  |71f9b7be6ebbd85a|
000003c0  37 63 36 64 64 37 36 64  64 36 33 39 37 0d 0a 36  |7c6dd76dd6397..6|
000003d0  33 66 34 33 65 30 32 32  38 30 30 33 35 35 30 66  |3f43e0228003550f|
000003e0  36 32 38 34 36 64 34 63  65 38 65 36 66 61 30 30  |62846d4ce8e6fa00|
000003f0  66 61 30 64 62 30 38 65  61 61 61 30 30 34 31 38  |fa0db08eaaa00418|
00000400

@chopinhauer : je ne fais pas confiance a ce type de logiciel, mais je croise les données vu que je n'y connais pas grand chose sur le sujet

Voici ce que me trouve testdisk comme superblock

     Partition                  Start        End    Size in sectors

  ext4                     0   0  1 1098851951   1  4 8790815616 [fichier]
superblock 0, blocksize=4096 [fichier]
superblock 32768, blocksize=4096 [fichier]
superblock 98304, blocksize=4096 [fichier]
superblock 163840, blocksize=4096 [fichier]
superblock 229376, blocksize=4096 [fichier]
superblock 294912, blocksize=4096 [fichier]
superblock 819200, blocksize=4096 [fichier]
superblock 884736, blocksize=4096 [fichier]
superblock 1605632, blocksize=4096 [fichier]
superblock 2654208, blocksize=4096 [fichier]

To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device

Dernière modification par Moimemeici (Le 08/10/2010, à 01:39)

Moimemeici · Le 08/10/2010, à 12:10

L'image est bientôt fini (c'est pas trop tôt)
Bientôt les choses vont commencer.

Voila l'image est fini !

Dernière modification par Moimemeici (Le 08/10/2010, à 13:49)

Moimemeici · Le 08/10/2010, à 13:57

bon j'ai commencé par faire un :

mkfs.ext4 -n /media/secours/image.dd |sed -n '11,15p'

comme stupilé sur le blog de cep, ca l'air long, il ne m'a pas encore donnée la main.

rmy · Le 08/10/2010, à 14:37

oui, presque aussi long que si tu créais un FS ext4 sur tes 4.5To, laisse le faire.

Heu, je viens de vérifier… en fait pas du tout, j'ai dit une grosse connerie. C'est pratiqement instantané.

Dernière modification par rmy (Le 08/10/2010, à 15:21)

Moimemeici · Le 08/10/2010, à 17:01

voici le resultat du mk2fs

[root@engrenage ~]# mkfs.ext4 -n /dev/md5 |sed -n '11,15p'
mke2fs 1.41.9 (22-Aug-2009)
8192 i-noeuds par groupe
Superblocs de secours stockÃ©s sur les blocsÂ :
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

chopinhauer · Le 08/10/2010, à 17:21

sudo e2fsck -b 102400000 /dev/md5

Il va te demander beaucoup de questions, si tu ne les comprend pas poste-le. Si tu veux répondre oui à tout, ajoute '-y'.

rmy · Le 08/10/2010, à 17:25

@chopinhauer, il vient de lancer

sudo e2fsck /media/secours/image.dd

pour bosser sur l'image, il y a du retour. À suivre, il est en train de répondre "y" à tout au fur et à mesure, mais juste pour voir ce qui se passe.

Si ça tourne sans -b, est-ce nécessaire de spécifier un super de secours ou peut-on espérer qu'e2fsck l'ait fait tout seul correctement ?

Dernière modification par rmy (Le 08/10/2010, à 17:26)

chopinhauer · Le 08/10/2010, à 17:35

rmy a écrit :

Si ça tourne sans -b, est-ce nécessaire de spécifier un super de secours ou peut-on espérer qu'e2fsck l'ait fait tout seul correctement ?

C'est probablement comme dumpe2fs, le '-b' est nécessaire uniquement pour un système de fichiers très endommagé (et créé avec des options non standard). De toute manière il n'utilise pas n'importe quoi comme superbloc, il faut que le magic number soit correct.

Moimemeici · Le 08/10/2010, à 17:38

alors un e2fsck /media/secours/image.dd donne:

fichier: ***** LE SYSTÃME DE FICHIERS A ÃTÃ MODIFIÃ *****
fichierÂ : 438222/274718720 fichiers (17.7% non contigus), 603002635/1098851952 blocs

je veux bien une petite traduction.

j'ai refais un e2fsck juste derriere ca donne:

[root@localhost testdisk-6.12-WIP]# e2fsck /media/secours/image.dd
e2fsck 1.41.10 (10-Feb-2009)
fichierÂ : propre, 438222/274718720 fichiers, 603002635/1098851952 blocs

Dernière modification par Moimemeici (Le 08/10/2010, à 17:40)

rmy · Le 08/10/2010, à 17:50

sudo mount /media/secours/image.dd /mnt

Dernière modification par rmy (Le 08/10/2010, à 17:53)

Moimemeici · Le 08/10/2010, à 19:59

Bon après plusieurs minute, j'ai monté la partition qui est maintenant clean
Résultat:

- les données se trouve dans le lost&found
- il y a 2.2To de donnée sur les 4.5To

e2fsck m'a posé une question qui me semble bizarre:
Vous vous que le lost&found soit agrandi, j'ai répondu oui

questions:

Je suppose que e2fsck récupére le premier superbloc qu'il trouve de valide pour faire son rebuild, donc ce qui expliquerais que j'ai plus de 1to qui ne se voit pas

Donc est ce que si je refait une image mais cette fois ci avec dd (plus rapide) et que je lui indique le superblock a utilisé je peux espérer récupérer les donnée manquante ?

rmy · Le 08/10/2010, à 20:37

chopinhauer, je te laisse répondre à cette question un peu plus pointue sur l'usage des super et leur contenu (inodes, journal), parce que je ne sais pas trop expliquer la "perte" de près de 2To de données alors que 10Gio "seulement" ont été effacés…

chopinhauer · Le 08/10/2010, à 21:22

Moimemeici: T'as perdu combien de données exactement? En perdre un peu plus c'est normal: si l'inode avec les metadonnées se trouvait dans la zone endommagée, le fichier est perdu.

Ceci dit le noyau essaie de mettre les inode à côté des données, donc à l'intérieur du même groupe de 128 Mio.

Sans les metadonnées c'est dur de comprendre qu'est-ce qu'il se trouve où. Par contre une bitmap d'allocation de blocs se trouve dans chaque groupe de blocs. Donc on devrait pouvoir retrouver les blocs qui sont alloués, mais qui n'appartiennent à aucun fichier.

Je me demande si Christophe Grenier n'as pas un outil pour faire cela.

PS: Pour faire des tests sur l'image un système de fichiers copy-on-write serait intéressant. Il y a ext3cow ou les snapshots de LVM qui marchent comme cela.

Moimemeici · Le 08/10/2010, à 23:39

chopinhauer:
cette ligne de commande me trouve des donnée a cette endroit exactement 9859375:

dd if=/dev/md5 count=1 bs=1024 skip=9859375 | hexdump -C

Donc je suppose que je peux dire au revoir au 10/15gio (ca ne me pose pas de probleme)

par contre il y a 1.8to que j'aimerais retrouvé (besoin)

Donc d'ou ma question sur les superblock, est ce qu'en spécifiant un autre superblock plus loin je peux envisagé de récupérer d'autre donnée.
Ou bien est ce qu'il y a une suite de commande que je peux essayé.

Ext3grep me renvoie un failed sur cette commande:

[root@localhost ~]# ext3grep /media/secours/image.dd --superblock | grep 'size:'
ext3grep: init_consts.cc:80: void init_consts(): Assertion `(super_block.s_feature_compat & 0x0004)' failed.

j'utilise de l'ext4.

je suis preneur de toute idées possible!

Dernière modification par Moimemeici (Le 08/10/2010, à 23:40)

chopinhauer · Le 08/10/2010, à 23:55

Ton disque contenait 4.5 Tio de données? C'était quel genre de fichiers et quelle taille?

Tu peux essayer, mais je ne pense pas que spécifier un superbloc manuellement va changer le résultat.

Sinon il y a aussi du matériel qui peut lire des données qui ont été écrit dessus. Hélas, je pense que c'est hors prix.

Moimemeici · Le 09/10/2010, à 10:14

Il était remplie a 93% si je me rappelle bien.
on a de fichiers de 50 a 100mo pour les fichier psd voir des dossiers de 100go etc

en gros l'arborescence du disque était la suivante (je sais que c'est pas très beau):

FTP: contenait que des fichiers PDF pour nos clients
Perso: contenait du perso
Travaux: nos boulot

dans chacun de ces dossier il y a des sous dossier et fichiers:

Moimemeici · Le 09/10/2010, à 15:03

Je teste foremost, il me retrouve plein de fichier mais c'est assez relou les resultat (nom de fichier/arbo)

chopinhauer · Le 09/10/2010, à 15:29

Les noms des fichiers sont stockés dans les répertoires, donc vu que les répertoires étaient probablement au début du disque, ces informations sont perdus. Cependant tu peux commencer en faisant un peu d'ordre:

for i in `find /lost+found -type f`; do
mime=`file --mime-type "$i"`
mkdir -p /premiertri/$mime
mv -i "$i" /premiertri/$mime
done

Comme cela tu vas les trier déjà par type mime et après tu pourra utiliser des logiciels comme pdfinfo pour récupérer les meta-données contenue dans certains fichiers pour leur donner un nom.

Dernière modification par chopinhauer (Le 09/10/2010, à 15:30)

Moimemeici · Le 09/10/2010, à 15:56

Foremost ne trouve que certains type de fichier. voir ceci: Foremost type fichier

Nous utilisons des fichier PSD/AI/TIFF/QXD/QXP etc tout ces types de fichiers ne sont pas pris en compte par foremost

je ne trouve aucune information sur pdfinfo a part ce ceci là

Dernière modification par Moimemeici (Le 09/10/2010, à 16:00)

chopinhauer · Le 09/10/2010, à 16:20

Mon idée était d'utiliser des outils qui savent lire les méta-données contenue dans certains fichiers pour leur donner un nouveau nom. Par exemple pdfinfo peut lire le Titre du PDF et on peut utiliser cette information pour renommer le fichier.

Moimemeici · Le 09/10/2010, à 19:24

Question: Comment convertir une image creer avec un dd/_rescue/rescue en .img valide?
j'aimerais tester un logiciel proprio pour voir le resultat.

Ne vous fachez pas monsieur, mais j'essai toutes les possibilité !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 07/10/2010, à 23:36

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#27 Le 08/10/2010, à 00:16

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#28 Le 08/10/2010, à 00:29

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#29 Le 08/10/2010, à 00:37

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#30 Le 08/10/2010, à 01:11

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#31 Le 08/10/2010, à 12:10

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#32 Le 08/10/2010, à 13:57

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#33 Le 08/10/2010, à 14:37

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#34 Le 08/10/2010, à 17:01

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#35 Le 08/10/2010, à 17:21

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#36 Le 08/10/2010, à 17:25

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#37 Le 08/10/2010, à 17:35

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#38 Le 08/10/2010, à 17:38

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#39 Le 08/10/2010, à 17:50

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#40 Le 08/10/2010, à 19:59

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#41 Le 08/10/2010, à 20:37

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#42 Le 08/10/2010, à 21:22

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#43 Le 08/10/2010, à 23:39

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#44 Le 08/10/2010, à 23:55

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#45 Le 09/10/2010, à 10:14

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#46 Le 09/10/2010, à 15:03

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#47 Le 09/10/2010, à 15:29

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#48 Le 09/10/2010, à 15:56

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#49 Le 09/10/2010, à 16:20

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

#50 Le 09/10/2010, à 19:24

Re : [Non Résolu mais fini]-Grappe Raid Ok - partition - Fichier disparue

Pied de page des forums