Pourquoi une reconstruction RAID redémarre après la déconnexion d’un disque

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Why a RAID Rebuild Restarts After a Disk Disconnects - Zima Store Online

Une reconstruction peut redémarrer après la déconnexion d'un autre disque car l'ensemble des membres de confiance a de nouveau changé. Le contrôleur peut abandonner les progrès partiels et régénérer la redondance à partir d'un nouveau point de cohérence.

Une brève déconnexion n'est pas sans conséquence en fonctionnement dégradé. La bonne réponse est d'identifier quel membre avec numéro de série est tombé, de préserver les journaux, de confirmer que l'ensemble a encore assez de copies valides, et d'arrêter d'expérimenter avec les câbles ou les emplacements tant que l'état actuel de récupération n'est pas compris.

La deuxième déconnexion crée un nouvel événement de récupération

Une reconstruction se base sur un ensemble spécifique de membres sources et un disque cible. Si un autre membre source disparaît, même brièvement, l'ensemble ne peut plus supposer que chaque bloc déjà écrit sur la cible correspond à l'ensemble actif actuel. Les écritures peuvent aussi avoir continué pendant l'absence de ce membre.

Les contrôleurs gèrent cela différemment. Certains reprennent à partir d'une carte bitmap ou d'un point de contrôle ; d'autres redémarrent une reconstruction complète. La discussion sur la reconstruction après reconnexion d'un disque montre pourquoi retirer un membre modifie l'état de tolérance aux pannes même lorsque le disque contient encore la plupart des anciennes données.

Des métadonnées corrompues peuvent faire paraître un ancien membre obsolète

Les membres RAID stockent normalement des métadonnées d'ensemble qui identifient leur rôle et leur historique d'événements. Lorsqu'un disque disparaît alors que les écritures continuent, son contenu devient plus ancien que l'ensemble actif. Le reconnecter ne fait pas disparaître ces écritures manquées, donc le contrôleur doit concilier ou écraser les zones obsolètes.

Un membre RAID temporairement retiré peut être reconnu grâce à ses métadonnées, mais l'implémentation décide toujours s'il peut rejoindre directement ou s'il nécessite une synchronisation. Ne supposez pas que le retour dans le même emplacement préserve la confiance.

Pourquoi la progression peut revenir à zéro

Le pourcentage décrit souvent le passage de récupération actuel, pas un registre permanent de tous les blocs jamais copiés. Si un membre source change d'état, si la cible est réaffectée ou si le contrôleur réassemble l'ensemble, l'opération affichée peut redémarrer à zéro même si certains blocs cibles correspondent déjà.

Sur un RAID logiciel, un nouvel événement dégradé peut nécessiter une resynchronisation complète. Une seconde reconstruction complète RAID1 documentée montre qu'une fois qu'un ensemble md entre en état dégradé, il peut synchroniser l'ensemble du membre plutôt que de faire confiance à un état partiel antérieur.

Ne pas retirer un autre disque pour tester la théorie

Pendant une reconstruction, chaque source restante fait partie du seul chemin pour reconstruire les données manquantes. Retirer un autre membre pour identification peut dépasser la tolérance aux pannes du niveau RAID ou créer des versions concurrentes des données. Localisez les disques par numéro de série et indicateurs d'enceinte, pas par retrait d'essai.

Arrêtez les expériences de changement à chaud jusqu'à ce que l'ensemble soit sain ou copié sur un stockage sécurisé. Si un câble ou un emplacement est suspecté, collectez d'abord le journal des événements et planifiez un changement contrôlé unique avec le système en pause lorsque le matériel ne supporte pas explicitement le service en ligne.

Vérifier si la reconstruction a vraiment redémarré

Comparez plus que le pourcentage. Enregistrez le nom de l'opération, le numéro de série cible, le nombre de membres source, le numéro d'événement ou de génération, les blocs traités, la vitesse actuelle et le temps estimé de fin. Un contrôleur peut passer de la reconstruction à l'initialisation de parité, à la vérification ou à la vérification de cohérence en arrière-plan.

Champ	Même opération	Nouvel événement de récupération
Numéro de série cible	Inchangé	Différent ou reclassé
Blocs traités	Continue vers le haut	Retour au début
Ensemble des membres	Stable	Un autre disque absent ou réintégré
Message journal	Reprendre ou continuer	Abandonner, redémarrer, réassembler, nouvelle reconstruction
État de l'ensemble	Dégradé/en reconstruction	Plus dégradé, étranger ou en récupération

Si l'ensemble des membres a changé, considérez le nouveau pourcentage comme un événement neuf. Si seule l'interface a été réinitialisée tandis que les compteurs continuent, il peut s'agir d'un problème d'affichage plutôt que d'une perte de progression.

Quand un redémarrage est moins important qu'un disque défaillant

Un redémarrage planifié n'invalide pas nécessairement une reconstruction gérée par le contrôleur. Beaucoup de contrôleurs conservent suffisamment d'état pour reprendre en toute sécurité. L'événement plus grave est la perte d'un autre disque source ou l'introduction d'une configuration étrangère pendant ou après le redémarrage.

Un redémarrage pendant une reconstruction peut être récupérable, mais la conclusion sûre dépend du statut du contrôleur après le démarrage. N'initialisez ni n'importez jamais une configuration étrangère simplement parce que le pourcentage a été réinitialisé.

Que faire immédiatement

Mettez en pause les écritures non essentielles et capturez les journaux du volume, du boîtier et du système d'exploitation.
Mappez chaque membre actif, manquant, en reconstruction et de secours à un numéro de série physique.
Confirmez que le niveau RAID dispose toujours de suffisamment de membres sources valides pour reconstruire les données.
Vérifiez les compteurs SMART et d'erreurs de liaison sur le disque qui s'est déconnecté et son chemin de connexion.
Laissez une reconstruction stable s'exécuter sans expérimentations supplémentaires de câbles, baies, redémarrages ou charges de travail.

Si une autre source signale des secteurs illisibles ou des déconnexions répétées, priorisez la copie des données irremplaçables ou l'imagerie des membres plutôt que de forcer une reconstruction répétée.

FAQ

Reconnecter le même disque redémarre-t-il toujours la reconstruction ?

Non. Certains contrôleurs peuvent le réintégrer ou reprendre à partir d'une carte bitmap. D'autres considèrent le membre comme obsolète et recommencent la synchronisation. Le journal des événements et les données de génération du membre déterminent le cas survenu.

Un pourcentage réinitialisé signifie-t-il que le nouveau disque a été effacé à nouveau ?

Pas nécessairement. Cela peut signifier que le contrôleur a commencé un nouveau passage ou changé le type d'opération. Ne déduisez pas une perte de données uniquement à partir du pourcentage ; inspectez l'identité de la cible et les messages d'événement.

Puis-je continuer à utiliser les applications pendant la reconstruction redémarrée ?

Une utilisation légère peut être supportée, mais réduisez les écritures évitables et les tâches sensibles à la latence. Le volume a déjà montré un deuxième événement de connectivité, donc la stabilité et la protection des données priment sur le débit normal.

La réponse pratique

Une reconstruction redémarre parce que les hypothèses de cohérence ont changé lorsqu'un autre membre s'est déconnecté. Stabilisez le chemin matériel, vérifiez l'ensemble source et autorisez une récupération ininterrompue au lieu de tester le volume en mode dégradé.