Comment récupérer des données et reconstruire des RAID logiciels défaillants - Partie 8

Dans les articles précédents de cette série RAID, vous êtes passé de zéro à héros RAID. Nous avons passé en revue plusieurs configurations RAID logicielles et expliqué l’essentiel de chacune d’entre elles, ainsi que les raisons pour lesquelles vous pencheriez vers l’une ou l’autre en fonction de votre scénario spécifique.

Dans ce guide, nous allons voir comment reconstruire une matrice RAID logicielle sans perte de données en cas de défaillance d’un disque. Par souci de brièveté, nous ne considérerons qu’une configuration RAID 1, mais les concepts et les commandes s’appliquent à tous les cas de la même manière.

Scénario de test RAID

Avant de poursuivre, assurez-vous d’avoir configuré une matrice RAID 1 en suivant les instructions fournies dans la partie 3 de cette série : Comment configurer RAID 1 (miroir) sous Linux.

Les seules variations dans notre cas actuel seront :

1) une version de CentOS différente (v7) de celle utilisée dans cet article (v6.5), et
2) des tailles de disque différentes pour /dev/sdb et /dev/sdc (8 Go chacune).

De plus, si SELinux est activé en mode d’application, vous devrez ajouter les étiquettes correspondantes au répertoire où vous monterez le périphérique RAID. Sinon, vous rencontrerez ce message d’avertissement lors de la tentative de montage :

Vous pouvez résoudre ce problème en exécutant :


restorecon -R /mnt/raid1

Configuration de la surveillance RAID

Il existe diverses raisons pour lesquelles un périphérique de stockage peut tomber en panne (les SSD ont cependant considérablement réduit les risques que cela se produise), mais quelle qu’en soit la cause, vous pouvez être sûr que des problèmes peuvent survenir à tout moment et vous devez être prêt à remplacer la pièce défectueuse et à garantir la disponibilité et l’intégrité de vos données.

Un conseil d’abord. Même si vous pouvez inspecter /proc/mdstat afin de vérifier l’état de vos RAID, il existe une méthode meilleure et plus rapide qui consiste à exécuter mdadm en mode moniteur + scan, ce qui enverra des alertes par e-mail à un destinataire prédéfini.

Pour configurer cela, ajoutez la ligne suivante dans /etc/mdadm.conf :


MAILADDR user@<domain or localhost>

Dans mon cas :


MAILADDR gacanepa@localhost

Pour exécuter mdadm en mode moniteur + balayage, ajoutez l’entrée crontab suivante en tant que root :


@reboot /sbin/mdadm --monitor --scan --oneshot

Par défaut, mdadm vérifiera les matrices RAID toutes les 60 secondes et enverra une alerte s’il détecte un problème. Vous pouvez modifier ce comportement en ajoutant l’option --delay à l’entrée crontab ci-dessus, ainsi que le nombre de secondes (par exemple, --delay 1800 signifie 30 minutes).

Enfin, assurez-vous d’avoir installé un agent utilisateur de messagerie (MUA), tel que mutt ou mailx. Sinon, vous ne recevrez aucune alerte.

Dans une minute, nous verrons à quoi ressemble une alerte envoyée par mdadm.

Simulation et remplacement d’un périphérique de stockage RAID défaillant

Pour simuler un problème avec l’un des périphériques de stockage de la matrice RAID, nous allons utiliser les options --manage et --set-faulty comme suit :


mdadm --manage --set-faulty /dev/md0 /dev/sdc1

Cela aura pour conséquence que /dev/sdc1 sera marqué comme défectueux, comme nous pouvons le voir dans /proc/mdstat :

Plus important encore, voyons si nous avons reçu une alerte par e-mail avec le même avertissement :

Dans ce cas, vous devrez retirer le périphérique de la matrice RAID logicielle :


mdadm /dev/md0 --remove /dev/sdc1

