[résolu] mon raid5 ne veut plus se monter

Support Debian
#1

Bonjour !!

J’en appelle aux bruts chevelus et barbus ! aux acharnés de la CLI. J’ai un gros soucis !!

Je suis sous Debian 7, avec un RAID5 logiciel (3 disques de 2To).
Le RAID5 était quasi rempli, j’ai donc acheté deux nouveaux disques à rajouter.

J’ai ensuite procédé comme suit :

–> les deux disques ont bien été ajoutés

Ensuite :

–> mdadm a restructuré mon RAID5, cela a pris une genre 16h.

Puis ensuite :

Le système de fichiers a alors été agrandi, pour attendre la taille souhaitée (environ 7.2To).

Je précise que j’ai procédé au resize2fs à chaud. Mon système n’étant pas installé sur le RAID5, qui me sert que de stockage (Machines virtuelles, photos raw…)

Tout semblé s’être bien passé. Sauf que maintenant le RAID5 refuse de se monter. J’obtiens l’erreur suivante :

Du coup, je n’accède plus à mes données, et certaines étant très importantes, j’ai peur de tout perdre…
J’avais pourtant maquetté l’opération au préalable sur une autre machine, tout s’était très bien passé…

Du coup, s’il y a des pros du mdadm, pour me conseiller, je suis preneur. Je n’ai pour le moment touché a rien, de peur de tout casser…

mon kernel : 3.2.0-4-amd64

Merci d’avance.

édit :
Sur la même machine, j’ai un raid1.
initialement, le RAID1 était /dev/md126

maintenant je vois dans l’utilitaire de disques qu’il s’appelle /dev/dm127 (ce qui était le RAID5…)

puis tenter un assemble --force avec un autre nom ? genre /dev/md1 ??

#2

Reglé !

J’ai essayé de démonter proprement le RAID1 : erreur, j’ai rebooté. Rien.
Dans mdadm.conf j’ai commenté les deux array, un reboot, et tout est rentré dans l’ordre… enfin presque. le md126 est devenu md127 et inversement. J’ai donc inversé les points de montage et c’est good :slightly_smiling:

Merci quand même les gars :wink:

#3

Avant de faire quelque chose de stupide, fais un état des lieux avec

D’autre part, il n’est pas normal que les ensembles RAID soient nommés md126 et md127 et changent de nom à tout bout de champ.

#4

Salut PascalHambourg,

Ils n’ont pas changé à tout bout de champs, cela a juste changé une fois.
Après je te confirme que ce n’est pas très normal en effet.

Mais tout est rentré dans l’ordre.

#5

Ces noms ne sont pas très normaux. Est-ce toi qui les as définis ainsi ? Ces ensembles RAID n’auraient-ils pas été créés par un autre système ?

#6

Re :slightly_smiling:

Non, ils n’ont pas été créé par un autre système.

Aujourd’hui, au reboot du serveur, j’ai droit au problème à nouveau !! :confused:

ARRAY /dev/md/DATA level=raid1 metadata=1.2 num-devices=2 UUID=51f4c448:1548ca93:1e9a221d:574fe99d name=:DATA
devices=/dev/sdf1,/dev/sde1
ARRAY /dev/md/FPS level=raid5 metadata=1.2 num-devices=3 UUID=e9d00ef5:c541a6b9:77b27878:d64af109 name=Srv01:FPS
spares=2 devices=/dev/sdg,/dev/sdh
ARRAY /dev/md/FPS level=raid5 metadata=1.2 num-devices=5 UUID=e9d00ef5:c541a6b9:77b27878:d64af109 name=Srv01:FPS
devices=/dev/sdb1,/dev/sdg1,/dev/sdh1,/dev/sdd1,/dev/sdc1

Mon RAID5 apparait 2 fois !! Mais une fois avec 3 disques…

Je veux bien un peu d’aide pour éviter de tout perdre car là le RAID5 ne veut pas se monter, je reçois l’erreur suivante si j’essaie de le monter vie l’utilitaire de disques :
error assembling array mdadm exited with exit code 1 : superblock on /dev/sdh doesn’t match others - assembly aborted

Merci d’avance

#7

D’où viennent ces lignes ? De [mono]mdadm --examine --scan -v[/mono] ?

Dont seulement deux présents, et qui sont des disques entiers et non des partitions. Tu n’aurais pas fait une fausse manip à un moment donné et intégré ces deux disques entiers comme membres au lieu de leurs partitions ? Il pourrait être instructif d’examiner chaque partition et disque :

