Restaurer données du DD LINUX RAID (pb sur super bloc)

[--RV--]

Bonsoir,
Manière de montrer que suis impressionner par la rapidité du nouveau IXIUS.NET je me permet de poser ici une question (posée par ailleurs en vain) en espérant le passage d'un amiral :

Je souhaite récupérer les données de l'un des disque miroirs de ma précédente install sme (système cassé avec la maladresse du débutant : sans backup).
A priori, je ne peux pas re-monter ce dd sur le "nouveau" sme car cela crée un conflit - sme cherchant à associer ce disque en RAID1.
J'ai donc décidé de connecter ce disque (sda) à un poste sous mandrakelinux10.1 ; mais je n'arrive pas à le "monter" :

mount : renvoi une erreur de vfstype ; or j'ai choisi ext3 ce qui me semble le filesysteme pour Linux Raid Autodect.
e2fsck : renvoi à l'erreur suivante "bad magic number in super block" ; or il n'y a pas de pb harware sur le disque en lui-même.

nota : dans un post en anglais (pris sur contribs ... je ne sais pas faire la citation complète) sous, le titre "Migrating a Raid 1 to bigger harddisks on SME using Knoppix"
je relève ceci :

"Step-6 - resize filesystem
When we created the raid device, the physical partion became slightly smaller because a second superblock is stored at the end of the partition.
If you reboot the system now, the reboot will fail with an error indicating the superblock is corrupt.

Resize them prior to the reboot
You will be required to fsck each of the md devices except the swap device. The -f flag is required to force fsck to check a clean filesystem. This will generate the same error about inconsistent sizes and possibly corrupted superblock. Say N to 'Abort?'.
# e2fsck -f /dev/md0
# e2fsck -f /dev/md1
# resize2fs /dev/md0
# resize2fs /dev/md1
Check again to be sure. Should be no errors now."

Je suis débutant donc pour moi c'est l'explication de mon problème.
Est-ce bien le cas ?
Est-ce que le redimentionnement ne risque pas d'écraser certaines données ?

@ vous lire

[Gaston]

Salut,
peut-être pas une bonne nouvelle, mais sur mon serveur de prod j'ai déjà perdu des disques et le mirroir a toujours bien fonctionné.
Donc si au moins un des deux disques du miroir n'est pas altéré, tu dois pouvoir booter dessus : fais toi une config lilo ou grub adéquate.
Je n'ai pas encore essayé de monter un disque de miroir sur une autre machine, je ne peux donc pas vraiment t'aider pour ton pb (mais je ne vois pas pourquoi tu ne peux pas monter le disque ...

G.

[--RV--]

Merci pour tes encouragements.

En fait aucun disque n'est altéré : j'ai mis la pagaille dans en sme en essayant d'installer un rmp (custombackup) non compatible avec ma version sme7beta.
Du cout, ça boot mais ça plante et je ne reprends pas la main => j'ai conservé le disque 1 et fait une nouvelle installation de sme7beta sur le 2, en espérant que je pourai ensuite récupérer mes données les stocker sur un troisième dd puis relancer sme en RAID avec les 2 disques sata importer les données sauvegardées etc ... (je suis pas sûr d'être très clair)

j'ai essayé les commandes du post en anglais = sans succès.
Retrour à la case départ : comment monter un dique partitionné en Linux raid autodetect ?

Quelsques infos techniques (sda1 étant la partition de boot de sme - que je peuxc monter sans difficultés - sda2 étant la partition raid1 crée par sme)

[root@localhost /]# fdisk -l /dev/sda
Disque /dev/sda : 164.6 Go
255 têtes, 63 secteurs/piste, 20023 cylindres
Périphérique Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 fd Linux raid autodetect
/dev/sda2 14 20023 160730325 fd Linux raid autodetect

[root@localhost /]# mke2fs -n /dev/sda1
mke2fs 1.35 (28 feb-2004)
Filesystem label =
OS type : Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
26104 inodes, 104388 blocks
5219 blocks (5.00%) reserved for the super user
First data block=1
13 block groups
8192 blocks per group, 8192 fragments per group
2008 inodes per group
Superblock backups stored on blocks :
8193, 24577, 40961, 57345, 73729

[root@localhost /]# mke2fs -n /dev/sda2
mke2fs 1.35 (28 feb-2004)
Filesystem label =
OS type : Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
20103168 inodes, 40182581 blocks
2009129 blocks (5.00%) reserved for the super user
First data block=0
1227 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks :
32768, 98304, 163840 , 229376, 294912 ]....

Hors la taille des 2 partitions, j'ai surligné des différences en rouge ... est-ce là que réside mon problème de superblock ?
@ lire et tester vos idées.

[Franck78]

Salut,
La première idée qui vient est google sur le message "bad magic...block". Au hazard:

https://listman.redhat.com/archives/ext ... 00018.html

Le principe est de rechercher le superbloc suivant si vraiment le premier est malade. Mais il faut être absolument sur de ce qu'était le disque !

C'est quoi l'intérèt de tes deux mke2fs? C'est un disque vierge?

[---rv---]

Oui j'ai aussi cherché mon inspiration sur goggle ... sans autre succés.

Il semble qu'il fallait résoudre la couche raidlinux pour accéder à la couche ext3 etc ... bref trop comliqué pour moi donc j'ai cédé ma place à un cousin qui a distance à pu retauré mes fichiers.

Fin d'un problème (dont je ne connais pas la solution).

[merlin2000]

salut a tous


c est peu etre une reponse de noob mais bon je me lance quand meme as tu essayer de voir si tes partition etaient en vrac avec un soft du type partition magic, je me souvient qu avec ce genre de truc j avait pu recupe un disque mal en point qui me plantait un serverveur raid 5 mirorré ( un raid5 mirroir d un autre) bin oui y a des parano partout lol et si j avais le sous je ferais bien pareil lol.