Pourquoi un boîtier de disque dur externe se déconnecte-t-il uniquement pendant les lectures de vérification ?
Un boîtier de disque dur externe peut se déconnecter pendant la vérification, car les lectures soutenues révèlent des problèmes limites d’alimentation, de transport USB, de pont, de chaleur, de câble ou du disque lui-même.
La navigation ordinaire ne lit que de petites zones et peut ne jamais solliciter le boîtier assez longtemps pour révéler un adaptateur faible, une puce de pont instable, un câble endommagé, un contrôleur qui surchauffe ou une région illisible du disque. Les lectures de vérification sont séquentielles, prolongées et réessaient souvent les secteurs défaillants ; elles créent donc exactement la charge qui fait réinitialiser un chemin instable. Diagnostiquez séparément le transport USB et le disque avant de supposer que l’un ou l’autre doit être remplacé.
Vérifiez si le périphérique se réinitialise ou si le système de fichiers est simplement démonté
Consignez le premier événement du journal système, l’identité du périphérique USB, le nom du périphérique bloc, l’état du montage et la position de vérification lorsque l’échec se produit. Déterminez si le boîtier disparaît de l’USB, si le disque reste présent mais signale des erreurs d’E/S, ou si le système de fichiers est démonté après ces erreurs.
La documentation Linux sur la gestion de l’alimentation USB distingue les changements d’alimentation du périphérique du comportement du système de fichiers à un niveau supérieur. Le modèle de gestion de l’alimentation USB du noyau aide à distinguer une suspension ou une réinitialisation au niveau USB d’une réaction du système de fichiers à des E/S de stockage défaillantes.
Si le boîtier disparaît de l’énumération USB, concentrez-vous d’abord sur l’alimentation, le câble, le micrologiciel du pont, le contrôleur hôte et la suspension. S’il reste présent avec des erreurs de lecture, conservez l’adresse défaillante et examinez le disque ou la traduction du pont.
Testez l’alimentation sous une charge de lecture soutenue
Utilisez l’adaptateur secteur approprié du boîtier, connectez-le directement à l’hôte et retirez les concentrateurs non alimentés ou les rallonges du panneau avant. Comparez le comportement au démarrage, au repos et pendant la vérification.
Les recommandations de Seagate pour le dépannage des disques externes préconisent de vérifier l’alimentation, la connexion USB directe, les câbles et d’autres ports avant de considérer le disque comme défaillant, car une activité soutenue peut révéler une connexion limite qui résiste à une utilisation légère.
Un boîtier alimenté qui se déconnecte uniquement sous charge peut tout de même avoir un adaptateur sous-dimensionné ou défaillant. Ne remplacez pas l’alimentation, sauf si la tension, la polarité, le connecteur et le courant nominal correspondent aux exigences du boîtier.
Désactivez la suspension sélective USB pour un test contrôlé
Consignez la politique d’alimentation USB du système d’exploitation et vérifiez si le boîtier passe à l’état inactif avant le début de la vérification. Dans la mesure du possible, ne modifiez que le périphérique concerné ou le système de test.
Microsoft décrit la suspension sélective USB comme une fonctionnalité d’alimentation par périphérique. Elle permet d’économiser l’énergie, mais constitue aussi un bon indicateur lorsqu’un chemin de stockage échoue autour de la suspension ou de la reprise.
Si le boîtier devient stable lorsque la suspension est désactivée, poursuivez en mettant à jour le jeu de puces, les composants USB et le micrologiciel du boîtier avant de laisser définitivement les économies d’énergie désactivées. Un test réussi identifie une interaction avec l’état d’alimentation, pas nécessairement le composant finalement défaillant.
Comparez les transports USB UAS et Bulk-Only
Vérifiez si le boîtier utilise USB Attached SCSI ou l’ancien transport Bulk-Only. Consignez l’identité de la puce de pont, le pilote, la profondeur de file d’attente et les erreurs avant de changer de mode.
La référence lsusb de Debian permet d’identifier le pont et l’interface USB active, ce qui est nécessaire avant d’appliquer une solution de contournement propre à un périphérique.
Tester le mode Bulk-Only peut révéler un problème lié à UAS ou à la mise en file d’attente, mais réduit également les performances et le parallélisme des commandes. Utilisez-le comme comparaison contrôlée plutôt que comme solution universelle pour tous les boîtiers.
Exécutez des tests d’état du disque sans la charge du système de fichiers
Lisez les données SMART via le boîtier si le pont prend en charge le relais des commandes. Consignez les secteurs en attente, les erreurs incorrigibles, les erreurs CRC de l’interface, la température, les dépassements de délai des commandes et l’historique des autotests.
Le manuel smartctl de Debian explique que les autotests et journaux d’erreurs SMART peuvent aider à distinguer les erreurs du support des réinitialisations du transport USB lorsque le boîtier relaie correctement les commandes vers le disque.
Un autotest court réussi ne suffit pas à innocenter un disque qui échoue lors d’une lecture de toute sa surface. Utilisez un autotest long ou une analyse en lecture seule uniquement lorsque les données sont sauvegardées et que le disque ne présente pas d’erreurs qui s’aggravent rapidement.
Vérifiez la qualité du câble, le port hôte et la topologie USB
Remplacez le câble de données par un câble court dont le bon fonctionnement est confirmé et branchez le boîtier sur un autre port arrière de la carte mère. Évitez les adaptateurs et les concentrateurs pendant le test.
L’USB-IF explique que le chemin d’alimentation USB dépend de l’ensemble de la chaîne ; un connecteur qui fonctionne pour de brèves lectures de métadonnées peut donc tout de même échouer lorsque le boîtier et le disque maintiennent une activité plus élevée.
Si le problème suit un câble ou un port précis, mettez ce composant hors service. S’il suit le boîtier sur plusieurs hôtes, concentrez-vous sur son pont, son alimentation, son refroidissement ou le disque lui-même.
Repérez les emplacements d’échec reproductibles et évitez la perte de données
Répétez la vérification juste assez longtemps pour déterminer si la déconnexion se produit dans la même plage de blocs logiques, après la même durée écoulée ou à la même température. Ces schémas permettent de distinguer les dommages du support d’une instabilité thermique ou du transport.
L’article de ZimaSpace consacré aux déconnexions de disques de sauvegarde externes propose une comparaison complémentaire entre les échecs lors de transferts soutenus et les erreurs du support de stockage.
Arrêtez les tests et copiez d’abord les données récupérables lorsque les erreurs de lecture augmentent, que le disque se réinitialise à répétition dans la même plage, que l’état SMART se dégrade ou que le boîtier surchauffe. Le problème n’est résolu que lorsqu’une vérification complète en lecture s’achève sur un chemin stable, sans réinitialisation USB, erreur d’E/S ni augmentation des avertissements d’état.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
