Comment distinguer un câble SATA défectueux d’un disque NAS en panne

Un mauvais câble SATA produit des erreurs de transport, tandis qu’un disque défaillant génère des erreurs média ou périphérique. Le test fiable consiste à suivre quel type d’erreur augmente et où elle se manifeste.

Ne diagnostiquez pas à partir d’un seul statut SMART ou d’une seule déconnexion. Enregistrez le numéro de série du disque, les compteurs actuels, les messages du noyau, la baie, le câble et le port du contrôleur, puis changez un composant du chemin à la fois. Le schéma après chaque changement contrôlé est plus utile que le nombre d’erreurs initial.

Capturez une référence avant de réinstaller quoi que ce soit

Notez le numéro de série, le modèle, la baie, le port du contrôleur, les attributs SMART, le journal d’auto-test, le journal d’erreurs et les messages système récents du disque affecté avant de changer le câble. Une réinstallation peut arrêter le symptôme tout en effaçant la relation entre le disque et le chemin.

Les noms de périphériques tels que /dev/sdX peuvent changer entre les démarrages ou les déplacements de câble, donc le numéro de série est l’identité stable. Horodatez la référence et notez les valeurs brutes des compteurs car plusieurs compteurs SMART sont cumulatifs et ne reviennent pas à zéro après le remplacement d’un câble.

Suspendez les écritures intensives si l’ensemble est dégradé ou si les erreurs augmentent. Préservez d’abord les preuves, puis effectuez un changement contrôlé ; sinon, un échange simultané de câble, baie, connecteur d’alimentation et disque ne donnera aucun diagnostic fiable.

Séparez les erreurs de transport des erreurs média

Les erreurs de transport surviennent lorsque les commandes ou les données traversent le chemin SATA, tandis que les erreurs média se produisent lorsque le disque ne peut pas lire ou écrire de manière fiable des secteurs. Ces deux types de défauts peuvent provoquer des symptômes similaires dans les applications mais indiquent un matériel différent.

Le modèle d’erreur ATA sous Linux distingue une erreur de bus ATA d’une erreur média : les échecs CRC et de transmission appartiennent au chemin, tandis qu’une lecture non corrigible signalée après plusieurs tentatives appartient au média du périphérique. Les délais d’attente peuvent être ambigus, ils nécessitent donc des compteurs de soutien et des échanges contrôlés.

Classez chaque entrée du journal avant d’agir. Une augmentation des erreurs CRC ou des réinitialisations de lien oriente l’attention vers le câble, le connecteur, le backplane, la stabilité de l’alimentation ou le chemin du contrôleur ; les secteurs illisibles et les auto-tests échoués maintiennent le disque lui-même sous suspicion.

Surveillez si les compteurs CRC et de lien continuent d’augmenter

Un compteur CRC non nul montre que des erreurs d’interface sont survenues, mais le total historique seul ne prouve pas que le câble est actuellement défectueux. Le signal clé est de savoir si le compteur brut augmente pendant une période de test connue.

ICRC enregistre une erreur CRC d’interface. Comme ce compteur est stocké par le disque, il peut rester visible après le remplacement du câble ou de l’hôte d’origine, donc comparez les valeurs avant et après plutôt que de considérer tout compteur passé comme une faute active.

Effectuez une charge de lecture contrôlée après avoir réinstallé ou remplacé le câble de données et enregistrez le nouveau compteur. Si les événements CRC ou de réinitialisation de lien cessent tandis que les indicateurs média restent stables, le chemin était la cause principale ; si le compteur continue d’augmenter, continuez à isoler la baie, le port et la connexion d’alimentation.

Utilisez les auto-tests pour rechercher une défaillance côté disque

Un disque reste suspect lorsqu’il signale des secteurs illisibles, des secteurs en attente, des secteurs réalloués, des commandes échouées non liées au CRC, ou un auto-test qui s’arrête à un emplacement répétable. Ces signaux concernent la capacité du périphérique à accéder à son média.

Les auto-tests SMART et les journaux d’erreurs sont utiles car ils conservent des preuves côté périphérique sans se fier uniquement à la couche RAID. Le journal d’auto-test SMART doit être interprété avec les attributs bruts et les journaux système, et non réduit à la seule ligne globale PASSED.

Ne lancez pas un test étendu qui surchargerait un ensemble gravement dégradé ou un disque déjà retournant des erreurs de lecture répétées. Lorsque les données sont en danger, priorisez la sauvegarde ou l’imagerie, puis testez le disque isolé sous une charge contrôlée.

Changez un composant du chemin à la fois

Le discriminateur le plus clair est de savoir si la faute suit le disque physique ou reste avec le chemin SATA. Changez un seul composant par test : d’abord le câble de données, puis la baie ou le chemin du backplane, et enfin le port du contrôleur si la plateforme le permet en toute sécurité.

Gardez le même numéro de série du disque et la même charge de travail tout en comparant les nouvelles erreurs. Un compteur de transport qui augmente uniquement dans une baie ou avec un câble indique que le disque n’est pas en cause, tandis que les erreurs média et les auto-tests échoués qui suivent le numéro de série à travers des chemins propres pointent vers le disque.

Ne déplacez jamais des membres RAID actifs sans enregistrer la correspondance numéro de série-emplacement et confirmer que la pile de stockage identifie les membres par métadonnées plutôt que par ordre de slot. Si le système ne supporte pas un déplacement contrôlé, remplacez d’abord le câble et utilisez les journaux pour restreindre le chemin restant.

Interprétez les délais d’attente et réinitialisations comme des preuves complémentaires

Les délais d’attente de commande, les réinitialisations de lien SATA et les périphériques disparaissant brièvement peuvent résulter d’un câble faible, d’une alimentation instable, d’un problème de contrôleur ou d’un disque qui cesse de répondre. Ce sont des signaux importants, mais ils ne sont pas des causes auto-identifiantes.

Le chemin de récupération ATA peut réinitialiser un lien après des échecs de transmission ou des états de commande inconnus. Des réinitialisations répétées combinées à une augmentation des erreurs CRC renforcent l’hypothèse du chemin ; des secteurs non corrigibles répétés ou des échecs d’auto-test renforcent l’hypothèse média.

Corrélez chaque événement par horodatage avec les pertes RAID, les erreurs d’E/S applicatives et les changements SMART. Une seule réinitialisation après maintenance est moins convaincante qu’un schéma récurrent qui revient avec le même câble, baie ou numéro de série de disque.

Remplacez le composant suivi par les preuves

Remplacez le câble ou réparez le chemin lorsque de nouvelles erreurs CRC et de lien restent liées à une connexion et que le disque passe les contrôles média contrôlés ailleurs. Remplacez ou retirez le disque lorsque des erreurs côté périphérique suivent son numéro de série à travers des chemins connus bons.

Les cas ambigus ne doivent pas être forcés dans une réponse binaire. Un disque défaillant peut coexister avec un câble marginal, et un auto-test SMART stable n’efface pas les fautes de transport répétées qui peuvent toujours faire tomber un membre RAID.

Après la réparation, établissez une nouvelle référence et vérifiez que les compteurs cessent d’augmenter lors d’une charge normale, d’un nettoyage ou d’une vérification de cohérence, et d’une période de surveillance. Escaladez ou imagez le disque si les erreurs persistent, les données sont illisibles ou l’ensemble n’a plus de redondance.