Et la sortie de [mono]parted -l[/mono] aussi stp, ou [mono]fdisk -lu[/mono] (de gnu-fdisk si les disques sont au format GPT).

PS : il faudrait peut-être supprimer le “Résolu” dans le titre, non ?

#8

Oui, cela vient de la commande mdadm --examine --scan -v

Non, je n’ai pour ma part jamais intégré de disque entier.
Je m’en souviens car au départ je n’arrivais pas à créer le RAID, car il y avait un soucis d’alignement des partitions (donc j’avais bien utilisé des partitions, et non les disques).

Idem lorsque j’ai récemment ajouté les deux nouveaux disques.

Mais le problème est apparu après passage de Squeeze à Wheezy (juste après la migration, j’ai entamé dans la foulée l’extension du raid…).

Là j’ai reboot, et au bout de la 3eme fois, les RAID se sont bien montés tous les deux. Mais je vois toujours mon RAID5 en “double” avec la commande ci-dessus.

Voici le résultat de mdadm -E /dev/sd*

[code]/dev/sda:
MBR Magic : aa55
Partition[0] : 605284352 sectors at 2048 (type 83)
Partition[1] : 19856048 sectors at 605286400 (type 05)
mdadm: No md superblock detected on /dev/sda1.
/dev/sda2:
MBR Magic : aa55
Partition[0] : 19853312 sectors at 2048 (type 82)
mdadm: No md superblock detected on /dev/sda5.
/dev/sdb:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : c811ce92:5ac76dbe:371ef366:f1c55a8f

Update Time : Sun Feb  1 00:09:56 2015
   Checksum : bc3dd81b - correct
     Events : 9995

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 0
Array State : AAAAA (‘A’ == active, ‘.’ == missing)
/dev/sdc:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : afbe1115:37b89909:67bd9aac:aad763cf

Update Time : Sun Feb  1 00:09:56 2015
   Checksum : f5e26c9 - correct
     Events : 9995

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 1
Array State : AAAAA (‘A’ == active, ‘.’ == missing)
/dev/sdd:
MBR Magic : aa55
Partition[0] : 3907029167 sectors at 1 (type ee)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3907025039 (1863.01 GiB 2000.40 GB)
Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f6fb0dec:ca8a7af1:6ce26ab6:141b4132

