La correction la plus importante apportée par cette source est que le tableau n’est pas resté un RAID confirmé dans lequel « un disque avait échoué ». Après que l’utilisateur a démarré avec chaque disque séparément, les deux fonctionnaient individuellement. La reconnexion des deux disques a produit [UU] dans /proc/mdstat, ce qui signifie que les deux membres du RAID 1 étaient présents et synchronisés à ce moment-là.
La discussion s’est ensuite élargie à l’instabilité SATA/de la liaison/de l’alimentation, aux défaillances de l’USB et du moniteur, aux démarrages en mode d’urgence, aux erreurs NFS et au basculement de ZimaOS vers l’autre emplacement système. Les données ont été récupérées, mais la source ne prouve jamais une cause finale unique. N’en faites pas un simple tutoriel « remplacer le disque X ».
Ne cliquez pas sur « Casser » ou « Formater » tant qu’une récupération reste possible
Le premier conseil de la communauté était correct sur ce point de sécurité : si les données sont importantes et que l’état réel du tableau est inconnu, les actions destructives dans l’interface peuvent compliquer la récupération. Sauvegardez d’abord les données lisibles.
Chaque disque fonctionnait lorsqu’il était testé seul
L’auteur du message initial a déconnecté les disques un par un et a indiqué que chacun permettait d’obtenir un système/accès aux données fonctionnel. Cela a immédiatement affaibli l’hypothèse selon laquelle un disque était physiquement hors service.
La reconnexion des deux disques a produit un tableau md [UU] sain
L’état affiché indiquait md0 : raid1 actif ... [2/2] [UU]. À ce moment-là, la couche md de Linux considérait les deux membres comme présents.
C’est pourquoi la discussion s’est ensuite orientée vers la stabilité des câbles, des ports SATA, du contrôleur, de l’adaptateur/du fond de panier et de l’alimentation, plutôt que vers les seules métadonnées du RAID.
L’instabilité du SATA/de l’alimentation peut se faire passer pour une défaillance du RAID
La source a ensuite signalé des défaillances plus générales touchant le comportement du SATA, de l’USB et de l’affichage. Les suggestions de la communauté comprenaient le remplacement des câbles SATA, le test de ports différents, l’évitement des répartiteurs/adaptateurs limites et des tests de résistance tout en surveillant les réinitialisations d’E/S.
Il s’agissait de diagnostics effectués par la communauté, et non d’un défaut matériel confirmé par IceWhale.
Les problèmes ultérieurs de mode d’urgence/NFS constituaient une couche distincte
Après des changements de câbles et des redémarrages, le système est passé en mode d’urgence et a affiché des erreurs liées à NFS/RPC. Les tentatives de la communauté pour réinitialiser l’état de NFS ou désactiver NFS n’ont pas permis de confirmer une réparation.
N’inférez pas que NFS a causé l’inaccessibilité initiale du RAID ; le problème est apparu plus tard sur un système qui connaissait déjà une instabilité plus générale.
Le système a également basculé vers l’autre emplacement ZimaOS
L’utilisateur a indiqué avoir démarré depuis le bloc ou l’emplacement B plutôt que A. Les versions actuelles de ZimaOS utilisent deux emplacements système pour la récupération ; ce basculement peut donc indiquer qu’un emplacement système a échoué aux vérifications d’intégrité ou de démarrage, et non que les données utilisateur du RAID ont disparu.
Consultez le modèle actuel de récupération à double emplacement de ZimaOS.
Les versions actuelles de ZimaOS disposent d’un processus officiel de réparation du RAID 1
ZimaOS 1.4.4 a ajouté la réparation du RAID1 pour les baies dégradées ou endommagées et corrigé l’indisponibilité des disques précédemment utilisés pendant la récupération.
Utilisez la fonctionnalité officielle de réparation du RAID1 avant d’appliquer d’anciennes commandes manuelles de modification mdadm.
Les métadonnées RAID sont plus résilientes dans les versions récentes de ZimaOS
ZimaOS 1.6.0 a ajouté un mécanisme d’enregistrement des métadonnées RAID conçu pour réidentifier et monter automatiquement la baie d’origine après la réinstallation du système d’exploitation ou le remplacement de l’appareil. Cela améliore le processus de récupération par rapport à la période de la source en version 1.5.x.
Ordre de récupération actuel le plus sûr
- Ne formatez pas la baie et ne la démantelez pas.
- Identifiez les modèles et les numéros de série des disques, ainsi que l’état actuel du RAID, à l’aide de diagnostics en lecture seule.
- Sauvegardez immédiatement les données accessibles.
- Vérifiez les câbles, les ports, l’alimentation, les données SMART ainsi que les journaux d’E/S et de réinitialisation du noyau.
- Utilisez l’interface actuelle de réparation du RAID lorsque la baie est réellement dégradée.
- Traitez séparément la récupération de l’emplacement du système et la récupération des données RAID.
Le fil de discussion sur la récupération a finalement abordé les options de réinitialisation et de récupération de ZimaOS
Un état md [UU] signifie que les deux membres du RAID 1 étaient présents à ce moment-là
Après avoir reconnecté les deux disques, la source affichait la baie comme active avec deux membres et [UU]. Cela constituait une preuve solide que le miroir lui-même s’était correctement réassemblé à ce moment-là.
Cela n’explique pas pourquoi la baie était auparavant apparue comme inaccessible, ni pourquoi l’instabilité ultérieure du SATA, de l’USB et du moniteur a persisté.
Les diagnostics en lecture seule sont plus sûrs que les commandes de réparation manuelle de mdadm
La communauté a demandé des informations sur la matrice et son état avant de suggérer des modifications. C’est le bon ordre : déterminer quels périphériques appartiennent à la matrice, si elle est active ou dégradée, et ce que signale le noyau avant d’ajouter ou de retirer des membres, ou de recréer les métadonnées.
Ne copiez pas une mdadm --create, une commande d’assemblage forcé ou d’effacement du superbloc provenant d’un autre cas Linux dans un RAID qui contient l’unique copie de vos données.
Copier les données importantes dès que la matrice redevient lisible
L’utilisateur mentionné dans la source a récupéré l’accès. À ce stade, la priorité devrait être de copier les données irremplaçables vers un stockage indépendant avant de poursuivre les essais avec les câbles, les contrôleurs, les emplacements système, NFS ou la réinstallation.
Le RAID 1 offre une redondance, mais un hôte ou un contrôleur instable peut rendre les deux membres indisponibles simultanément.
Lorsque des problèmes SATA, USB et d’affichage apparaissent simultanément, élargissez le diagnostic
Les symptômes apparus ensuite ne correspondaient plus à un scénario simple de défaillance d’un seul disque. Une détection SATA intermittente, des problèmes USB et des problèmes d’affichage ou de démarrage peuvent indiquer des câbles, une alimentation, un contrôleur, un micrologiciel de la carte mère ou une autre instabilité de la plateforme.
Testez une alimentation et des câbles dont le bon fonctionnement est avéré, et simplifiez la configuration matérielle avant de reconstruire le RAID à plusieurs reprises.
La récupération de l’emplacement système et la récupération du RAID sont distinctes
ZimaOS peut démarrer depuis d’autres emplacements système pour récupérer le système d’exploitation. Basculer vers l’emplacement B peut réparer ou contourner un problème lié à l’emplacement du système d’exploitation, mais cela ne répare pas à lui seul une matrice dégradée.
Utilisez le modèle actuel de récupération du système ZimaOS lorsque l’emplacement du système d’exploitation est également défaillant.
Déconnecter les disques de données lors de la réinstallation du système d’exploitation si le plan de récupération le prévoit
La communauté mentionnée dans la source recommandait d’isoler les disques RAID lors d’une réinstallation propre du système d’exploitation afin de réduire le risque de sélectionner ou de modifier le mauvais disque. Si le support IceWhale actuel fournit un plan de réinstallation, étiquetez chaque disque et sauvegardez d’abord les métadonnées du stockage ainsi que les sauvegardes.
FAQ sur la récupération du RAID 1
La source a-t-elle établi de manière définitive qu’un disque était hors service ?
Non. Les deux disques ont ensuite fonctionné indépendamment et la matrice affichait [UU] lorsqu’il a été reconnecté.
La source a-t-elle identifié une cause première définitive ?
Non. Les problèmes de RAID, d’instabilité SATA/alimentation, de démarrage NFS et d’emplacement système se chevauchaient.
La version actuelle de ZimaOS prend-elle en charge la réparation du RAID 1 ?
Oui. IceWhale a ajouté une procédure officielle de réparation de RAID 1 dans la version 1.4.4.
