Raid 5 dégradé !

Support Debian
#1

Bonjour, je viens de me rendre compte que mon raid5 venait de passer en dégradé le 27/11 !

This is an automatically generated mail message from mdadm
running on raid6

A Fail event had been detected on md device /dev/md127.

It could be related to component device /dev/sdd1.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md127 : active raid5 sdf1[3] sdb1[1] sdd1[0](F)
        1953260544 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
        bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>



root@raid:# mdadm --detail --verbose /dev/md127 
/dev/md127:
        Version : 1.2
  Creation Time : Fri Sep 29 06:44:43 2017
     Raid Level : raid5
     Array Size : 1953260544 (1862.77 GiB 2000.14 GB)
  Used Dev Size : 976630272 (931.39 GiB 1000.07 GB)
   Raid Devices : 3
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Wed Dec  6 05:51:08 2017
          State : clean, degraded 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K
 
           Name : raid6:2  (local to host raid6)
           UUID : f1a0ef99:ea007236:03204e21:ceca4abf
         Events : 13858

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       17        1      active sync   /dev/sdb1
       3       8       81        2      active sync   /dev/sdf1

Il me manque la partition sdd1, pourtant le disque est bien visible dans l’utilitaire de disque.
Le SMART est bon : c’est un disque que j’ai acheter reconditionner chez LDLC, il a 2 mois d’heure de fonctionnement.
Je ne sais pas pourquoi il ne veut pas faire parti du raid :confused:
J’ai lu qu’il ne faut pas faire n’importe quoi dans cette situation, pour éviter de supprimer les données.
J’ai essayé un

root@raid:# mdadm /dev/md127 –add /dev/sdd1
mdadm: An option must be given to set the mode before a second device
       (–add) is listed

et la je reste bloqué ne voulant pas faire de conneries

Sinon le raid est toujours accessible en r/w

#2

C’est presque que ça :

Voir le man de mdadm ou bien trouvé un article wiki comme celui-ci (selon le type de table de partition) :

https://fr.ikoula.wiki/fr/Reconstruction_d'un_raid_software_avec_table_de_partition_en_GPT
https://fr.ikoula.wiki/fr/Reconstruction_d'un_raid_software_avec_table_de_partition_en_MSDOS

Par contre la table de partition a t’elle déjà été importé sur le disque à ajouté au raid ?
De ce que je vois non, donc mdadm ne parviendra pas à reconstruire le raid si il n’a pas un emplacement précisé pour copier les données.

Attention au moment de la copie de la table de partition de pas se tromper de sens dans la copie :stuck_out_tongue:

#3

Merci de ta réponse :wink:

cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md127 : active raid5 sdd[4] sdf1[3] sdb1[1]
      1953260544 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
      [>....................]  recovery =  0.2% (2433052/976630272) finish=269.8min speed=60166K/sec
      bitmap: 7/8 pages [28KB], 65536KB chunk

unused devices: <none>

Donc c’est partie pour 270 minutes c’est plutôt rapide et je peut toujours accéder a mes donnée en même temps.
ce qui est bizarre c’est que j’ai crée le raid il y a quelques semaines et je n’ai pas changer de disque et il n’est pas hs donc pourquoi je dois recréer la somme de contrôle ?

#4

Sans analyse plus approfondie je ne pourrais t’en dire plus, mais le premier retour que tu nous fourni montre la partition ssd1 en dehors du raid.

Pour qu’une partition soit retiré d’un raid il faut un événement majeur tel que le décès du disque ou tout du moins sa non réponse.
Au travail nous avons eu des cas assez atypique de disque sortie de raid matériel ou software, des nappes mal branché qui se déconnecte avec les vibration ou une manipulation du châssis du serveur.
Des contrôleur raid physiques qui dégage des disques suite à des retards de communication ou des incompatibilité de disques (ssd en l’occurrence).
Les causes peuvent être nombreuses à toi de faire un check approfondie des logs pour voir :wink:

#5

ok, es que c’est possible que ce soit du a un changement de port sata suite a un clean du serveur ?
sinon quel log je dois voir ?

#6

oh que oui mais si tu avait intervertis plusieurs disques ton raid ne serait pas remonté.

Si tu as par contre simplement rebrancher sur une autre prise ce disque alors là oui c’est largement suffisant pour le rendre étranger à la configuration du raid et le sortir de celui-ci.

Généralement je travaille sur des châssis rack donc à moins de se tromper de panier … et le peu de châssis plus traditionnel nous ne faisons que du raid 1 ou 0 donc ça limite les risques de se tromper dans un raid.

Lors du démontage d’un serveur pour ne pas risquer de se tromper il est sans doute avisé d’étiqueté les disques, lors du branchement il y aura moins de souci ;), et idem pur les switch/routeur.

#7

après c’est pas vraiment un serveur c’est juste un cm avec quelques disque , mais oui c’est bizarre , normalement c’est identifié par un uuid et je crois que c’est le cas

#8

Non, non !
Il fallait mettre la partition sdd1 et non le disque entier sdd. On n’utilise pas un disque entier partitionné comme membre d’un ensemble RAID.
Maintenant le disque entier contient à la fois un superbloc RAID et une table de partition définissant une partition contenant aussi un superbloc RAID (différent mais du même ensemble RAID). Risque de confusion maximum. Et en prime si la table de partition du disque est au format GPT, le nouveau superbloc a été placé en plein milieu de celle-ci et en a écrasé une partie.

Faux et faux (sauf si on l’a fait à chaud évidemment). La détection et l’assemblage des membres d’ensemble RAID se base sur des UUID, donc peu importe leur position physique.