Update Time : Sun Feb  1 00:09:56 2015
   Checksum : 3ae89f15 - correct
     Events : 9995

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 2
Array State : AAAAA (‘A’ == active, ‘.’ == missing)
/dev/sde:
MBR Magic : aa55
Partition[0] : 1953520002 sectors at 63 (type fd)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 51f4c448:1548ca93:1e9a221d:574fe99d
Name : :DATA
Creation Time : Thu Sep 13 08:52:14 2012
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1953517954 (931.51 GiB 1000.20 GB)
Array Size : 976758841 (931.51 GiB 1000.20 GB)
Used Dev Size : 1953517682 (931.51 GiB 1000.20 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 2e4ebeee:31c3bc72:ec615fdf:c4bf3f1b

Update Time : Sun Feb  1 00:20:53 2015
   Checksum : 7e638188 - correct
     Events : 1132

Device Role : Active device 1
Array State : AA (‘A’ == active, ‘.’ == missing)
/dev/sdf:
MBR Magic : aa55
Partition[0] : 1953520002 sectors at 63 (type fd)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 51f4c448:1548ca93:1e9a221d:574fe99d
Name : :DATA
Creation Time : Thu Sep 13 08:52:14 2012
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1953517954 (931.51 GiB 1000.20 GB)
Array Size : 976758841 (931.51 GiB 1000.20 GB)
Used Dev Size : 1953517682 (931.51 GiB 1000.20 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : bbcf9dfc:d470e8bd:be94f731:e5909e59

Update Time : Sun Feb  1 00:20:53 2015
   Checksum : 6865b4aa - correct
     Events : 1132

Device Role : Active device 0
Array State : AA (‘A’ == active, ‘.’ == missing)
/dev/sdg:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 3907025072 (1863.01 GiB 2000.40 GB)
Array Size : 3907023872 (3726.03 GiB 4000.79 GB)
Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Data Offset : 4096 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 17412270:7f838eed:e1348eb1:5b885357

Update Time : Fri Jan  2 20:37:05 2015
   Checksum : 37a919fe - correct
     Events : 3510

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : spare
Array State : AAA (‘A’ == active, ‘.’ == missing)
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
Data Offset : 1712 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 3ba1ff7e:1e517720:a90a239a:2617d66d

Update Time : Sun Feb  1 00:09:56 2015
   Checksum : 1c24291e - correct
     Events : 9995

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 4
Array State : AAAAA (‘A’ == active, ‘.’ == missing)
/dev/sdh:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 3907025072 (1863.01 GiB 2000.40 GB)
Array Size : 3907023872 (3726.03 GiB 4000.79 GB)
Used Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Data Offset : 4096 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1dae89e4:76bf80c6:7d74786f:3b32240a

Update Time : Fri Jan  2 20:37:17 2015
   Checksum : f5bdac83 - correct
     Events : 3511

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : spare
Array State : AAA (‘A’ == active, ‘.’ == missing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
Data Offset : 1712 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1ef2defd:ff5897e1:87328aa7:7d4a733d

Update Time : Sun Feb  1 00:09:56 2015
   Checksum : 3927dd19 - correct
     Events : 9995

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 3
Array State : AAAAA (‘A’ == active, ‘.’ == missing)[/code]

#9

Parted -l me répond :

[code]Model: ATA SAMSUNG HD321KJ (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 1049kB 310GB 310GB primary ext3 boot
2 310GB 320GB 10,2GB extended
5 310GB 320GB 10,2GB logical linux-swap(v1)

Model: ATA ST2000DM001-1CH1 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 2000GB 2000GB ext4 Linux filesystem

Model: ATA ST2000DM001-1CH1 (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 2000GB 2000GB ext4 Linux filesystem

Model: ATA WDC WD20EFRX-68A (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 2000GB 2000GB Linux filesystem

Model: ATA Hitachi HDS72101 (scsi)
Disk /dev/sde: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32,3kB 1000GB 1000GB primary raid

Model: ATA Hitachi HDS72101 (scsi)
Disk /dev/sdf: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32,3kB 1000GB 1000GB primary raid

Warning: /dev/sdg contains GPT signatures, indicating that it has a GPT table.
However, it does not have a valid fake msdos partition table, as it should.
Perhaps it was corrupted – possibly by a program that doesn’t understand GPT
partition tables. Or perhaps you deleted the GPT table, and are now using an
msdos partition table. Is this a GPT partition table?
Yes/No?
[/code]

#10

La sortie de [mono]mdadm -E[/mono] montre bien la présence de superblocs RAID 1.2 sur les disques /dev/sdg et /dev/sdh et aussi sur leurs partitions /dev/sdg1 et /dev/sdh1 avec le même UUID et nom d’ensemble. En regardant les dates d’uptime, le nombre de membres et la taille de l’ensemble dans les différents superblocs, on voit que ce sont ceux de /dev/sdg et /dev/sdh qui ne collent pas avec les autres. Ils sont indiqués comme spare et a priori inutilisés, mais je voudrais confirmer avec le contenu de [mono]/proc/mdstat[/mono] ou la sortie de [mono]mdadm -D /dev/md126[/mono] (ou 127, selon lequel est le RAID 5).

Si c’est confirmé, il faudrait effacer les superblocs sur ces deux disques. Normalement la commande [mono]mdadm --zero-superblock[/mono] sert à cela mais comme il est probable que les structures RAID du disque et de la partition se recouvrent, j’ai peur que cela efface aussi le début du superbloc de la partition. C’est pourquoi j’ai demandé l’organisation des partitions des disques.

La sortie de parted est incomplète, il manque le contenu de /dev/sdg et /dev/sdh, les plus intéressants.
Essaie individuellement pour chaque disque :

parted /dev/sdg unit s print parted /dev/sdh unit s print
Quand parted demande si la table est GPT, réponds “yes”, relance la commande et réponds “no” pour avoir les deux versions. S’il n’affiche rien (je l’ai déjà constaté dans ce genre de situation), essaie avec fdisk :

fdisk -lu /dev/sdg fdisk -lu /dev/sdh

#11

/proc/mdstat :

[code]Personalities : [raid6] [raid5] [raid4] [raid1]
md126 : active raid1 sdf1[0] sde1[1]
976758841 blocks super 1.2 [2/2] [UU]
[===>…] check = 15.2% (149261120/976758841) finish=124.4min speed=110796K/sec

md127 : active raid5 sdb1[0] sdg1[4] sdh1[5] sdd1[3] sdc1[1]
7814047744 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/5] [UUUUU]
[=>…] check = 7.9% (155664500/1953511936) finish=259.0min speed=115673K/sec

unused devices:
[/code]

Et la fin de parted -l (avec la réponse Yes)

[code]Warning: /dev/sdg contains GPT signatures, indicating that it has a GPT table.
However, it does not have a valid fake msdos partition table, as it should.
Perhaps it was corrupted – possibly by a program that doesn’t understand GPT
partition tables. Or perhaps you deleted the GPT table, and are now using an
msdos partition table. Is this a GPT partition table?
Yes/No? yes
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted’s rescue feature to recover partitions.

Warning: /dev/sdh contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted – possibly by a program that doesn’t understand GPT
partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table?
Yes/No? yes
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted’s rescue feature to recover partitions.

Model: Linux Software RAID Array (md)
Disk /dev/md127: 8002GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number Start End Size File system Flags
1 0,00B 8002GB 8002GB ext4

Model: Linux Software RAID Array (md)
Disk /dev/md126: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number Start End Size File system Flags
1 0,00B 1000GB 1000GB ext4
[/code]

Le fdisk -lu /dev/sdg :

[code]WARNING: GPT (GUID Partition Table) detected on ‘/dev/sdg’! The util fdisk doesn’t support GPT. Use GNU Parted.

Disk /dev/sdg: 2000.4 GB, 2000398934016 bytes
80 heads, 63 sectors/track, 775204 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdg1 3584 3907029167 1953512792 fd Linux raid autodetect
[/code]

Le fdisk -lu /dev/sdh :

[code]WARNING: GPT (GUID Partition Table) detected on ‘/dev/sdh’! The util fdisk doesn’t support GPT. Use GNU Parted.

Disk /dev/sdh: 2000.4 GB, 2000398934016 bytes
80 heads, 63 sectors/track, 775204 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdh1 3584 3907029167 1953512792 fd Linux raid autodetect
[/code]

#12

En préambule, la structure atypique des deux disques sdg et sdh me laisse perplexe, sans même parler des superblocs en double.

  • La table de partition au format MBR/MS-DOS mais présence d’une signature GPT, ce qui suggère qu’ils avaient auparavant contenu une table de partition au format GPT (puis ont été repartitionnés au format MBR sans effacer les en-têtes GPT, donc par un outil qui ne gère pas le format GPT).
  • La position de début de la partition à 3584 secteurs au lieu des habituels 63 ou 2048 (1 Mio) comme on voit sur les autres disques.
  • L’offset de début des données dans le superbloc RAID de la partition à 1712 secteurs et dans le superbloc RAID du disque à 4096 au lieu de l’habituel 2048 comme dans les autres superblocs.

Je ne sais qu’en penser, ni comment ce résultat a été obtenu.

Ma première idée pour nettoyer ce bazar serait d’effacer les deux secteurs contenant le superbloc (offset 8 ) et l’en-tête GPT (offset 1) de ces disques avec dd. J’espère ne pas m’être trompé dans les commandes car les conséquences peuvent être désastreuses.

[quote]# copie de sauvegarde des secteurs qu’on s’apprête à effacer
dd count=1 bs=512 if=/dev/sdg of=/root/sdg_super skip=8
dd count=1 bs=512 if=/dev/sdg of=/root/sdg_gpt skip=1
dd count=1 bs=512 if=/dev/sdh of=/root/sdh_super skip=8
dd count=1 bs=512 if=/dev/sdh of=/root/sdh_gpt skip=1

effacement des secteurs

dd count=1 bs=512 if=/dev/zero of=/dev/sdg seek=8
dd count=1 bs=512 if=/dev/zero of=/dev/sdg seek=1
dd count=1 bs=512 if=/dev/zero of=/dev/sdh seek=8
dd count=1 bs=512 if=/dev/zero of=/dev/sdh seek=1[/quote]
Puis vérifier avec [mono]parted -l[/mono], [mono]mdadm -E --scan -v[/mono] et [mono]mdadm -E /dev/sd*[/mono] que tout semble dans l’ordre.

#13

Je dois recevoir demain un autre disque de 2To (que j’ai acheté au cas où un disque lâche, en le laissant dans un placard).

Est-il envisageable sinon de déclarer un des deux fautifs, et le remplacer par un nouveau, puis de faire pareil avec le second et celui que j’ai enlevé ?
Bon c’est chaud car ça me ferait double reconstruction du RAID, mais c’est peut être plus safe non ?

Pour la préparation des disques, j’avais utilisé gdisk en ligne de commande : création d’une table GPT puis création d’une partition tagguée “linux raid”.

Quand je regarde mes 3 disques initials, je les vois pas en “linux raid” mais en “linux filesystem”. Peut être que ça aussi c’est gênant ?

#14

PascalHambourg : étant donné que j’ai maintenant un disque en space, je peux peut être tester ta technique d’effacement des superblocks sur l’un des deux disques en cause, et voir ce que cela donne ? Mais j’aurais toujours le problème de GPT ??

Est-ce mieux de procéder au remplacement des disques ?

Merci d’avance

#15

Le problème de la signature GPT résiduelle n’est pas essentiel, cela perturbe juste parted.

Je ne vois pas trop à quoi te servirait un disque en spare pour tester ma méthode. Tu peux la tester sur un disque à la fois, et seulement si ça foire et l’ensemble est dégradé ajouter le nouveau disque en spare pour reconstruire.

En revanche si tu es patient, tu peux ajouter le nouveau disque en tant que spare, sortir un des deux disque anormaux, (cela va lancer la reconstruction sur le spare), effacer le début du disque (contenant la table de partition et les deux superblocs RAID) recréer une table de partition propre du type de ton choix (GPT pour être cohérent avec les trois premiers) et une partition RAID et l’ajouter en tant que spare. Quand la reconstruction est terminée, tu fais pareil avec l’autre disque anormal.

C’est long (deux reconstructions de 2 To), et il faut espérer qu’aucun disque ne tombe en panne pendant ce temps.

#16

Oui c’est ce que je voulais dire.

N’ayant plus de port SATA dispo, je ne peux pas le mettre tout de suite en spare…
Je pense que je vais essayer d’effacer les superblocks d’un des disque, et ensuite je verrais pour faire le second.

Dis moi, au passage, si je dois intégrer un nouveaux disque, je flag la partition comme “linux raid autodetect” ? Car mes 3 initiaux ne sont pas sous ce flag…

#17

Ce n’est pas utile, surtout avec les partitions RAID au format 1.x. Le type 0xFD (RAID autodetect) sert (ou plutôt servait) pour les partitions RAID au format 0.90 qui devaient être détectées et montées directement par le noyau lui-même. Comme les fonctions RAID sont en modules dans le noyau Debian, ce n’est pas possible et le format par défaut est 1.2 qui ne supporte pas l’auto-assemblage par le noyau. C’est [mono]mdadm[/mono] qui assemble les volumes RAID et il ne se base pas sur le type des partitions mais uniquement sur les superblocs.

La page de manuel de [mono]mdadm[/mono] indique qu’il faudrait utiliser le type 0xDA (non-FS data) pour les partitions RAID d’un disque au format MBR/MS-DOS (non GPT). Pour les partitions d’un disque au format GPT, Wikipédia mentionne un GUID pour les partitions Linux RAID, sans distinction.

#18

OK merci de tes réponses.
je vais tester cela dès que j’aurais un moment.
Je te tiens informé de la suite des évènements.

++

#19

Salut Pascal,

Je viens de faire la manoeuvre d’effacement des superblocks sur mon disque sdg.

Voici ce que me retourne mdadm -E /dev/sdg*

[code]
/dev/sdg:
MBR Magic : aa55
Partition[0] : 3907025584 sectors at 3584 (type fd)
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : e9d00ef5:c541a6b9:77b27878:d64af109
Name : Srv01:FPS (local to host Srv01)
Creation Time : Mon Sep 24 18:26:31 2012
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 3907023872 (1863.01 GiB 2000.40 GB)
Array Size : 7814047744 (7452.06 GiB 8001.58 GB)
Data Offset : 1712 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 3ba1ff7e:1e517720:a90a239a:2617d66d

Update Time : Tue Mar  3 16:52:52 2015
   Checksum : 1c4ca134 - correct
     Events : 10001

     Layout : left-symmetric
 Chunk Size : 512K

Device Role : Active device 4
Array State : AAAAA (‘A’ == active, ‘.’ == missing)[/code]

Cela semble être bon, le sdg n’apparait pas comme membre d’un RAID, et sdg1 oui.
En parallèle, j’accède toujours à mes données…

Dois-je essayer de démonter puis remonter le RAID avant de tenter la manip sur le deuxième disque ?
Merci d’avance

#20

Vérifie aussi avec parted que la table de partition n’a pas été altérée (que la partition existe toujours pour le système ne prouve rien tant que le noyau n’a pas rechargé la table de partition).

J’aurais tendance à être confiant, mais ce ne sont pas mes données.
Si tu veux jouer la sécurité, tu peux arrêter et redémarrage l’ensemble RAID puis vérifier qu’il n’est pas dégradé.