Ceux qui viennent de penser au capitaine Flam marquent un point. Mais ce n’est pas d’animés dont nous allons parler aujourd’hui. Nous allons apprendre à sauver un RAID5 quand tout indique que vos données sont perdues.
Dans un premier temps il faut être clair: Je n’ai pas la prétention de vous apprendre à réparer un disque dur 🙂 Si deux de vos disques se sont mis à « claquer », avant qu’un arc électrique « de la mort » ne provoque une surtension et de jolies flammes dans votre tour, et que tout cela s’est terminé par deux disques noires et calcinés, la oui, faites vous une raison, ils sont MORTS 🙂
Heureusement, ce cas de figure n’est pas le plus fréquent. Par expérience, il arrive bien plus souvent qu’un problème électrique quelconque, une défaillance mécanique ou autre, entraîne des soucis lors d’une écriture, provoquant l’éjection du ou des disques du raid. Tant qu’un seul disque est impacté, la reconstruction reste plutôt aisée. Mais que faire lorsque ce sont DEUX disques qui sont brutalement éjectés du raid, que le raid devient donc HS avec deux disques flagués en erreur ? C’est tout le sujet de cet article…
Situation initiale
Nous avons donc un raid software (utilisant mdadm bien sur), avec deux disques en erreur. Ces disques restent néanmoins parfaitement « visibles » par le bios après un reboot. Bref, le problème est venu du contrôleur ou d’ailleurs, les disques eux semblent bon, matériellement parlant.
Ce que j’ai fait, et qui a fonctionné
(Je ne prétend donc pas que cela fonctionnera à tous les coups hein… Mais comme j’en suis à ma deuxième grosse « panne » sur un raid5, et que je suis super content d’avoir pu sauver mes données, je vous en fait profiter 😉
Commencez par examiner chaque disque (ou partition) de la façon suivante :
mdadm --examine /dev/sda1
Pour chaque disques, notez le résultat des deux champs les plus importants : « state » et « event ». Dans mon cas, tous les disques étaient dans un état « clean » ce qui doit vouloir dire qu’au moment de la panne, les données du raid étaient dans un état cohérent. Si vous avez des disques qui ne sont pas dans un état « clean », dites vous qu’il ne faudra les utiliser qu’en dernier recours. A priori, le raid ne devrait être reconstruit qu’avec des disques en état « clean ».
Regardez maintenant le champs « event ». C’est le nombre d’événements qui ont eu lieu. Autrement dit, si tous vos disques ont le même numéro (ce qui est peu probable…) c’est qu’ils ont tous au même niveau et que vous pouvez tout de suite reconstruire le raid. Mais il est probable que ce ne soit pas le cas. Si vous avez de la chance, et si un seul disque à un numéro différant, alors c’est ce disque la qu’il ne faudra pas prendre en compte pour le « ré-assemblage » du raid.
Personnellement je me suis retrouvé avec deux disques qui avaient le numéro X et deux autres avec le numéro Y. (X étant inférieur à Y). Il m’a semblé plutôt logique de repartir de l’état le plus ancien, celui d’avant la panne donc.
Imaginons que mes 4 partitions s’appelaient /dev/sda1, /dev/sdb1, /dev/sdc1 et /dev/sdd1, et que a et b ai X pour event, alors que c et d avaient Y. Voila la commande magique :
mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1
Autrement dit, j’ai pris les deux plus ancien, et j’ajoute un des disques avec un event plus récent. (celui qui m’a semblé être le plus « net » d’apres d’autres critère sur lesquelles je n’ai pas trop le temps de m’étaler).
Croisez les doigts, et si vous avez de la chance, mdadm acceptera l’opération, mettra à jour l’ensemble des disques pour qu’ils aient un event identique. Bien sur, il faudra encore ré-ajouter le dernier disque (à condition bien sur qu’il soit lui aussi matériellement hors de cause) :
mdadm --add /dev/md0 /dev/sdd1
Vous n’avez plus qu’a vérifier que vos volumes logiques (si vous utilisez lvm) sont bien revenus, et à faire un fsck de vos systèmes de fichiers 🙂
PS : Et juste parce qu’on ne le répétera jamais assez… un raid ne remplacera jamais une vraie sauvegarde. JAMAIS !
Tout simplement MERCI !
On a eu exactement le même problème sur notre serveur, les disques qui ne mettent en rade sans prévenir, sans même réaliser une mise à jour du système alors bon … La méthode a parfaitement fonctionné. On a utilisé le assemble avec le force (au passage –assemble puis –force, sinon ça ne fonctionne pas) et il a tout recréé, notre système a redémarré ! Il est même en train de resynchroniser le 4eme disque tout seul !
Merci encore 🙂
Et bien vraiment tant mieux si cet article à pu être utile 🙂
Je l’ai écrit de mémoire, et l’ordre des arguments « assemble » et « force » avait peut être de l’importance en effet… je vais donc prendre en compte votre remarque et modifier l’article en conséquence.
Pour la suite, n’oubliez pas les sauvegardes !
Un énorme merci pour ton article, et tes explications dans un vieux post du forum ubuntu-fr !
Grâce à toi, tout est resynchronisé alors que je croyais tout perdu !
Ça m’apprendra à monter un truc sensible sans avoir à l’avance compris comment il fontionne, et comment réparer…
Encore big up à toi 🙂
Merci à toi pour ton message, cela fait toujours plaisir de savoir qu’on a pas passé des heures à écrire un truc pour rien 😉
Et désolé pour le temps d’approbation, il faut que je comprenne pourquoi mais je n’ai reçu aucun mail me prévenant de messages en attente de modération 🙁
Bonjour,
Je suis également confronté à un problème de RAID5, consécutif à une coupure de courant.
Contexte : RAID 5, cinq disques (sda, sdb, sdc, sdd, sde), tous à l’état « clean ».
Note importante, sda est un disque que j’ai installé récemment, pour étendre le RAID5.
Les « events » des disques sont les suivants :
sda : 5659
sdb : 76640
sdc : 76635
sdd : 76640
sde : 76640
Dans ce contexte, faut-il mettre sda de côté, réassembler le RAID avec sdb / c / d / e (la synchro se faisant alors sur 76635 events, si j’ai bien compris) puis ajouter sda ?
Merci !
Bonjour,
C’est vraiment bizarre pour sda. Pour moi quel que soit la date d’ajout dans le raid il devrait avoir un nombre d’événements identique (il aurait pas commencé a 0 mais au même niveau que les autres). Tu es sur que le raid était clean avant la panne ?
Quoi qu’il en soit je ferai exactement ce que tu proposes. Forcer le reasemblage des autres d’abord, puis remettre sda dans le raid ensuite.
Hello,
Bravo pour ce tuto, il m’a sortie une belle épine du pied. merci beaucoup d’avoir pris le temps de partager tes recherches.
Bonjour,
Je suis bien content que ça ai pu aider quelqu’un d’autre.
La rédaction de billets prend effectivement beaucoup de temps, et c’est bien ce genre
de commentaires qui pousse à continuer.
Même en 2021 Y a encore des mercis !!
Merci merci merci.
J’avais un disque défectueux depuis un bout de temps , rien de méchant , des erreures de lecture qui me faisait des scans du raid toutes les semaines mais cela n’aboutissait pas.
Et puis j’ai décider de prendre le taureau par les cornes et de changer le disque défectueux. Pendant la reconstruction c’est un autre qui a lâcher sans crier gare lui …
Mais après une prise de tête sur l’emergency mode , j’ai réussi a rescanner les disques , tous OK et grâce a ta commande ( que j’avais déjà faite pour la première reconstruction) , il a collaborer et c’est reparti pour la reconstruction…. plus que 600 min… pourvu que cela ne décroche pas !!
Whaou ! Un autre merci ONZE ANS après la rédaction du billet ! Je ne m’occupe vraiment plus assez de ce blog, quasiment laissé à l’abandon, et raison pour laquelle j’ai mis autant de temps à voir ton message. Mais je suis vraiment content que ce texte puisse encore servir.
J’en aurai pourtant des trucs à écrire. Mais c’est le temps (et le courage !) qui manque.