#9

Salut pascal :wink:
Donc c’est quoi le problème maintenant ?

fdisk -l

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disque /dev/sdd : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 5D7A3720-45CD-4E9B-910E-97D1F7C6C55F

Périphérique Start        Fin   Secteurs   Size Type
/dev/sdd1     2048 1953525134 1953523087 931,5G RAID Linux

Que dois-je faire ???

#10

un simple mdadm --manage --add /dev/md127 dev/sdd1
ou reformater le disque et le ré ajouter ?

Sinon la recréation (enfin l’ajout du disque) n’a pris que 3-4h pour 1To je pensais que ça prendrait plus de temps que ça.

#11

Autant pour moi pour l’oubli de la partition, mais que je rassure Pascal je ne proposais pas à ce moment là d’ajouter le disque entier mais bien la partition, sans doute un oubli de ma part ou une mauvaise frappe sur le clavier.

J’ai plus l’habitude de travailler avec le serveur en marche qu’a l’arrêt.

#12

Le problème, c’est ce que j’ai expliqué et dont tu vois une conséquence : table de partition GPT primaire corrompue par l’écriture du superbloc RAID en plein milieu de celle-ci.

Tu as trois options :

  1. Ne rien faire. Ça peut continuer à marcher. Ou pas, et un jour le système peut décider que la table de partition GPT prend le pas sur le superbloc RAID et empêcher l’assemblage de ce disque.

  2. Effacer les signatures de table de partition DOS et GPT du disque sdd (pas la table entière, sinon tu effaces aussi le superbloc RAID qui occupe le même emplacement). Le disque sdd apparaîtra alors comme non partitionné, et utilisé en entier comme membre RAID. Avantage : rapidité. Inconvénient : la structure de sdd sera différente de celle des deux autres disques.

  3. Retirer le disque sdd de l’ensemble RAID, effacer le superbloc RAID de sdd, restaurer la table de partition primaire de sdd à partir de la table de partition de secours, et ajouter la partition sdd1 à l’ensemble RAID, ce qui relancera une reconstruction complète. Avantage : sdd aura la même structure d’origine que les deux autres disques. Inconvénient : long (reconstruction), et l’ensemble RAID reste dégradé pendant la reconstruction donc s’il perd encore un disque il est mort.

#13

Je vois, la seconde option me tente plus, tu a un lien qui explique cette manip ? et quel est inconvénient d’avoir une structure différente ?

#14

“J’étais sûr que vous diriez ça !” (saurez-vous retrouver de quel film cette réplique est tirée ?)
Pour effacer les deux premiers secteurs du disque contenant le MBR et la signature GPT :

dd if=/dev/zero of=/dev/sdd bs=512 count=2

Attention : bien s’assurer avant que le disque à traiter est bien vu comme sdd. Cela peut changer d’un démarrage à l’autre.

(il y a un autre moyen plus “soft” avec wipefs, mais c’est plus compliqué)

  1. C’est moche, dissymétrique, pas harmonieux.

  2. Un disque sans table de partition, je trouve que c’est risqué même si une table de partition n’est pas obligatoire (du moins pour Linux). On finit par se demander ce qu’il contient et on peut croire à tort qu’ils ne contient rien puisqu’il n’y a aucune partition. Certains logiciels de gestion des disques “bien intentionnés” pourraient même proposer lourdement d’y créer une table de partition, écrasant une partie de son contenu.
    Inversement, quand un disque contient une partition de type Linux RAID, on sait tout de suite qu’il est membre d’un ensemble RAID logiciel.

#15

Judge Dredd ? (meme si je ne l’ai pas vu :stuck_out_tongue: )

Bon je ne sais pas quoi prendre finalement entre la seconde et troisième: je me tâte :smiley:

#16

Bravo !

Techniquement, l’option 2 est parfaitement valide (du moins avec Linux). Ses inconvénients sont dus au facteur humain.
Mais même si une commande comme blkid peut détecter le type de contenu d’un disque partitionné ou non, l’expérience montre qu’on utilise plus volontiers un outil comme fdisk pour examiner un disque.

#17

Bon j’ai fait un dd if=/dev/zero of=/dev/sdd bs=512 count=2 du coup après il se passe quoi ? tout rentre dans l’ordre comme par magie ? :smiley:

Sinon le mdstat renvoie bien les 3 UUU

#18

Après tu peux vérifier que les signatures de tables de partitions ont disparu mais pas le superbloc RAID.

wipefs /dev/sdd
fdisk -l /dev/sdd
mdadm --examine /dev/sdd
#19

Yes ! merci Pascal et Clochette pour votre aide !

Disque /dev/sdd : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
# mdadm --examine /dev/sdd
/dev/sdd:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 
           Name : raid6:2  (local to host raid6)
  Creation Time : Fri Sep 29 06:44:43 2017
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 1953263024 (931.39 GiB 1000.07 GB)
     Array Size : 1953260544 (1862.77 GiB 2000.14 GB)
  Used Dev Size : 1953260544 (931.39 GiB 1000.07 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=2480 sectors
          State : clean
    Device UUID : 
Internal Bitmap : 8 sectors from superblock
    Update Time : Fri Dec  8 02:54:40 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : ac8cb011 - correct
         Events : 15974

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAA ('A' == active, '.' == missing, 'R' == replacing)
#20

Bon j’ai peut être parler trop vite …

# mdadm --examine /dev/sdd
mdadm: No md superblock detected on /dev/sdd.

j’ai encore perdu le même disque !