Pourquoi un SSD SATA disparaît-il après un redémarrage à chaud, mais réapparaît-il après une mise hors tension ?
Un SSD SATA peut disparaître après un redémarrage à chaud lorsque le contrôleur ou la liaison reste dans un état défaillant que seule une coupure complète de l’alimentation peut réinitialiser.
Un redémarrage normal réinitialise les logiciels, mais peut ne pas couper l’alimentation de veille du SSD, du contrôleur, du fond de panier ou du port de la carte mère. Si la liaison ne parvient pas à devenir opérationnelle, le disque peut disparaître avant même l’intervention des partitions, des systèmes de fichiers, des pools ou des applications. Un arrêt complet modifie le diagnostic, car il force une initialisation plus profonde du contrôleur et de la liaison. Commencez par identifier la couche la plus basse qui perd le périphérique, plutôt que de reconstruire immédiatement le stockage ou de remplacer le système de fichiers.
Déterminez si le BIOS, le contrôleur SATA ou uniquement le système d’exploitation perd le SSD
Notez si le SSD apparaît dans le BIOS ou l’UEFI, dans la vue des contrôleurs du système d’exploitation, dans la liste des périphériques de blocs, dans la table des partitions et dans le système de fichiers monté avant et après un redémarrage à chaud.
Le guide libATA de Linux décrit comment le pilote attend qu’une liaison SATA soit opérationnelle et peut considérer un périphérique comme absent lorsque cette mise en service échoue. Son modèle de récupération des liaisons SATA explique pourquoi un disque peut disparaître avant même d’atteindre la couche du système de fichiers.
Si le BIOS perd également le SSD, concentrez-vous sur le micrologiciel, l’alimentation du port, l’initialisation de la liaison, le câble et le contrôleur du disque. Si le BIOS le détecte mais que le système d’exploitation ne le voit pas, conservez les journaux du système d’exploitation et examinez l’énumération du pilote ainsi que le mode du contrôleur.
Comparez le redémarrage à chaud, l’arrêt complet et la coupure d’alimentation
Testez un redémarrage ordinaire, un arrêt du système d’exploitation suivi d’une remise sous tension immédiate, puis un arrêt avec déconnexion de l’alimentation suffisamment longue pour permettre aux rails de veille de retomber. Répétez chaque scénario au moins deux fois.
La vue des périphériques PCI fournit une limite claire entre la présence du contrôleur et la détection du stockage. L’utilitaire lspci peut confirmer si le contrôleur AHCI ou SATA lui-même a changé après le redémarrage, même lorsque le périphérique de blocs SSD est absent.
Si seule une coupure complète de l’alimentation permet de restaurer le disque, les causes les plus probables sont un état conservé du contrôleur, une réinitialisation incomplète du PHY SATA, un état du micrologiciel du SSD ou une interaction avec la gestion de l’alimentation. Ce comportement correspond moins à un problème ordinaire de montage ou de partition.
Examinez la première erreur de liaison SATA et de réinitialisation
Enregistrez le journal des événements du noyau ou du système après le redémarrage à chaud défaillant, avant d’effectuer un démarrage à froid. Recherchez les messages indiquant une liaison inactive, des échecs COMRESET, des délais d’attente de mise en service du périphérique, des commandes IDENTIFY échouées ou des réinitialisations répétées du port.
La gestion active de l’alimentation des liaisons SATA peut placer la liaison dans des états basse consommation que certaines associations de contrôleurs et de SSD gèrent mal. L’ArchWiki avertit qu’une gestion agressive de l’alimentation des liaisons peut causer de graves problèmes sur les périphériques incompatibles.
La première erreur est plus utile que les messages ultérieurs indiquant que le système de fichiers ou le pool est indisponible. Conservez le numéro du port et le modèle du disque afin de pouvoir associer chaque test ultérieur de câble, de baie et de micrologiciel au même chemin.
Vérifiez le câble SATA, le connecteur d’alimentation et les compteurs d’erreurs d’interface
Rebranchez le câble de données SATA et le connecteur d’alimentation lorsque le serveur est complètement éteint. Vérifiez les languettes de verrouillage desserrées, les courbures trop prononcées, les répartiteurs, les connecteurs du fond de panier et les adaptateurs.
Les recommandations de dépannage du stockage d’Unraid indiquent qu’une hausse des erreurs CRC UDMA doit conduire à vérifier les câbles de données et d’alimentation, les connexions du contrôleur et les ports, plutôt qu’à réparer immédiatement le système de fichiers.
Un compteur CRC historique ne prouve pas que le câble actuel est toujours défectueux. Notez la valeur brute, effectuez un cycle de redémarrage contrôlé, puis vérifiez si le compteur augmente.
Examinez les données SMART du SSD, les journaux d’erreurs et l’état du micrologiciel
Relevez le modèle du SSD, son numéro de série, la version de son micrologiciel, le nombre de cycles d’alimentation, le nombre d’arrêts non sécurisés, les erreurs d’interface et les journaux d’erreurs disponibles lorsque le disque est visible.
La documentation de smartctl décrit les attributs SMART et journaux d’erreurs qui permettent de distinguer les problèmes de santé de la mémoire flash des défaillances du transport ou du contrôleur.
N’appliquez une mise à jour du micrologiciel du SSD qu’après avoir vérifié les sauvegardes, la compatibilité du modèle et les instructions de récupération du fabricant. Ne modifiez qu’une seule couche de micrologiciel à la fois afin de pouvoir identifier clairement une correction réussie.
Utilisez une nouvelle détection uniquement à des fins de diagnostic
Lorsque le contrôleur reste présent mais que le disque est absent, effectuez une seule nouvelle détection du stockage prise en charge après avoir arrêté toutes les entrées-sorties actives. Notez si le SSD réapparaît sans cycle d’alimentation.
Microsoft indique que la commande rescan de DiskPart détecte les nouveaux disques, ce qui permet de distinguer une énumération retardée du système d’exploitation d’un disque absent au niveau du contrôleur.
Une nouvelle détection réussie ne constitue pas une solution permanente. Elle montre que le contrôleur et le SSD peuvent communiquer après une nouvelle tentative de détection ; le travail restant concerne donc le micrologiciel, le pilote, le mode du contrôleur ou l’initialisation de la liaison.
Isoler le disque, le port et le contrôleur avant tout remplacement
Après avoir sauvegardé les données, déplacez le SSD vers un port SATA connu comme fonctionnel avec un câble connu comme fonctionnel, ou testez un disque connu comme fonctionnel sur le chemin d’origine. Ne modifiez qu’un seul composant par cycle.
Le guide ZimaSpace consacré à la distinction entre une défaillance du câble SATA et du disque fournit la procédure d’isolement adaptée aux chemins de stockage sujets à des pannes intermittentes.
Le problème est résolu lorsque le SSD reste visible après plusieurs redémarrages à chaud, démarrages à froid et périodes d’inactivité, ainsi que pendant des lectures soutenues, sans nouvelles erreurs de liaison. Cessez d’utiliser le disque pour les données principales s’il continue de disparaître avec des ports et des câbles connus comme fonctionnels, ou s’il signale une aggravation des erreurs du périphérique.
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...
