#26 Le 27/06/2011, à 21:08
- rmy
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Ouais, c'est un peu capilotracté ton affaire… mais c'est vrai, il pourrait mettre ensuite une partition en failed. Par contre je ne suis pas sûr non plus qu'il ait le même résultat par rapport à ce qui a été écrasé… Dans l'idée je pense qu'il pourrait aussi le faire avec deux fichiers… il suffirait qu'il en supprime un des deux…
récupération de données: vrac–topic unique–mon site pro pour les particuliers : www.diskcard.fr– Je recycle volontiers tous vos disques durs HS (ou pas).
Le site pro pour les pros, spécialiste recupération de données RAID, NAS et serveurs: www.vodata.fr
Hors ligne
#27 Le 27/06/2011, à 23:00
- Hoper
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Tout a fait. Deux fichiers ou deux volumes logiques, ca revient strictement au même
Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org
Hors ligne
#28 Le 28/06/2011, à 09:35
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Effectivement, les versions récentes d'ubuntu n'utilisent plus le format 0.90. Et encore une fois, si il faut des heures pour réaliser l'opération (et pendant ce temps, les disques ont une activée vraiment intense), je suis certain que c'est parce qu'il écrit vraiment sur les disques. Alors est ce qu'il met des 0 partout, ou des FF, ou autre chose, je n'en sais rien. Mais dans tous les cas, il doit réellement écrire. (Cela doit aussi permettre de détecter des secteurs défectueux, mais je doute que ce soit le but premier de la manipulation)
Je suis assez d'accord avec ça. Par contre, on en est au même point, on ne sait pas exactement ce que fait mdadm, on fait juste des suppositions. Pour savoir ce qu'il fait, vous savez où je dois me rendre (un site, une personne, ...) ? Sinon, j'imagine que si le man est à jour, je devrais être aiguillé vers le responsable du paquet qui pourra probablement m'en dire plus.
Concernant l'histoire des disques, petits ou gros, partition ou pas partition...etc... De toute façon, je récupère aujourd'hui ou demain un disque de 2To dans lequel je ferai un dump de l'un des 2 disques de 1To. Ensuite j'ouvrirai ce fichier en lecture séquentielle pour voir ce qu'il contient. Je parle couramment binaire/hexa donc je vais essayer de glaner des infos à la mano, soit avec un petit programme en C, soit en lecture directe avec gvim en mode hexa. Après j'aviserai. En tout cas, savoir exactement ce que fait mdadm au moment de la synchronisation serait un très très gros atout pour la suite. Au pire, si je n'arrive pas à trouver l'info qqpart, j'irai voir directement dans le code source de mdadm en espérant qu'il ne soit pas trop compliqué pour moi et surtout écrit dans un langage que je maîtrise.
La bonne nouvelle quand même : j'ai retrouvé mon disque externe (perdu après un déménagement en avril) sur lequel j'ai une sauvegarde du mois d'avril contenant toutes mes photos, toute ma musique et tous mes documents. Mes dernières photos sont encore sur compact flash. Et le DD de ma femme se porte bien pour l'instant, avec toutes ses données intactes. Donc au pire je perds les dernières modifs dans mes musiques (pas grave), mes derniers docs (pas trop grave), et toutes mes vidéos (sic) : en somme, même si je ne vais pas plus loin, je ne perds pas grand chose (on appellera ça un ménage de printemps à la mode mad max). C'est pourquoi je ne vais pas me prendre le chou avec un ou 2 autres disques ou 2 partitions...etc... Je fais un dump de l'un des 2 concernés et advienne que pourra. Si j'en apprends davantage sur les formats internes d'écriture sur les disques, ce sera déjà très bien.
Donc en somme, je poursuis pour le challenge, mais je suis serein maintenant que j'ai retrouvé mes données sensibles.
Hors ligne
#29 Le 28/06/2011, à 09:57
- rmy
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Effectivement, les versions récentes d'ubuntu n'utilisent plus le format 0.90. Et encore une fois, si il faut des heures pour réaliser l'opération (et pendant ce temps, les disques ont une activée vraiment intense), je suis certain que c'est parce qu'il écrit vraiment sur les disques. Alors est ce qu'il met des 0 partout, ou des FF, ou autre chose, je n'en sais rien. Mais dans tous les cas, il doit réellement écrire. (Cela doit aussi permettre de détecter des secteurs défectueux, mais je doute que ce soit le but premier de la manipulation)
Je suis assez d'accord avec ça. Par contre, on en est au même point, on ne sait pas exactement ce que fait mdadm, on fait juste des suppositions. Pour savoir ce qu'il fait, vous savez où je dois me rendre (un site, une personne, ...) ? Sinon, j'imagine que si le man est à jour, je devrais être aiguillé vers le responsable du paquet qui pourra probablement m'en dire plus.
Concernant l'histoire des disques, petits ou gros, partition ou pas partition...etc... De toute façon, je récupère aujourd'hui ou demain un disque de 2To dans lequel je ferai un dump de l'un des 2 disques de 1To. Ensuite j'ouvrirai ce fichier en lecture séquentielle pour voir ce qu'il contient. Je parle couramment binaire/hexa donc je vais essayer de glaner des infos à la mano, soit avec un petit programme en C, soit en lecture directe avec gvim en mode hexa. Après j'aviserai. En tout cas, savoir exactement ce que fait mdadm au moment de la synchronisation serait un très très gros atout pour la suite. Au pire, si je n'arrive pas à trouver l'info qqpart, j'irai voir directement dans le code source de mdadm en espérant qu'il ne soit pas trop compliqué pour moi et surtout écrit dans un langage que je maîtrise.
La bonne nouvelle quand même : j'ai retrouvé mon disque externe (perdu après un déménagement en avril) sur lequel j'ai une sauvegarde du mois d'avril contenant toutes mes photos, toute ma musique et tous mes documents. Mes dernières photos sont encore sur compact flash. Et le DD de ma femme se porte bien pour l'instant, avec toutes ses données intactes. Donc au pire je perds les dernières modifs dans mes musiques (pas grave), mes derniers docs (pas trop grave), et toutes mes vidéos (sic) : en somme, même si je ne vais pas plus loin, je ne perds pas grand chose (on appellera ça un ménage de printemps à la mode mad max). C'est pourquoi je ne vais pas me prendre le chou avec un ou 2 autres disques ou 2 partitions...etc... Je fais un dump de l'un des 2 concernés et advienne que pourra.
Si j'en apprends davantage sur les formats internes d'écriture sur les disques, ce sera déjà très bien.
Donc en somme, je poursuis pour le challenge, mais je suis serein maintenant que j'ai retrouvé mes données sensibles.
tu peux aller tapper à la porte de l'irc, il y a un chan en rapport de mémoire. N'hésites pas à être le plus détaillé possible dans tes recherches, ça aidera tout le monde. Je vais essayer de trouver le temps de mon côté pour faire un petit test… mais je suis sincèrement débordé en ce moment. Bcp de boulot + rmll.
Suis ravi pour ton disque retrouvé. Si tu fais vraiment le boulot sur un seul disque du raid1, et que tu peux sacrifier l'autre, à mon avis la première chose à faire est de faire une copie de sécurité des données du disque externe. L'expérimentation et le challenge, ça peut venir après, non ?
récupération de données: vrac–topic unique–mon site pro pour les particuliers : www.diskcard.fr– Je recycle volontiers tous vos disques durs HS (ou pas).
Le site pro pour les pros, spécialiste recupération de données RAID, NAS et serveurs: www.vodata.fr
Hors ligne
#30 Le 28/06/2011, à 10:18
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Suis ravi pour ton disque retrouvé. Si tu fais vraiment le boulot sur un seul disque du raid1, et que tu peux sacrifier l'autre, à mon avis la première chose à faire est de faire une copie de sécurité des données du disque externe. L'expérimentation et le challenge, ça peut venir après, non ?
Pour la petite histoire, j'ai retourné la maison tout hier soir dans le seul et unique but de retrouver ce **ê²²ễù de disque de ¹ù*££µ% sans succès. Je me suis couché puis, vers 2h du mat, un oiseau est venu foutre le souk sous ma fenêtre pour la deuxième nuit consécutive et là j'ai craqué, j'ai fouillé ma table de nuit à la recherche de boules quies et ma main a trouvé, dans le noir, au fond du tiroir, un disque dur externe... Au réveil, j'ai de suite allumé mon pc, connecté le disque, puis copié l'ensemble de son contenu sur mon disque système (donc t'inquiètes, ça c'est fait ). Ce soir, je crois que je vais laisser quelques miettes de pain sous la fenêtre car finalement, cet oiseau, je l'aime bien. Il est un peu bruyant, mais il s'est manifesté au bon moment.
Hors ligne
#31 Le 28/06/2011, à 10:21
- rmy
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
récupération de données: vrac–topic unique–mon site pro pour les particuliers : www.diskcard.fr– Je recycle volontiers tous vos disques durs HS (ou pas).
Le site pro pour les pros, spécialiste recupération de données RAID, NAS et serveurs: www.vodata.fr
Hors ligne
#32 Le 28/06/2011, à 14:49
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Ouais, c'est un peu capilotracté ton affaire… mais c'est vrai, il pourrait mettre ensuite une partition en failed. Par contre je ne suis pas sûr non plus qu'il ait le même résultat par rapport à ce qui a été écrasé… Dans l'idée je pense qu'il pourrait aussi le faire avec deux fichiers… il suffirait qu'il en supprime un des deux…
Tout a fait. Deux fichiers ou deux volumes logiques, ca revient strictement au même
De toute façon, sous unix/linux, tout est fichier, donc partant de là...
Hors ligne
#33 Le 28/06/2011, à 18:49
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, j'y suis, j'ai démarré le système avec un raid dégradé (un seul disque). Je me permets de vous reposer cette question :
Autre question : tu dis qu'il faut débrancher un disque et travailler avec un seul. Ok. Mais dois-je accéder à celui que je garde en tant que DD d'un ensemble raid ou dois-je "déconstruire" le raid ?
En fait je me demande si je peux directement faire un dump /dev/sda alors qu'il est membre d'un ensemble raid. Je vais tester...
EDIT : raid stoppé, commande lancée, reste plus qu'à attendre 3 heures
sudo dd if=/dev/sda of=/media/DJu/wazaaa.image bs=4096 conv=notrunc,noerror
EDIT2 : erf, un orage approche... suis-je maudit...
EDIT3 : dump OK :
244190646+0 enregistrements lus
244190646+0 enregistrements écrits
1000204886016 octets (1,0 TB) copiés, 10310 s, 97,0 MB/s
Maintenant il faut voir ce qu'il contient...
Dernière modification par mazkagaz (Le 28/06/2011, à 22:06)
Hors ligne
#34 Le 28/06/2011, à 22:30
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, suite des événements :
testdisk /media/DJu/wazaaa.dd
renvoie
TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.orgTestDisk is free software, and
comes with ABSOLUTELY NO WARRANTY.Select a media (use Arrow keys, then press Enter):
Disk wazaaa.dd - 1000 GB / 931 GiB[Proceed ] [ Sudo ] [ Quit ]
Je choisis proceed et là... joyeux noël, mon terminal est complètement buggé et rempli de
7f4ca93e0000-7f4ca95df000 ---p 00003000 08:21 7081667 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca95df000-7f4ca95e0000 r--p 00002000 08:21 7081667 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca95e0000-7f4ca95e1000 rw-p 00003000 08:21 7081667 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca95e1000-7f4ca960d000 r-xp 00000000 08:21 7081689 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7f4ca960d000-7f4ca980d000 ---p 0002c000 08:21 7081689 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7f4ca980d000-7f4ca980e000 r--p 0002c000 08:21 7081689 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7f4ca980e000-7f4ca980f000 rw-p 0002d000 08:21 7081689 /lib/x86_64-linux-gnu/libext2fs.so.2.4
7f4ca980f000-7f4ca9833000 r-xp 00000000 08:21 5122641 /usr/lib/libntfs.so.10.0.0
7f4ca9833000-7f4ca9a33000 ---p 00024000 08:21 5122641 /usr/lib/libntfs.so.10.0.0
7f4ca9a33000-7f4ca9a34000 r--p 00024000 08:21 5122641 /usr/lib/libntfs.so.10.0.0
7f4ca9a34000-7f4ca9a35000 rw-p 00025000 08:21 5122641 /usr/lib/libntfs.so.10.0.0
7f4ca9a35000-7f4ca9a39000 r-xp 00000000 08:21 7081743 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f4ca9a39000-7f4ca9c38000 ---p 00004000 08:21 7081743 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f4ca9c38000-7f4ca9c39000 r--p 00003000 08:21 7081743 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f4ca9c39000-7f4ca9c3a000 rw-p 00004000 08:21 7081743 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f4ca9c3a000-7f4ca9c86000 r-xp 00000000 08:21 7077949 /lib/libncursesw.so.5.7
7f4ca9c86000-7f4ca9e85000 ---p 0004c000 08:21 7077949 /lib/libncursesw.so.5.7
7f4ca9e85000-7f4ca9e89000 r--p 0004b000 08:21 7077949 /lib/libncursesw.so.5.7
7f4ca9e89000-7f4ca9e8a000 rw-p 0004f000 08:21 7077949 /lib/libncursesw.so.5.7
7f4ca9e8a000-7f4ca9eab000 r-xp 00000000 08:21 7081649 /lib/x86_64-linux-gnu/ld-2.13.so
7f4caa084000-7f4caa089000 rw-p 00000000 00:00 0
7f4caa0a8000-7f4caa0aa000 rw-p 00000000 00:00 0
7f4caa0aa000-7f4caa0ab000 r--p 00020000 08:21 7081649 /lib/x86_64-linux-gnu/ld-2.13.so
7f4caa0ab000-7f4caa0ad000 rw-p 00021000 08:21 7081649 /lib/x86_64-linux-gnu/ld-2.13.so
7fff0b0f0000-7fff0b111000 rw-p 00000000 00:00 0 [stack]
7fff0b1ff000-7fff0b200000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Abandon
Je suis pas un pro, mais je dirais que ça s'est pas super bien passé
Hors ligne
#35 Le 28/06/2011, à 23:06
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
suite....
hd -v wazaaa.dd |more
commence par me renvoyer des choses intéressantes... Déjà je retrouve l'ancien nom de volume :
000003f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000400 00 a0 a3 03 b6 0d 8e 0e 7c 4d ba 00 19 0b bf 08 |........|M......|
00000410 b4 7b a2 03 00 00 00 00 02 00 00 00 02 00 00 00 |.{..............|
00000420 00 80 00 00 00 80 00 00 00 20 00 00 89 8c 07 4e |......... .....N|
00000430 3d 9f 07 4e 02 00 20 00 53 ef 01 00 01 00 00 00 |=..N.. .S.......|
00000440 63 8c 07 4e 00 4e ed 00 00 00 00 00 01 00 00 00 |c..N.N..........|
00000450 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00000460 42 02 00 00 7b 00 00 00 64 65 1a 7c b3 79 46 f3 |B...{...de.|.yF.|
00000470 ba e6 cf f8 67 ef 8c eb 44 41 54 41 5f 4f 4b 32 |....g...DATA_OK2|
00000480 00 00 00 00 00 00 00 00 2f 6d 65 64 69 61 2f 44 |......../media/D|
00000490 41 54 41 5f 4f 4b 32 00 10 59 55 cd 01 88 ff ff |ATA_OK2..YU.....|
000004a0 ea b6 c7 ff 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004b0 00 59 55 cd 01 88 ff ff 40 9b e9 ee 01 88 ff ff |.YU.....@.......|
000004c0 00 c9 7d 0b 02 88 ff ff 00 00 00 00 00 00 c5 03 |..}.............|
000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004e0 08 00 00 00 00 00 00 00 00 00 00 00 3c 67 df d6 |............<g..|
000004f0 8d 09 41 a2 98 2d 53 9a 45 a9 01 89 01 01 00 00 |..A..-S.E.......|
00000500 00 00 00 00 00 00 00 00 63 8c 07 4e 0a f3 02 00 |........c..N....|
00000510 04 00 00 00 00 00 00 00 00 00 00 00 ff 7f 00 00 |................|
00000520 00 80 40 07 ff 7f 00 00 01 00 00 00 ff ff 40 07 |..@...........@.|
00000530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Bon, c'est pas grand chose, et ça n'est que le début du disque... les metadatas raid commencent à "4K from the beginning of the device", soit 00001000 (16*16*16=4096).
Bingo, le magic number 0xa92b4efc :
00001000 fc 4e 2b a9 01 00 00 00 00 00 00 00 00 00 00 00 |.N+.............|
Ensuite, après les 256 octets du superblock (jusqu'à 000010FF), ça devient de l’hébreu ancien pour moi pendant lonnnngtemps puis, il semble qu'on trouve qqch...
Tous les 4k, j'ai des données suivies par des 0 jusqu'au 4k suivant, par exemple :
0003efe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0003eff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0003f000 3f 80 00 00 3f 80 01 00 3f 80 02 00 3f 80 03 00 |?...?...?...?...|
0003f010 3f 80 04 00 3f 80 0c 00 3f 80 0d 00 3f 80 18 00 |?...?...?...?...|
0003f020 3f 80 28 00 3f 80 3e 00 3f 80 79 00 3f 80 ab 00 |?.(.?.>.?.y.?...|
0003f030 3f 80 38 01 3f 80 6c 01 3f 80 45 04 3f 80 b0 04 |?.8.?.l.?.E.?...|
0003f040 3f 80 1a 06 3f 80 d0 0c 00 00 00 00 00 00 00 00 |?...?...........|
0003f050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0003f060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0003f070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0003f080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
(...)
0003ffe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0003fff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00040000 40 80 00 00 40 80 01 00 40 80 02 00 40 80 03 00 |@...@...@...@...|
00040010 40 80 04 00 40 80 0c 00 40 80 0d 00 40 80 18 00 |@...@...@...@...|
00040020 40 80 28 00 40 80 3e 00 40 80 79 00 40 80 ab 00 |@.(.@.>.@.y.@...|
00040030 40 80 38 01 40 80 6c 01 40 80 45 04 40 80 b0 04 |@.8.@.l.@.E.@...|
00040040 40 80 1a 06 40 80 d0 0c 00 00 00 00 00 00 00 00 |@...@...........|
00040050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
(...)
00040fe0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00040ff0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00041000 41 80 00 00 41 80 01 00 41 80 02 00 41 80 03 00 |A...A...A...A...|
00041010 41 80 04 00 41 80 0c 00 41 80 0d 00 41 80 18 00 |A...A...A...A...|
00041020 41 80 28 00 41 80 3e 00 41 80 79 00 41 80 ab 00 |A.(.A.>.A.y.A...|
00041030 41 80 38 01 41 80 6c 01 41 80 45 04 41 80 b0 04 |A.8.A.l.A.E.A...|
00041040 41 80 1a 06 41 80 d0 0c 00 00 00 00 00 00 00 00 |A...A...........|
00041050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00041060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Est-ce que quelqu'un qui a l'habitude de lire des raw data n'y verrait pas, à tout hasard, une certaine cohérence avec une système de fichier ext4 ? Par hasard ? Franchement ça me ferait plaisir...
Dernière modification par mazkagaz (Le 28/06/2011, à 23:10)
Hors ligne
#36 Le 28/06/2011, à 23:23
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, donc, toute la question pour moi maintenant est de savoir si ces blocks de 4k sont issus du format ext4 ou d'une initialisation raid faite par mdadm.
La suite un autre jour, je suis fatigué. (faites que "synchronisation" rime avec "copie d'un disque sur l'autre"...)
Demain j'attaque la lecture de https://ext4.wiki.kernel.org/index.php/Ext4_Design
et https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
Dernière modification par mazkagaz (Le 28/06/2011, à 23:32)
Hors ligne
#37 Le 29/06/2011, à 02:52
- rmy
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Je persiste à penser que ta démarche est courageuse, mais effectuée à l'envers. Pour réponder à la question primordiale : "est-ce que mdadm a tout effacé", le plus simple pour moi reste de faire une recherche rapide sur des JPG et de voir si tu sors quelque chose d'intéressant avec photorec.
Si tu veux voir vite fait si ton ancien ext4 existe encore, fais un scan avec les version démos rstudio ou ufsexplorer.
Si tu veux en savoir plus sur mdadm et ce qu'il fait, reproduis et compare un "avant" et un "après"… plutôt que de partir du résultat, dont tu n'as aucune info objective que ce qui a causé son état actuel.
récupération de données: vrac–topic unique–mon site pro pour les particuliers : www.diskcard.fr– Je recycle volontiers tous vos disques durs HS (ou pas).
Le site pro pour les pros, spécialiste recupération de données RAID, NAS et serveurs: www.vodata.fr
Hors ligne
#38 Le 29/06/2011, à 07:20
- Hoper
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, donc, toute la question pour moi maintenant est de savoir si ces blocks de 4k sont issus du format ext4 ou d'une initialisation raid faite par mdadm.
Je vote malheureusement (et sans preuves on est d'accord) pour la seconde option. Je ne sais pas avec quelles options par défaut les raid sont crées en version 1.2. Mais en version 0.90, il était possible d'activer un mécanisme de journalisation. En fait, le raid qui est crée est découpé en un très grand nombre de "bloc" (je ne connais pas leur taille, mais on ne parle évidement pas de bloc de 512 octets). Pourquoi ? Parce qu'en cas d'arrêt électrique brutal ou autre gag de ce genre, cela lui permet de trouver très vite quels sont les blocs qui ne sont plus synchronisés. (je suppose qu'il compare des checsums des blocks mais il y a peut etre d'autres infos dans ses meta data...).
Grâce à ça, au lieu de plusieurs heures de synchro, le raid peut remonter en quelques secondes.
Pour le reste je suis d'accord avec rmy...
Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org
Hors ligne
#39 Le 29/06/2011, à 09:26
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Je persiste à penser que ta démarche est courageuse, mais effectuée à l'envers. Pour réponder à la question primordiale : "est-ce que mdadm a tout effacé", le plus simple pour moi reste de faire une recherche rapide sur des JPG et de voir si tu sors quelque chose d'intéressant avec photorec.
Si tu veux voir vite fait si ton ancien ext4 existe encore, fais un scan avec les version démos rstudio ou ufsexplorer.
Si tu veux en savoir plus sur mdadm et ce qu'il fait, reproduis et compare un "avant" et un "après"… plutôt que de partir du résultat, dont tu n'as aucune info objective que ce qui a causé son état actuel.
Oui, j'aime bien mettre les mains dans le cambouis pour voir à quoi ça ressemble à l'intérieur. Et comme je n'ai pas l'habitude de perdre des données, je n'ai pas tous les outils en tête. La prochaine étape sera effectivement de chercher une photo ou image avec photorec. Normalement j'avais environ 30 Go de photos donc si le système de fichier ext4 existe encore, photorec devrait trouver quelque chose. Comme ça je serai fixé. Par contre, vu le résultat de testdisk, et étant donné que photorec fait partie de la même suite logicielle, je suis assez perplexe...
Rstudio... C'est un IDE pour développer en R. Dispose-t-il d'outils intégrés pour analyser des disques, système de fichiers ou autre ? Ufsexplorer, pour l'instant le proxy de mon taf bloque tous les liens vers cet outil donc... Je verrai plus tard. J'ai trouvé aussi assez souvent des posts abordant Foremost qui a l'air assez puissant. Un petit :
foremost -w -t jpg -i /media/DJu/wazaaa.dd -o /media/DJu/liste_jpg
devrait me donner qqch d'intéressant, ou rien si le disque est vide.
Je vote malheureusement (et sans preuves on est d'accord) pour la seconde option.
Je te trouve un peu hope(r)less... Comme tu dis, "sans preuve", donc tout est possible. Encore une fois, j'y vais l'esprit serein puisque j'ai récupéré quasiment tout ce qui était vraiment important. Je n'ai rien à perdre et même, tout à gagner. Aussi, c'est avec la claire intention de trancher dans le mysticisme que je cherche des traces tangibles (ou "preuve") pour confirmer, ou non, que mdadm a tout écrasé. Comme ça, si un autre clampin débarque un de ces 4 avec le même soucis que moi, mais sans avoir la chance de disposer d'une autre sauvegarde ailleurs, il saura à quoi s'en tenir. Avec des considérations du même ordre que les tiennes, je pourrais te dire qu'hier, la commande dd a duré autant de temps que le montage du raid, avec des accès disque tout à fait comparables (à la fois en lecture et écriture) et que pourtant, je dispose d'une copie exacte et non altérée de mon disque sans l'avoir modifié le moins du monde. Ne prends pas cette remarque pour un argument, je cherche juste à te montrer que sans "preuve", on peut dire tout et son contraire. Les blocs du raid sont-ils marqués sur toute la surface ? A-t-on seulement leurs adresses et checksums en début de disque (la partie hébreu ancien par exemple) ? Peut-être que mdadm se contente de lire un des disques (au hasard le premier puisqu'il n'y a pas de notion de source et cible, comme tu l'as déjà remarqué), de copier les blocs un par un d'un disque sur l'autre en calculant les checksum pour remplir l'entête après les metadatas. D'ailleurs, je pourrais trouver un autre indice fumeux pour "confirmer" cette supposition : si mdadm se contentait d'écrire des blocks vides, pourquoi y aurait-il autant d'accès en lecture ? Tu pourrais me dire, sans "preuve", que c'est peut-être pour chercher et tagger les secteurs défectueux... Bref, tu vois, tant qu'on sait pas, on peut aller loin en suppositions. Aussi je vais poursuivre mes investigation jusqu'à avoir cette certitude : mdadm a ou n'a pas tout cassé.
Hors ligne
#40 Le 29/06/2011, à 19:05
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
des nouvelles du front...
La commande :
foremost -w -t jpg -i /media/DJu/wazaaa.dd -o /media/DJu/liste_jpg
me renvoie toute une liste de jpeg dans le fichier /media/DJu/liste_jpg/audit.conf ...
Mais ne nous emballons pas ! (enfin, pas trop, parce que là j'ai quand même un gros smile)
Comme hier j'ai eu l'impression de reconnaître des blocks de 4k, je relance la commande en essayant de l'optimiser un peu :
foremost -w -t jpg -b 4096 -i /media/DJu/wazaaa.dd -o /media/DJu/liste_jpg_2
la suite au prochain épisode...
Hors ligne
#41 Le 29/06/2011, à 19:20
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
le résultat des 2 appels à foremost est identique, le nom des fichiers mis à part. Si je "grep" une ligne au hasard :
$ grep 25251: audit.txt.*
audit.txt.1:25251: 184522374.jpg 1 MB 94475455664
audit.txt.2:25251: 23065296.jpg 1 MB 94475455664
reste à savoir si c'est vraiment une image...
Donc je vais passer à la phase récupération pour vérifier le contenu....
La suite au prochain épisode....
Hors ligne
#42 Le 29/06/2011, à 19:36
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Yes !!!!
...
Et je dirais même plus : YES !!!!!
J'ai des images, des vrais, qui sortent. Donc : mdadm n'a pas tout cassé. On ne sait toujours pas ce que ça a fait exactement mais il y a encore de la donnée sur ces disques.
Du coup, soit je me plonge dans les specs du format ext4, soit vous avez une solution vachement plus simple à me proposer. Mais il va de soi que je ne peux pas en rester là !
Hors ligne
#43 Le 29/06/2011, à 21:30
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, photorec, testdisk, même combat : ça plante.
J'ai l'impression qu'il va falloir que je me fade tout ça à la main.
Hors ligne
#44 Le 29/06/2011, à 22:21
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, je sors l'artillerie e2fsprogs. On va voir si ça aide.
$ dumpe2fs wazaaa.dd
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name: DATA_OK2
Last mounted on: /media/DATA_OK2
Filesystem UUID: 64651a7c-b379-46f3-bae6-cff867ef8ceb
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244190646
Reserved block count: 12209532
Free blocks: 146737945
Free inodes: 60980148
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sun Jun 26 21:45:39 2011
Last mount time: Sun Jun 26 21:46:17 2011
Last write time: Sun Jun 26 23:06:05 2011
Mount count: 2
Maximum mount count: 32
Last checked: Sun Jun 26 21:45:39 2011
Check interval: 15552000 (6 months)
Next check after: Fri Dec 23 20:45:39 2011
Lifetime writes: 362 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 3c67dfd6-8d09-41a2-982d-539a45a90189
Journal backup: inode blocks
dumpe2fs: A block group is missing an inode table lors de la lecture de l'i-noeud du journal
Donc ça ça correspond aux info qu'on avait dans les premiers 4k je pense, avant l'arrivée des metadata raid.
EDIT : lancement de
$ e2fsck wazaaa.dd
très verbeux, me demande confirmer des milliards de corrections... ctrl+c et tentative de
$ e2fsck -p wazaaa.dd
DATA_OK2 n'a pas été démonté proprement, vérification forcée.
DATA_OK2: l'i-noeud 44961552 a le drapeau de compression qui est initialisé sur un système de fichiers sans support de compression.DATA_OK2: INCONSISTENCE INATTENDUE ; EXÉCUTEZ fsck MANUELLEMENT.
(i.e., sans options -a ou -p)
Bon, ok, je vais utiliser la technique du tournevis qui bloque la touche "O" et je vais fumer une cloppe pendant le "e2fsck wazaaa.dd"
Dernière modification par mazkagaz (Le 29/06/2011, à 23:07)
Hors ligne
#45 Le 29/06/2011, à 22:28
- rmy
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Bon, photorec, testdisk, même combat : ça plante.
J'ai l'impression qu'il va falloir que je me fade tout ça à la main.
Désolé pour le manque de réactivité, suis overbooké par les RMLL.
Essaye une autre version de photorec. Si tu as pris celle des paquets en particulier, c'est obsolète. Va chopper sur le site de Christophe Grenier la 6.12 ou la 6.13-WIP, et relance testdisk et photorec s'il te plaît.
En vrac pour les réponses : R-Studio (de r-tt). Logiciel de récup proprio qui tourne sous linux. Bien joué pour foremeost, est-ce que tu as des images de plus de 1M ? Est-ce qu'elles ne sont pas corrompues ?
récupération de données: vrac–topic unique–mon site pro pour les particuliers : www.diskcard.fr– Je recycle volontiers tous vos disques durs HS (ou pas).
Le site pro pour les pros, spécialiste recupération de données RAID, NAS et serveurs: www.vodata.fr
Hors ligne
#46 Le 29/06/2011, à 22:44
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
mazkagaz a écrit :Bon, photorec, testdisk, même combat : ça plante.
J'ai l'impression qu'il va falloir que je me fade tout ça à la main.
Désolé pour le manque de réactivité, suis overbooké par les RMLL.
Essaye une autre version de photorec. Si tu as pris celle des paquets en particulier, c'est obsolète. Va chopper sur le site de Christophe Grenier la 6.12 ou la 6.13-WIP, et relance testdisk et photorec s'il te plaît.
En vrac pour les réponses : R-Studio (de r-tt). Logiciel de récup proprio qui tourne sous linux. Bien joué pour foremeost, est-ce que tu as des images de plus de 1M ? Est-ce qu'elles ne sont pas corrompues ?
pour l'instant j'ai pas essayé de récupérer les grosses images. J'ai juste acter leur existence en en récupérant une petite et je m'en suis allé avec l'idée de réparer le FS (non... si si).
En plus maintenant que l'hypothèse copie de l'un sur l'autre semble se vérifier, ce qui serait intéressant, ce serait de savoir lequel était le source. Du coup, je fais joujou avec le dump du premier, au pire, si je le démolis, je le re dumpe. Et si j'obtiens rien, je teste avec le second disque, au cas ou ce soit la "source".
Dernière modification par mazkagaz (Le 29/06/2011, à 22:45)
Hors ligne
#47 Le 29/06/2011, à 22:46
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
En fait voilà, mon idée c'est : je répare le FS dans un dump et je monte le dump réparer... Je sais pas si c'est possible étant donné que je ne connais pas le niveau de dégradation, mais je vais tester.
Hors ligne
#48 Le 29/06/2011, à 23:13
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
La vache ! je commence à voir apparaître les noms de mes fichiers/dossiers
Je le laisse finir et demain je ferais un dump de l'autre disque, pour voir si j'obtiens la même chose, ou mieux, ou pire.
Hors ligne
#49 Le 30/06/2011, à 09:16
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
Levé ce matin, restauration en pause, attente de réponse pour dupliquer des blocks partagés... bref, le tournevis qui bloquait la touche "O" est tombé
Dans l'hypothèse peu probable où qqun ayant le même soucis que moi suivrait l'évolution de ce post :
/!\ATTENTION/!\ Ne pas faire comme moi. J'y vais comme un bourrin parce que j'ai pas grand chose à perdre. Je mettrai à jour le premier post en supprimant le blabla et en ajoutant toutes les infos utiles (s'il en est) quand j'aurai terminé mes expériences. /!\ATTENTION/!\
Comme en attendant de récupérer ou non mes datas je suis un peu bloqué pour le reste (2 disques de 1To mis au placard, ça manque...), j'installe prochainement 2 disques de 2To et je mets les 2 de 1To dans 2 boîtiers externes. Comme ça je vais pouvoir refermer ma tour et travailler sur les 2 dumps en même temps, tout en vaquant à mes occupations habituelles.
Je suis allé sur le site de Christophe Grenier. Effectivement il semble qu'il y ait du nouveau. Je verrais ce que proposent ces nouvelles versions. Sachant que ce que j'aimerais faire est assez particulier : je souhaite essayer de réparer un FS et non simplement récupérer quelques fichiers. Je ne sais pas si c'est possible, je ne sais pas si je vais y arriver, mais c'est le but que je me suis fixé pour le moment.
Donc pour résumer ce que je vais faire :
1/ dump des disques :
dd if=/device_1To_disque1 of=/media/Disque_2To_1/image_1To_1.dd bs=4096 conv=notrunc,noerror
dd if=/device_1To_disque2 of=/media/Disque_2To_2/image_1To_2.dd bs=4096 conv=notrunc,noerror
2/ identification des images :
dumpe2fs /media/Disque_2To_1/image_1To_1.dd
dumpe2fs /media/Disque_2To_2/image_1To_2.dd
3/ tentative de récup bourrine :
e2fsck -p /media/Disque_2To_1/image_1To_1.dd
e2fsck -p /media/Disque_2To_2/image_1To_2.dd
4/ si l'un des 2 e2fsck donne des résultats encourageants, je compare certains gros fichiers avec ma sauvegarde externe actuelle (somme de contrôle md5) non corrompue et j'avise. Si pas de résultat, je recommence les étapes 1 et 2 puis je modifie l'étape 3 par des réparations moins bourrines : d'autres utilisations de e2fsck et/ou testdisk/photorec (dernières versions) et/ou ce que j'aurai trouvé d'ici là (restauration en utilisant les 2 dumps simultanément ??? )...
Hors ligne
#50 Le 30/06/2011, à 18:50
- mazkagaz
Re : [RESOLU] perte données suite montage raid1 mdadm sur disques non vides
moi@machine:~$ sudo mount -o loop /media/DJu/wazaaa.dd test/
[sudo] password for moi:
moi@machine:~$ ls test
elle lost+found moi
moi@machine:~$ echo content
content
moi@machine:~$
TADAM !
et j'ai des images qui font largement plus d'un méga, et intactes ! Oui messieurs !
Bon, vu que j'ai interrompu le e2fsck parce que j'en avais ras la cacaouette, ben je vais recommencer à zéro en essayant de le faire proprement sur les images des 2 disques.
(content content content content content content content content content content content content)
Hors ligne