[PERDU] Récupération partition ext4 avec lvm sous mdadm raid5

[keneda212]

Hello

 

Suite un soucis chaise clavier (ou plutot sol/tabouret dans ce cas la), j'ai plusieurs disques qui se sont sortis de l'ordi puis remis, le tout en route (en gros pendant 10s maxi, sans aucune operation sur l'ordi a ce moment la)

mdadm a pas bien supporté cela, et m'a mis le raid5 en javel.

 

j'ai pas mal fouillé sur le net, et j'ai reussi a remonter mon raid (enfin j'espere).

 

Dans les opérations faites, j'ai forcé le réassemblage du raid, qui a corrigé les "event count" de 2 disques mais n'a résolu le soucis.

Puis j'ai recrée le raid avec l'option --assume-clean, tout d'abord avec un mauvais chunk, et ca s'est vu car rien reconnu.

Quand je l'ai refais avec le bon chunk, LVM s'est réactivé, a retrouvé mon pv, vg et finalement le lv.

le status mdstat m'a bloqué le raid5 en mode active read only, niquel (pas envie que ca refasse une synchro et que ca pete tout).

 

Donc mon lv est bien reconnu avec une partoche dessus, je peux d'ailleurs plus toucher au raid car lvm tient bien son truc.

 

Mais....., forcement y'a bien un pb.... j'arrive pas à monter la partition

J'ai le droit à ca :

 

mount : mauvais type de système de fichiers, option erronée, superbloc
        erroné sur /dev/mapper/spooky-data, page de code ou aide manquante, ou autre erreur
       Dans quelques cas certaines informations sont utiles dans syslog — essayez
       « dmesg | tail » ou quelque chose du genre

Ca reconnait plus l'ext4.

Dans les logs system j'ai le droit à ca :

Jul 18 12:22:42 spooky kernel: [   84.090184] EXT4-fs (dm-0): VFS: Can't find ext4 filesystem
Jul 18 12:22:42 spooky kernel: [   84.098740] EXT2-fs (dm-0): error: can't find an ext2 filesystem on dev dm-0.
Jul 18 12:22:49 spooky kernel: [   90.665995] EXT4-fs (dm-0): VFS: Can't find ext4 filesystem

Est ce qu'il y a un moyen de récuperer ma partition, vivante, et sans formater ?

parce que la, je commence a desespérer à recuperer ma partoche

edit : j'adore tomber sur des sites qui indique des choses du genre :

Never use Linux software RAID and LVM for important data

Software RAID in Linux is generally invitation to troubles. This badly written and badly integrated subsystem. Unfortunately Red Hat popularized this horrible mess by including it in certification.

Combination of Linux software RAID and LVM is especially toxic. As Richard Bullington-McGuire noted (Recovery of RAID and LVM2 Volumes, April 28, 2006 | Linux Journal)

.... j'ai du choper un tuto qu'il fallait pas quand j'ai monté mon raid (d'ailleurs, me souvenait meme plus que j'avais mis du lvm la dessus...)

[keneda212]

et merde ... je sais plus y'a du lvm ou non...

la je viens de redemarrer le truc, y'a plus de lvm...

avec testdisk j'ai reussi a reconstruire une partoche raid ext4.. mais finalement... ca fait rien derriere, et je peux toujours pas la monter...

[keneda212]

bon ben a clore..... mon raid est mort

j'ai reussi a recup des fichiers avec photorec.... mais les données sont pas viables

exemple : je peux recupérer des videos, ca affiche les 4 premières secondes de la video, puis couic, comme si les données dans les autres disques sont décalées....

je peux dire adieu a mes datas....

maintenant faut que je trouve pq j'ai des dd qui lachent (comme ca vient encore de se reproduire)...

aucune erreur sur les dd...

mais comme si l'alimentation lachait, ou le port sata lachait

je suspecte les 2 circuits electriques du rack (un qui gere 3 disques, l'autre 2 disques) ou l'alim

[dudul88]

C'est con. Et la récupération de fichier de testdisk ?

[keneda212]

il a reconstruit la partoche mais je pense que mdadm a refixé le raid avec un offset certains dd, d'ou le décalage...

[keneda212]

Bon je valide la défaillance de l'alimentation sur une broche molex.

Broche qui alimentait un circuit electrique du rack hotswap, sur 3 disques... d'ou mes 2 ou 3 dd hs suivant quand j'ai regardé mon pb de raid...

je suis dégouté....

[dudul88]

Non, mais vraiment, normalement le raid peut être reconstruit sans problème dans ces cas là. Tu as formater les disques, ou on peut encore tenté des trucs ?

[keneda212]

les disques sont encore la, non formaté

si tu as des idées je suis preneur

mon soucis c'est comment reconstruire le raid correctement en fait

[dudul88]

OK, on vas commencé par le commencement. Combien il y avait de disques dans le raid ? Je peux avoir le "cat /proc/mdstat" et un "mdadm -D /chemin/vers/le/raid", pour y voir un peu plus clair ?

 

J'ai pas compris du coup s'il y avait du lvm par au dessus ou pas. Le fstab pourrait être utile aussi.

 

Je ne te promet rien, ça fait longtemps que je n'ai pas touché à mdadm.

[keneda212]

pas de lvm

alors des infos qu'il me reste quand c'est tombé en panne :

j'ai 5 partoches sur 5 dd : sdd1 sdf1 sde1 sdc1 sda1 le tout en raid5

quand il a laché il refusait de se remonter. L'event count n'était plus le meme sur les 2 dd qui ont lachés a cause de l'alim

j'ai trouvé sur le net une commande pour réassembler avec le -force (j'aurai peut etre pas du)

 

mdadm: forcing event count in /dev/sdd1(0) from 86476 upto 86491mdadm: forcing event count in /dev/sde1(2) from 86476 upto 86491mdadm: /dev/md0 has been started with 5 drives.

Une fois fait ca j'ai eu le droit a

mdadm --misc --scan --detail /dev/md0/dev/md0:        Version : 1.2  Creation Time : Thu Jan 24 19:44:49 2013     Raid Level : raid5  Used Dev Size : -1   Raid Devices : 5  Total Devices : 2    Persistence : Superblock is persistent    Update Time : Wed Jul 16 19:18:57 2014          State : active, FAILED, Not Started  Active Devices : 2Working Devices : 2 Failed Devices : 0  Spare Devices : 0         Layout : left-symmetric     Chunk Size : 512K           Name : spooky:0  (local to host spooky)           UUID : 63496fde:cc00e935:c85c8db7:582bddb8         Events : 86491    Number   Major   Minor   RaidDevice State       7       8       49        0      active sync   /dev/sdd1       1       0        0        1      removed       2       8       65        2      active sync   /dev/sde1       3       0        0        3      removed       4       0        0        4      removed

Donc j'ai lu sur le net qu'on pouvait recreer le raid sans peter les données

 

 > mdadm --create --assume-clean --level=5 --chunk 512 --raid-devices=5 /dev/md0 /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1mdadm: /dev/sda1 appears to be part of a raid array:    level=raid5 devices=5 ctime=Thu Jul 17 12:31:54 2014mdadm: /dev/sdc1 appears to be part of a raid array:    level=raid5 devices=5 ctime=Thu Jul 17 12:31:54 2014mdadm: /dev/sdd1 appears to be part of a raid array:    level=raid5 devices=5 ctime=Thu Jul 17 12:31:54 2014mdadm: /dev/sde1 appears to be part of a raid array:    level=raid5 devices=5 ctime=Thu Jul 17 12:31:54 2014mdadm: /dev/sdf1 appears to be part of a raid array:    level=raid5 devices=5 ctime=Thu Jul 17 12:31:54 2014Continue creating array? ymdadm: Defaulting to version 1.2 metadatamdadm: array /dev/md0 started.

C'est la que j'ai pas pigé le truc car il m'a sorti ensuite quand j'ai tenté de monter la partoche

 

mount     : type de système de fichiers «     LVM2_member     » inconnu

la je vois qu'il crois a du lvm donc j'ai fais du

 

sudo pvscan sudo vgscan sudo lvscan

ca a trouvé une partoche que j'ai toujours pas reussi a monter

 

mount   : mauvais type de système de fichiers, option erronée, superbloc        erroné sur /dev/mapper/spooky-data, page de code ou aide manquante, ou autre erreur       Dans quelques cas certaines informations sont utiles dans syslog — essayez       «   dmesg | tail   » ou quelque chose du genreJul 18 12:22:42 spooky kernel: [   84.090184] EXT4-fs (dm-0): VFS: Can't find ext4 filesystemJul 18 12:22:42 spooky kernel: [   84.098740] EXT2-fs (dm-0): error: can't find an ext2 filesystem on dev dm-0.Jul 18 12:22:49 spooky kernel: [   90.665995] EXT4-fs (dm-0): VFS: Can't find ext4 filesystem

A la suite d'un reboot, ou les 2 dd ont encore laché, ca s'est remonté mais sans le LVM (et je suis presque sur que j'avais pas mis de LVM dessus)

donc depuis j'ai un raid activé mais en read only

 

Personalities : [raid6] [raid5] [raid4] md0 : active (auto-read-only) raid5 sda1[0] sdf1[4] sde1[3] sdd1[2] sdc1[1]      11720534016 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [uUUUU]      unused devices: <none>

(le soucis c'est que je sais pas s'il était comme ca avant... un chunk peut etre différent ?

[dudul88]

Ah oui. Je sais pas trop ce qu'à fait le mdadm --create --assume-clean. S'il y a un truc de foutu c'est à cause de ça. Et si tu désassemble tout et que tu fais un "mdadm --assemble -u 63496fde:cc00e935:c85c8db7:582bddb8 -f /dev/md0" ?

[keneda212]

https://raid.wiki.kernel.org/index.php/RAID_Recovery

j'ai testé ta commande, ca fait rien. ni erreur, ni montage. dans les logs je vois qu'il tente d'envoyer des infos aux partoches mais ... rien

[dudul88]

Bon, sapu quand même. Du coup de mdadm --examine sur toutes les partoches donne quoi ?

[keneda212]

avant, ca donnait justement qu'il y avait 2 dd avec un count event différent (enfin 3 vu qu'il donnait après le "reset" les 2 dd corrigés ok mais pas les 3 autres)

depuis que j'ai tout recréé, ils sont tous identiques, niquel avec le raid remonté...

 

/dev/sda1:          Magic : a92b4efc        Version : 1.2    Feature Map : 0x0     Array UUID : 403f0926:d21c06cb:71d0de82:6d5eeead           Name : spooky:0  (local to host spooky)  Creation Time : Sun Jul 20 20:56:24 2014     Raid Level : raid5   Raid Devices : 5 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)     Array Size : 11720534016 (11177.57 GiB 12001.83 GB)  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)    Data Offset : 262144 sectors   Super Offset : 8 sectors          State : clean    Device UUID : 651dd16a:180abfc9:24a50842:ea4d0b0a    Update Time : Sun Jul 20 20:56:24 2014       Checksum : 4d8e30a9 - correct         Events : 0         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 0   Array State : AAAAA ('A' == active, '.' == missing)/dev/sdc1:          Magic : a92b4efc        Version : 1.2    Feature Map : 0x0     Array UUID : 403f0926:d21c06cb:71d0de82:6d5eeead           Name : spooky:0  (local to host spooky)  Creation Time : Sun Jul 20 20:56:24 2014     Raid Level : raid5   Raid Devices : 5 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)     Array Size : 11720534016 (11177.57 GiB 12001.83 GB)  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)    Data Offset : 262144 sectors   Super Offset : 8 sectors          State : clean    Device UUID : 135d850d:214c3d95:d2271d77:d685457d    Update Time : Sun Jul 20 20:56:24 2014       Checksum : 640f6cfb - correct         Events : 0         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 1   Array State : AAAAA ('A' == active, '.' == missing)/dev/sdd1:          Magic : a92b4efc        Version : 1.2    Feature Map : 0x0     Array UUID : 403f0926:d21c06cb:71d0de82:6d5eeead           Name : spooky:0  (local to host spooky)  Creation Time : Sun Jul 20 20:56:24 2014     Raid Level : raid5   Raid Devices : 5 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)     Array Size : 11720534016 (11177.57 GiB 12001.83 GB)  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)    Data Offset : 262144 sectors   Super Offset : 8 sectors          State : clean    Device UUID : 0bd2af3e:0c4919f4:680bdcce:4370a2b4    Update Time : Sun Jul 20 20:56:24 2014       Checksum : 8331ace3 - correct         Events : 0         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 2   Array State : AAAAA ('A' == active, '.' == missing)/dev/sde1:          Magic : a92b4efc        Version : 1.2    Feature Map : 0x0     Array UUID : 403f0926:d21c06cb:71d0de82:6d5eeead           Name : spooky:0  (local to host spooky)  Creation Time : Sun Jul 20 20:56:24 2014     Raid Level : raid5   Raid Devices : 5 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)     Array Size : 11720534016 (11177.57 GiB 12001.83 GB)  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)    Data Offset : 262144 sectors   Super Offset : 8 sectors          State : clean    Device UUID : 6b936024:ca27d2cc:5faa893a:c0c76918    Update Time : Sun Jul 20 20:56:24 2014       Checksum : 11104375 - correct         Events : 0         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 3   Array State : AAAAA ('A' == active, '.' == missing)/dev/sdf1:          Magic : a92b4efc        Version : 1.2    Feature Map : 0x0     Array UUID : 403f0926:d21c06cb:71d0de82:6d5eeead           Name : spooky:0  (local to host spooky)  Creation Time : Sun Jul 20 20:56:24 2014     Raid Level : raid5   Raid Devices : 5 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)     Array Size : 11720534016 (11177.57 GiB 12001.83 GB)  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)    Data Offset : 262144 sectors   Super Offset : 8 sectors          State : clean    Device UUID : 256301fa:7a4ed368:264a4d8a:d821facd    Update Time : Sun Jul 20 20:56:24 2014       Checksum : 880633c0 - correct         Events : 0         Layout : left-symmetric     Chunk Size : 512K   Device Role : Active device 4   Array State : AAAAA ('A' == active, '.' == missing)

