# Raid 5 dégradé ! **URL:** \ **Category:** Support Debian\ **Created:** [Décembre 6, 2017, 5:07 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301 "2017-12-06T05:07:32Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 5:07 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/1 "2017-12-06T05:07:32Z")
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: ```  ``` 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 😕 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 ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Décembre 6, 2017, 7:59 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/2 "2017-12-06T07:59:48Z")
C’est presque que ça : ```auto ``` 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%27un_raid_software_avec_table_de_partition_en_GPT) [https://fr.ikoula.wiki/fr/Reconstruction\_d'un\_raid\_software\_avec\_table\_de\_partition\_en\_MSDOS](https://fr.ikoula.wiki/fr/Reconstruction_d%27un_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 😛 ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 9:03 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/3 "2017-12-06T09:03:43Z")
Merci de ta réponse 😉 ``` 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: ``` 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 ? ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Décembre 6, 2017, 9:35 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/4 "2017-12-06T09:35:15Z")
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 😉 ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 9:38 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/5 "2017-12-06T09:38:57Z")
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 ? ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Décembre 6, 2017, 9:49 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/6 "2017-12-06T09:49:50Z")
> [@eliasb](#): > > es que c’est possible que ce soit du a un changement de port sata suite a un clean du serveur ? 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. ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 9:58 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/7 "2017-12-06T09:58:23Z")
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 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 6, 2017, 12:22 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/8 "2017-12-06T12:22:45Z")
> [@Clochette](#): > > mdadm --manage --add /dev/md127 dev/sdd 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. > [@Clochette](#): > > 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. 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. ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 12:58 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/9 "2017-12-06T12:58:27Z")
Salut pascal 😉 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 ??? ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 1:00 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/10 "2017-12-06T13:00:40Z")
> [@PascalHambourg](#): > > mdadm --manage --add /dev/md127 dev/sdd 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. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Décembre 6, 2017, 1:31 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/11 "2017-12-06T13:31:59Z")
> [@PascalHambourg](#): > > 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. 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. > [@PascalHambourg](#): > > 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. J’ai plus l’habitude de travailler avec le serveur en marche qu’a l’arrêt. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 6, 2017, 2:10 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/12 "2017-12-06T14:10:55Z")
> [@eliasb](#): > > Donc c’est quoi le problème maintenant ? 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. ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 2:17 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/13 "2017-12-06T14:17:43Z")
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 ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 6, 2017, 4:11 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/14 "2017-12-06T16:11:22Z")
> [@eliasb](#): > > la seconde option me tente plus « 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é) > [@eliasb](#): > > quel est inconvénient d’avoir une structure différente ? 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. ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 6, 2017, 4:16 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/15 "2017-12-06T16:16:00Z")
> [@PascalHambourg](#): > > J’étais sûr que vous diriez ça ! Judge Dredd ? (meme si je ne l’ai pas vu 😛 ) Bon je ne sais pas quoi prendre finalement entre la seconde et troisième: je me tâte 😃 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 6, 2017, 4:28 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/16 "2017-12-06T16:28:45Z")
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. ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 7, 2017, 1:11 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/17 "2017-12-07T01:11:54Z")
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 ? 😃 Sinon le mdstat renvoie bien les 3 UUU ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Décembre 7, 2017, 10:53 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/18 "2017-12-07T10:53:18Z")
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 ``` ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 8, 2017, 1:57 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/19 "2017-12-08T01:57:04Z")
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) ``` ---
**Author:** ![eliasb](https://www.debian-fr.org/user_avatar/www.debian-fr.org/eliasb/32/2960_2.png) [@eliasb](https://www.debian-fr.org/u/eliasb)\ **Post date:** [Décembre 9, 2017, 2:29 UTC](https://www.debian-fr.org/t/raid-5-degrade/75301/20 "2017-12-09T02:29:04Z")
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 ! [Page suivante](https://www.debian-fr.org/t/raid-5-degrade/75301.md?page=2)