Guide de dépannage des DAS USB pour les déconnexions, l’alimentation et les erreurs UAS

L’approche sûre consiste à capturer la signature de la panne, à ne modifier qu’une variable à la fois et à appliquer uniquement la correction correspondante, sous forme d’une séquence de points de contrôle observables plutôt qu’une commande unique.

Sur un serveur domestique Linux équipé d’un boîtier de stockage directement connecté en USB, le risque pratique est que les disques USB DAS se déconnectent, se réinitialisent ou disparaissent sous charge. Notez l’identité actuelle et le point de récupération, commencez par le test différentiel le moins invasif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous dès que le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le processus ci-dessous ne se termine qu’une fois la charge de travail d’origine exécutée avec succès ou lorsque les éléments recueillis atteignent un seuil nécessitant une escalade.

Capturez la signature exacte de la déconnexion

Arrêtez les applications fortement sollicitées en écriture et recueillez la sortie de journalctl -k -f ou dmesg -w tout en reproduisant le même transfert. Notez les horodatages, la topologie USB, le fabricant et les identifiants produit du pont, la vitesse négociée, les numéros de série des périphériques, l’état du montage et la première erreur avant que les messages de réinitialisation ultérieurs ne masquent l’événement initial.

Un cas résolu sur Ask Ubuntu présente un cas typique d’abandon UAS et de déconnexion, où les messages d’abandon UAS et la disparition du périphérique doivent être interprétés ensemble. Considérez cette signature comme une observation circonscrite, et non comme la preuve que chaque déconnexion est due à un bogue UAS.

Arrêtez les tests et protégez les données si les réinitialisations se répètent pendant les écritures, si le système de fichiers passe en lecture seule, si le disque émet des clics ou si les compteurs d’erreurs SMART et du périphérique augmentent. N’exécutez pas de réparation du système de fichiers sur une liaison USB instable.

Commencez par distinguer les problèmes d’alimentation et de signal

Reproduisez la charge de travail avec le boîtier d’origine, puis ne changez qu’un seul élément : le câble, le port hôte, le bloc d’alimentation ou, le cas échéant, un concentrateur alimenté. Gardez le disque, le système de fichiers, la charge de travail et la durée constants. Un boîtier contenant plusieurs disques et alimenté par le bus, qui échoue uniquement au démarrage des disques ou lors d’écritures simultanées, indique probablement un problème d’alimentation, même si les lectures au repos semblent normales.

Vérifiez si la liaison rétrograde en vitesse, se réinitialise lorsque le connecteur bouge ou échoue uniquement via un port en façade ou une rallonge. Remplacez un câble suspect par un câble court certifié et évitez les adaptateurs pendant le test de contrôle. Si l’erreur suit un port ou un hôte précis, ne mettez pas le boîtier en cause avant d’avoir testé le contrôleur et la gestion de l’alimentation.

Cette branche est validée lorsque la charge d’origine reste connectée lors de deux démarrages à froid et d’un transfert prolongé après une seule modification du chemin matériel. Si chaque câble et chaque port échoue selon le même schéma de transaction, passez aux tests du protocole du pont et à l’isolement boîtier-disque.

Testez UAS comme une branche de compatibilité, pas comme le coupable par défaut

Vérifiez que le périphérique utilise actuellement uas et relevez son identifiant USB exact. Ce n’est qu’après avoir reproduit des abandons spécifiques à UAS que vous devez tester le même périphérique avec une option temporaire et correctement ciblée de usb-storage, ou avec un hôte connu pour utiliser le chemin « bulk-only ». Prévoyez une profondeur de file d’attente ou des performances réduites pendant ce test différentiel.

Un fil de dépannage Linux Mint recommande de surveiller les journaux du noyau pour détecter les erreurs UAS afin de mettre en évidence les erreurs liées à UAS lorsque le périphérique est connecté. Utilisez la comparaison pour déterminer si les réinitialisations disparaissent sous la même charge ; le simple fait de voir le mot uas dans un journal ne prouve pas la causalité.

Si le transport « bulk-only » reste stable deux fois tandis que UAS échoue systématiquement, conservez la solution de contournement uniquement pour cet identifiant fabricant/produit et vérifiez les options de mise à jour du micrologiciel ou de remplacement du boîtier. Si les deux transports échouent, retirez l’exception et poursuivez l’isolement de l’alimentation, du pont, de la température ou du disque.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Déterminez si les erreurs suivent le disque ou le boîtier

Installez le disque suspect dans un boîtier fiable ou sur une liaison SATA directe, puis placez un disque de rechange fiable dans le DAS suspect. Exécutez le même test de lecture non destructif avant toute sollicitation intensive en écriture. Les erreurs qui suivent le disque mettent en cause son support ou son contrôleur ; celles qui restent liées au DAS mettent en cause le pont, le fond de panier, le refroidissement, le câble ou l’alimentation.

Le guide de dépannage associé sur le disque ou le boîtier de ZimaSpace détaille davantage la décision fondée sur l’échange des éléments. Utilisez-le après les tests de transport afin de ne pas confondre une panne du pont avec un support défectueux et de ne pas masquer un disque défaillant par des réinitialisations répétées du boîtier.

La récupération est validée lorsque la charge de travail d’origine reste stable après reconnexion, redémarrage et entrées/sorties prolongées, sans nouvelles réinitialisations du noyau ni nouvelles erreurs du périphérique. Demandez une prise en charge ou remplacez le composant lorsque la panne le suit systématiquement ; si les résultats restent contradictoires, arrêtez les écritures, créez une image des données critiques via le chemin le plus stable et conservez les journaux pour le support matériel.