FIRSTHEBERG : souci de RAID et apparition d’un /dev/md126 ou /dev/md127

En gros, pour faire simple, suite à un reboot serveur, on ne peut se reconnecter au serveur et sur la console d’admin (à laquelle on n’a pas accès) on se retrouve avec une impossibilité de monté le volume nécessaire avec un device inexistant ou corrompu. Dans mon cas, /dev/md3 était inexistant.

dev_md3

Après reboot du serveur par les équipes de FIRSTHEBERG, j’ai pu avoir accès au serveur et je me suis rendu compte que seul /dev/md1 était monté malgré le fait que /dev/md3 était mentionné dans le « fstab », ainsi que dans le fichier de conf de « mdadm » (/etc/mdadm/mdadm.conf)
La commande « cat /proc/mdstat » m’indique que /dev/md3 est inexistant mais je vois apparaitre un /dev/md126 !!!!

D’où sort il ce /dev/md126 !!###$$^^##&&**%%§§???

Un « df –h », me confirme la chose … pas de md3 et évidemment pas de md126 car listé dans aucune conf du RAID Soft

df -h

Sys. de fichiers    Taille  Uti. Disp. Uti% Monté sur 
/dev/md1              9,8G  7,7G  1,6G  84% /
tmpfs                 2,0G     0  2,0G   0% /lib/init/rw
udev                   10M  160K  9,9M   2% /dev
tmpfs                 2,0G     0  2,0G   0% /dev/shm

Bref, on se retrouve avec un serveur amputé d’une partie de ses données.

Si je monte le /dev/md126 sur /var, je retrouve toutes mes données. Je me rends compte aussi que l’outil « mdadm », n’est pas installé.
Ayant monté le /var, j’en profite pour lancé la commande « apt-get install mdadm » … pourquoi cet outil est-il absent … bizarre, bonne question, car cet outil est appelé par un script dans « /etc/init.d » … et ce serveur à été souscrit avec cette option de RAID Logiciel dès le départ … « mdadm » devrait être installé et ce n’est pas le cas 🙁

Bref, il est temps de passer aux choses sérieuses.
Pour résumer, j’ai un md126 en lieu et place d’un md3 …
La commande « cat /proc/mdstat » me donne le résultat suivant

cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sdb1[1] sda1[0]
10239936 blocks [2/2] [UU]

md126 : active raid1 sdb3[1] sda3[0]
476097472 blocks [2/2] [UU]

unused devices: <none>

Elle devrait me donner le résultat :

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md1 : active raid1 sdb1[1] sda1[0]
10239936 blocks [2/2] [UU]

md3 : active raid1 sdb3[1] sda3[0]
476097472 blocks [2/2] [UU]

unused devices: <none>

Donc prenons le taureau par les cornes, et je démonte le « /dev/md126 ».
Ce device étant un Raid Soft, j’arrête le Raid sur ce device :

mdadm -S /dev/md126 » (réponse : mdadm: stopped /dev/md126

La commande suivante va checker le raid que mdadm voit :

mdadm --detail –scan

ARRAY /dev/md1 metadata=0.90 UUID=10460d6e:c684efe0:9d4deba6:47ca997f

Maintenant que md126 est stoppé, il va falloir recréer (réassembler le raid) pour md3. Pour cela on récupère les infos qui vont bien.
Dans le fichier « /etc/mdadm/mdadm.conf », on voit les informations du RAID :

cat /etc/mdadm/mdadm.conf

ARRAY /dev/md1 UUID=10460d6e:c684efe0:9d4deba6:47ca997f
ARRAY /dev/md3 UUID=d65cbf89:20217a78:9d4deba6:47ca997f

Avec la commande « blkid », on récupère les BlockID des devices de stockage

blkid

/dev/sdb1: UUID="10460d6e-c684-efe0-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sdb3: UUID="d65cbf89-2021-7a78-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sda1: UUID="10460d6e-c684-efe0-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sda3: UUID="d65cbf89-2021-7a78-9d4d-eba647ca997f" TYPE="linux_raid_member"
/dev/sda2: UUID="1ba0b73e-fde6-4209-a516-2954608c111f" TYPE="swap"
/dev/sdb2: UUID="a119d4cf-5b1a-4f85-a30d-fbc6c48c3a7a" TYPE="swap"
/dev/md1: UUID="cf984d55-82e2-49bb-90b6-a82792149bb9" TYPE="ext4"

On voit très bien quels devices font partis des quels raid.
Ainsi md1 = sdb1 + sda1 et md3 = sdb3 + sda3
Et voici ZE commande pour réassembler le RAID avec les bons devices :

mdadm --assemble --verbose /dev/md3 /dev/sda3 /dev/sdb3

Et la réponse à cette commande :

mdadm: looking for devices for /dev/md3
mdadm: /dev/sda3 is identified as a member of /dev/md3, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md3, slot 1.
mdadm: added /dev/sdb3 to /dev/md3 as 1
mdadm: added /dev/sda3 to /dev/md3 as 0
mdadm: /dev/md3 has been started with 2 drives.

La commande  de scan me donne alors les infos suivantes :

mdadm --detail –scan

ARRAY /dev/md1 metadata=0.90 UUID=10460d6e:c684efe0:9d4deba6:47ca997f
ARRAY /dev/md3 metadata=0.90 UUID=d65cbf89:20217a78:9d4deba6:47ca997f

Et la commande « cat /proc/mdstat » me donne :

cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md3 : active raid1 sda3[0] sdb3[1]
476097472 blocks [2/2] [UU]

md1 : active raid1 sda1[0] sdb1[1]
10239936 blocks [2/2] [UU]

unused devices: <none>

C’est donc tout bon, donc un petit check avec un « fsck /dev/md3 »  et je remonte le /dev/md3 sur /var
Il ne reste plus qu’à lancer la commande : update-initramfs -k all –u
Elle permet de régénérer toutes les images de kernel présentes avec les infos Up2date.

Je reboot et voilà 🙂
C’est fini 😛

Merci qui ?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.