Disque HS sur advance-2

Bonjour,
J'ai un serveur dans un des 2 disques NVME vient de tomber en panne.
Quand je fais un cat /proc/mdstat, j'ai la réponse suivante :

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md2 : active raid1 nvme0n1p2[1]
20478912 blocks [2/1] [_U]
md3 : active raid1 nvme0n1p3[1]
978671552 blocks [2/1] [_U]
bitmap: 8/8 pages [32KB], 65536KB chunk
unused devices:

Donc apparemment, c'est le 1er disque qui est HS.
OVH me propose une intervention pour changer le disque.

Mes craintes sont que le serveur ne redémarre pas en mode normal, pas trop les compétences pour resynchroniser le RAID

Avez vous des expériences dans ce domaine ou des conseils ?
Merci

Pas grand chose à dire…
Si ce n'est :
- Faire une prière.
- Faire un backup complet du système.
- Faire une autre prière en allumant un cierge…

Dans les grandes lignes il va falloir installer grub sur le 1er disque en mode rescue. Ajouter ensuite le nouveau disque au raid pour qu'il se resynchronise.
Eventuellement rebooter de suite, le raid continuera de se rebuild au reboot…

On doit pouvoir ajouter le disque au raid après le reboot, ça peut être + rassurant d'être sur le système "normal" et pas en rescue.
En théorie du moment que GRUB est réinstallé sur le premier disque ça devrait booter sur le raid, même sans que le 1er disque soit réintégré…

Il y a pas mal de docs à ce sujet sur le net.
Dans tous les cas ça reste une opération délicate, stressante et désagréable…
Je l'ai fais quelques fois déjà (pas fait depuis des années, je touche du bois).
Je n'ai jamais eu de soucis, j'ai tjrs pu remonter mes serveurs sans le moindre problème. Mais peu importe le nombre de fois où j'ai pu faire ça, j'ai tjrs eu horreur de ce genre d'intervention…

Un peu de documentation ici:
https://docs.ovh.com/fr/dedicated/raid-soft/

Il faut faire attention, car maintenant ce sont des disques en GPT, il faut donc utiliser l'outil adéquat gfdisk et non plus fdisk, et parted. Si les serveurs sont bootés sous BIOS (et non UEFI), il doit y avoir une petite partition de 1MB de type bios_grub.

Grosso modo d'après le guide, il faut d'abord créer la table de partition (en copiant depuis l'autre disque), faire le makeswap, réinstaller Grub2 (si c'est le premier disque qui est remplacé), puis intégrer le disque dans le RAID, et lancer la reconstruction.

J'avais à l'époque simulé les opérations dans une machine virtuelle pour m'entraîner "au cas où", mais c'est toujours très stressant. Et je crois que j'ai tout oublié, heureusement que j'avais pris quelques notes.

<br /># parted -l<br />Model: VMware, VMware Virtual S (scsi)<br />Disk /dev/sda: 32.2GB<br />Sector size (logical/physical): 512B/512B<br />Partition Table: gpt<br />Disk Flags: pmbr_boot<br /> <br />Number Start End Size File system Name Flags<br /> 1 1049kB 2097kB 1049kB bios_grub<br /> 2 2097kB 31.2GB 31.2GB raid<br /> 3 31.2GB 32.2GB 1049MB linux-swap(v1)<br />

Bon courage !

Merci pour les grandes lignes.
Te confirme que c'est désagréable et stressant.

Pour mon niveau de compétence d'admin proche de 0 et après avoir lu plusieurs doc, voila ce que je vais tenter en me basant sur la doc en adaptant les sda/sdb aux disques nvme

Si j'ai bien compris la doc sda devient nvme1n1, sdb devient nvme0n1
Dans l'exemple sdb (nvme0n1) est sain, sda (nveme1n1) est hs

Etat de mes disques
Disque /dev/nvme0n1 : Ok
Disque /dev/nvme1n1 : plus visible , c'est lui qui va être changé

/dev/md3 : 1002 Go
/dev/md2 : 21 go

Après le changement du disque par ovh , je vais en mode rescue copier la table de partition avec :
sfdisk -d /dev/nvme0n1 | sfdisk /dev/nvme1n1

puis recontruire le raid :
mdadm --add /dev/md2 /dev/nvme1n1p2
mdadm --add /dev/md3 /dev/nvme1n1p3

Si vous voyez une boulette avant que je commence le massacre …

PS : J'ai pris un nouveau serveur en backup sur lequel j'installé les projets au cas ou ça ne redémarre pas :frowning:

Il est recommandé de copier d'abord la table de partition du disque sain sur un fichier:

backup partition table of /dev/sda
sgdisk --backup=/root/sda.partitiontable /dev/sda

Pour restaurer sur un disque sdb:
restore partition table from sda to sdb
sgdisk --load-backup=/root/sda.partitiontable /dev/sdb
(tu peux aussi utiliser la commande indiquée par OVH)


Bien réfléchir et changer sda/sdb en nvmexxx correctement.
Après avoir copié la table de partition sur le nouveau disque, tu peux "dumper" (backuper) sa table
sur un fichier, et vérifier avec un "diff" que c'est identique avec l'autre fichier.

En copiant la table de partition, le disque copié hérite d'un même GUID (disque GPT), il faut lui donner une autre valeur:

To randomize the GUID on the /dev/sdb, enter:
sgdisk -G /dev/sdb
<br /># sgdisk -G /dev/sdb<br />Warning: The kernel is still using the old partition table.<br />The new table will be used at the next reboot.<br />The operation has completed successfully.<br />
Dans ton cas, le disque remplacé n'est pas locké, donc pas de message comme ci-dessus.

Je n'ai pas trop le temps, mais fais attention et comprendre les commandes, qui est le destinataire de la copie, ne pas tromper de syntaxe ou de disque.

Edit:
How to backup and restore a partition table on Linux
https://www.cyberciti.biz/faq/linux-backup-restore-a-partition-table-with-sfdisk-command/

How do I restore GPT partition table from a file?
<br />To restore the backup use:<br /># sgdisk --load-backup&#61;{/path/to/file} {/dev/device/here}<br /># sgdisk --load-backup&#61;/media/usb/sda_partition_table_12_30_2015 /dev/sda<br /> <br />Finally, verify that both hard drives have the same partitioning schema:<br /># sgdisk -p /dev/sda<br /># sgdisk -p /dev/sdb<br /><br />Afficher la sortie de :<br />parted -l<br /># parted /dev/sda unit s print<br />

Je vais surement dire une bêtise mais dans la mesure où vous louez un serveur, pourquoi ne pas carrément en changer? N'est-ce pas plus simple et surtout moins stressant?

Le serveur a un engagement jusque fin 11/2021 (de mémoire +- 120 euros/mois)
J'attends une réponse d'ovh pour savoir si il accepte un transfert de l'engagement sur un nouveau serveur dans la meme config.
Dans ce cas , je migre tout sur le nouveau et je tente la réparation sans stress sur l'ancien avant de le restituer.