j'ai tenté avec du default (128) ou du 256 .. j'arrive pas a avoir les fichiers non plus.

Ce qui est marrant qu'est qu'en 512 (je crois que j'étais en 512 avant), j'arrive a avoir une a deux seconde d'une video puis plus rien, car surement déphasé avec les autres dd

[dudul88]

Ton mdadm --create a recréer un truc inutilisable. Tu ne peux rien faire avec ça. Tu as sauvegardé tes superblocks avant de le faire ?

[keneda212]

vu que je sais pas ce que c'est qu'un superblock non...

j'ai fais que suivre le wiki que j'ai linké un peu plus haut :/

[dudul88]

Donc le première chose qui est mise dans le wiki c'est "mdadm --examine /dev/sd[acdef]1 >> raid.status" (ce que tu viens de faire mais redirigé dans un fichier).

[keneda212]

je l'ai fais... mais je l'ai pas stocké....

je pensais que le mdadm --misc --scan --detail /dev/md0 suffisait pour avoir les infos

[dudul88]

Bon, c'est pas grave, mais ça va être chiant. Le principal problème qu'on a à cette heure ci c'est qu'on ne sait pas l'ordre des disque d'origine. On connait le premier (/dev/sdd1) et le 3ème (/dev/sde1) mais pas le reste. Et lorsque tu as recréé la grappe il a remis dans l'ordre des lettres, donc ça va pas.

 

Ce qu'il te reste à faire c'est "mdadm --create --assume-clean --level=5 --chunk 512 --raid-devices=5 /dev/md0 /dev/sd[dXeXX]1" avec a, c et f à la place des X. Et puis t'essayes toutes les possibilité jusqu'à avoir un système de fichier cohérent. (tu essayes de récupérer ta vidéo avec testdisk, et s'il elle est complète c'est bon, tu peux faire un fsck et le tour est joué).

 

Vérifie quand même à chaque fois que ça permute bien les disques avec mdadm -D, je ne suis plus sûr de moi.

[keneda212]

hum... l'ordre des disques dans le fichier /etc/mdadm/jesaisplusquoi.conf serai le bon ?

parce que celui ci, je l'ai encore (en commenté)

[dudul88]

Ouaip, s'il n'a pas été modifié entre temps... Regarde par rapport aux disques qu'on connait.

[keneda212]

Ce qu'il te reste à faire c'est "mdadm --create --assume-clean --level=5 --chunk 512 --raid-devices=5 /dev/md0 /dev/sd[dXeXX]1" avec a, c et f à la place des X. Et puis t'essayes toutes les possibilité jusqu'à avoir un système de fichier cohérent

sauf que les disques changent de lettre a chaque reboot ... d'ou le fait que j'avais mis les vrai nom de disques dans le fichier de conf

... mais ca marche pas non plus ...

j'ai l'ordre quand c'est tombé en panne : sdd1 sdf1 sde1 sdc1 sda1 .... sauf que vu que les disques ont changé d'ordre depuis.. je l'ai dans le cul ...

[keneda212]

dans l'ordre d'origine (enfin celui que je pense) j'ai pu récupérer bien plus de fichier qu'avant (2x plus environ) et encore, j'ai eu un fs full.

Par contre, toujours pas lisible ...

[theocrite]

Tu peux utiliser la commande blkid pour vérifier l'uuid des disques.

 

La partition raid doit avoir le même uuid. Si tu as une autre partition à côté sur chaque disque ça peut t'aider à identifier tes disques.

 

Sinon hdparm.

[dudul88]

Ça va pas vraiment nous avancer d'avoir l'uuid des disques puisque de toute façon sans le résultat de "mdadm --examine "/dev/sd[acdef]1" avant de tenter de recréer le raid, on ne saura pas quel uuid correspond à quel numéro du raid.

 

La seule chose qu'il reste à faire, c'est de tenter ce script perl.