Ensuite, vous pouvez le retirer physiquement de la machine et le remplacer par une pièce de rechange (/dev/sdd, où une partition de type fd a été précédemment créée) :


mdadm --manage /dev/md0 --add /dev/sdd1

Heureusement pour nous, le système commencera automatiquement à reconstruire le réseau avec la partie que nous venons d’ajouter. Nous pouvons tester cela en marquant /dev/sdb1 comme défectueux, en le supprimant du tableau et en nous assurant que le fichier tecmint.txt est toujours accessible dans /mnt/raid1 :


mdadm --detail /dev/md0
mount | grep raid1
ls -l /mnt/raid1 | grep tecmint
cat /mnt/raid1/tecmint.txt

L’image ci-dessus montre clairement qu’après avoir ajouté /dev/sdd1 au tableau en remplacement de /dev/sdc1, la reconstruction des données a été automatiquement effectuée par le système sans intervention de notre part.

Bien que ce ne soit pas strictement obligatoire, c’est une excellente idée d’avoir un appareil de rechange à portée de main afin que le processus de remplacement de l’appareil défectueux par un bon disque puisse être effectué en un clin d’œil. Pour ce faire, rajoutons /dev/sdb1 et /dev/sdc1 :


mdadm --manage /dev/md0 --add /dev/sdb1
mdadm --manage /dev/md0 --add /dev/sdc1

Récupération d’un sinistre lié à un licenciement

Comme expliqué précédemment, mdadm reconstruira automatiquement les données lorsqu’un disque tombe en panne. Mais que se passe-t-il si 2 disques de la matrice tombent en panne ? Simulons un tel scénario en marquant /dev/sdb1 et /dev/sdd1 comme défectueux :


umount /mnt/raid1
mdadm --manage --set-faulty /dev/md0 /dev/sdb1
mdadm --stop /dev/md0
mdadm --manage --set-faulty /dev/md0 /dev/sdd1

Les tentatives de recréation du tableau de la même manière qu’il a été créé à ce moment-là (ou à l’aide de l’option --assume-clean) peuvent entraîner une perte de données, de sorte qu’il ne faut le laisser qu’en dernier recours.

Essayons de récupérer les données de /dev/sdb1, par exemple, dans une partition de disque similaire (/dev/sde1 – notez que cela nécessite que vous créiez une partition de type fd dans /dev/sde avant de continuer) en utilisant ddrescue :


ddrescue -r 2 /dev/sdb1 /dev/sde1

Veuillez noter que jusqu’à présent, nous n’avons pas touché à /dev/sdb ou /dev/sdd, les partitions qui faisaient partie de la matrice RAID.

Maintenant, reconstruisons le tableau en utilisant /dev/sde1 et /dev/sdf1 :


mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sd[e-f]1

Veuillez noter que dans une situation réelle, vous utiliserez généralement les mêmes noms de périphériques qu’avec la matrice d’origine, c’est-à-dire /dev/sdb1 et /dev/sdc1 après que les disques défaillants ont été remplacés par de nouveaux.

Dans cet article, j’ai choisi d’utiliser des périphériques supplémentaires pour recréer la matrice avec de nouveaux disques et pour éviter toute confusion avec les disques défaillants d’origine.

Lorsqu’on vous demande si vous souhaitez continuer à écrire le tableau, tapez Y et appuyez sur Entrée. Le tableau doit être démarré et vous devez être en mesure de suivre sa progression avec :


watch -n 1 cat /proc/mdstat

Une fois le processus terminé, vous devriez être en mesure d’accéder au contenu de votre RAID :

Résumé

Dans cet article, nous avons vu comment récupérer après des pannes RAID et des pertes de redondance. Cependant, vous devez vous rappeler que cette technologie est une solution de stockage et NE REMPLACE PAS les sauvegardes.

Les principes expliqués dans ce guide s’appliquent à toutes les configurations RAID, ainsi qu’aux concepts que nous aborderons dans le prochain et dernier guide de cette série (gestion RAID).