Volume NAS en lecture seule après une extinction non sécurisée : premières vérifications

Un volume NAS qui devient en lecture seule après un arrêt non sécurisé protège généralement des métadonnées endommagées ou réagit à des erreurs d’E/S de stockage — il ne s’agit pas simplement d’un changement de permissions.

Si vos partages s’ouvrent encore mais que les téléchargements, bases de données d’applications ou analyses médias échouent, résistez à la tentation de forcer un remontage en lecture-écriture. La voie la plus sûre est de préserver les données lisibles, d’identifier si le blocage se produit au niveau du partage, du système de fichiers, du pool ou du disque, puis d’utiliser la méthode de réparation adaptée à cette pile de stockage.

D’abord, figez les modifications et protégez les données lisibles

Considérez le mode lecture seule comme un avertissement, pas comme la faute elle-même. Mettez en pause les tâches de synchronisation, les conteneurs, l’indexation des médias, les téléchargements et la rotation des sauvegardes pour que les tentatives répétées ne masquent pas les erreurs initiales ni ne stressent un disque faible.

Si des fichiers importants restent lisibles, copiez les données les plus irremplaçables sur un stockage sain séparé avant d’essayer la réparation. Dans un cas rapporté, un système de fichiers en lecture seule après une coupure de courant est revenu après des tentatives de réparation temporaires, montrant pourquoi une récidive doit être considérée comme non résolue.

1. Mettez en pause les services et les écritures des clients.
2. Copiez ailleurs les fichiers critiques lisibles.
3. Sauvegardez les écrans d’état du stockage et les journaux d’événements.
4. Enregistrez la configuration du pool et le type de système de fichiers.
5. Commencez les vérifications sans modifier l’ensemble RAID.

Cet ordre préserve à la fois les données et les preuves. Un redémarrage, un assemblage forcé, une réparation ou un remontage peut modifier l’état que vous devez diagnostiquer, donc ne faites pas de l’un de ces actes la première expérience.

Qu’est-ce qui est réellement devenu en lecture seule ?

Un échec de téléchargement ne prouve pas que tout le volume est en lecture seule. Un partage, un ensemble de données, un répertoire d’application, un système de fichiers, un pool de stockage ou un périphérique physique peut bloquer les écritures, et chaque couche nécessite une correction différente.

Comparez la défaillance depuis le tableau de bord NAS et depuis plus d’un client. Le schéma ci-dessous distingue un problème d’accès d’un événement de protection du stockage avant de toucher aux disques ou d’exécuter un outil de réparation du système de fichiers.

Si le NAS lui-même peut créer un fichier test mais que les clients ne le peuvent pas, restez au-dessus de la couche système de fichiers. Si les écritures locales échouent aussi et que le tableau de bord signale un volume en lecture seule, poursuivez avec les journaux et la santé du pool.

Lisez les journaux avant qu’ils ne disparaissent

La première preuve utile est l’événement immédiatement avant que le volume ne devienne en lecture seule. Consultez le journal des événements système, l’historique du gestionnaire de stockage et les messages du noyau pour le démarrage affecté et celui précédent.

Certains systèmes de fichiers arrêtent les écritures après avoir détecté une erreur. Dans un cas où un système est soudainement devenu en lecture seule, les intervenants ont averti que les nouvelles entrées du journal pourraient ne pas atteindre le disque. Capturez les messages actuels du noyau avant de redémarrer autant que possible.

Sauvegardez les entrées contenant des erreurs de système de fichiers, des arrêts du journal, des échecs de somme de contrôle, des réinitialisations de périphériques, des délais d’attente ou des erreurs d’E/S en lecture/écriture. Notez l’identifiant du périphérique et l’horodatage ; les fautes répétées sur le même membre sont plus importantes qu’un simple avis de « fermeture non propre ».

Vérifiez le pool ou le RAID avant le système de fichiers

Un système de fichiers repose sur un pool, un ensemble RAID, un volume logique, un contrôleur et des disques. Si cette couche inférieure est incomplète ou instable, la réparation du système de fichiers peut lire des données incohérentes ou ajouter une charge au pire moment.

Pour le RAID logiciel Linux, un ensemble RAID 5 ou RAID 6 sale et dégradé peut comporter un risque de corruption indétectable ; la règle de l’ensemble sale et dégradé explique pourquoi le démarrage automatique peut être refusé. Ne forcez pas l’assemblage simplement pour effacer un avertissement du tableau de bord.

Vérifiez que chaque membre est présent, qu’une reconstruction ou un resilver est en cours, et que les compteurs de lecture, écriture ou somme de contrôle augmentent. Notez l’ordre des membres et le statut exact sans forcer l’assemblage, remplacer un disque ou lancer un scrub. Stabilisez le pool avant de vérifier le système de fichiers au-dessus.

Vérifiez la santé du disque, le câblage et l’alimentation

Examinez chaque disque dur, SSD et périphérique NVMe, y compris les dispositifs de cache et de métadonnées. Utilisez la page de santé du NAS pour inspecter la santé SMART ou NVMe, les autotests récents, les températures, les erreurs médias et si un périphérique a disparu après l’arrêt.

Ne vous fiez pas à un seul badge vert « sain ». Corrélez les résultats de santé avec les erreurs d’E/S du noyau, les réinitialisations de périphériques et le moment où le volume a changé d’état. Un résumé positif n’explique pas une faute enregistrée ailleurs dans le chemin de stockage.

Éteignez proprement le NAS avant de réinsérer une connexion d’alimentation ou de données accessible, et ne changez qu’une variable à la fois. Si plusieurs disques disparaissent ensemble ou si des erreurs suivent un port plutôt qu’un disque, cessez de blâmer les disques individuels et examinez le chemin partagé.

Adapter l’outil de réparation au système de fichiers

Ext4 et XFS : réparation hors ligne avec les outils natifs

Ext4 utilise e2fsck, tandis que XFS utilise xfs_repair ; aucun ne doit être utilisé sur un volume monté ou un chemin de périphérique incertain. Si le NAS ne peut pas démonter le volume en toute sécurité, utilisez son flux de maintenance ou un environnement de récupération pris en charge.

Un guide pratique de dépannage des systèmes de fichiers sépare les vérifications de la famille ext de la réparation XFS et place les vérifications sur un système de fichiers démonté. Préservez une sauvegarde, identifiez le périphérique exact et commencez par le mode natif non modifiant du système de fichiers lorsqu’il est disponible.

Btrfs : privilégier les vérifications en lecture seule et les conseils d’experts

Btrfs sépare le scrub, la vérification structurelle et la réparation. Un scrub valide les sommes de contrôle et peut utiliser une bonne réplique, tandis qu’une vérification structurelle examine les objets du système de fichiers ; aucun ne doit être considéré comme un interrupteur générique rendant un volume endommagé accessible en écriture.

L’avertissement officiel de vérification Btrfs recommande de démonter d’abord et met explicitement en garde contre l’utilisation de --repair sans guide expérimenté. Commencez par une récupération des données lisibles et une vérification non modifiante, puis suivez la procédure de récupération documentée par le fournisseur NAS.

ZFS : stabiliser le pool avant le scrub

ZFS n’utilise pas un flux de travail fsck traditionnel. Lisez d’abord le statut du pool, préservez les fichiers critiques et résolvez les périphériques manquants ou défaillants avant d’ajouter la charge d’E/S soutenue d’un scrub.

Un scrub de pool OpenZFS vérifie les sommes de contrôle des blocs et peut réparer à partir de bonnes répliques, mais il est intensif en E/S et ne peut pas inventer une copie valide lorsque la redondance est épuisée. Lancez-le uniquement après que le pool soit stable et que les données critiques soient protégées.

Quand restaurer les écritures — et quand s’arrêter

Restaurer le service en lecture-écriture uniquement après que le pool soit stable, que la vérification hors ligne pertinente ou la récupération native soit terminée, et que les journaux récents ne montrent aucune erreur récurrente d’E/S ou de métadonnées. Ensuite, démarrez un service à faible risque et testez un fichier jetable avant de reprendre les charges de travail normales.

Si un remontage forcé échoue ou si le volume revient immédiatement en lecture seule, considérez ce résultat comme une nouvelle preuve. Répéter la même commande ne supprime pas la cause ; cela augmente seulement les écritures, la chaleur et la pression sur la récupération.

Arrêtez la réparation DIY lorsque plusieurs membres du pool manquent, que les compteurs d’erreurs continuent d’augmenter, qu’un disque clique ou se déconnecte à répétition, que les sommes de contrôle sont irrécupérables, ou que la seule copie lisible est critique. Conservez les journaux et l’ordre des périphériques, maintenez le système éteint si le matériel est instable, et contactez un service qualifié de récupération de stockage ou le support de la plateforme.

Prévenir la prochaine extinction non sécurisée

Utilisez un onduleur capable de signaler au NAS de s’éteindre automatiquement, pas seulement une batterie avec des ports de communication inutilisés. Cette checklist NAS en cas de coupure de courant couvre la communication d’arrêt, les vérifications post-coupure et pourquoi une alimentation stable est importante pendant la récupération.

Gardez les copies de récupération en dehors du pool actif. Le RAID peut préserver la disponibilité après certaines défaillances de disque, mais il suit la corruption en direct et ne fournit pas une version propre antérieure ; la distinction entre RAID et la récupération par sauvegarde est cruciale lorsque la réparation échoue.

Enfin, activez les alertes disque, pool et onduleur ; planifiez des vérifications ou des scrubs adaptés au système de fichiers ; et testez périodiquement une petite restauration. Un démarrage réussi est utile, mais un chemin de récupération vérifié transforme la prochaine extinction en un événement contrôlé plutôt qu’en crise.

FAQ

Un redémarrage peut-il réparer un volume NAS en lecture seule ?

Un redémarrage peut terminer la relecture du journal ou effacer un état temporaire de service, mais ce n’est pas une preuve que le stockage est sain. Vérifiez d’abord les journaux sauvegardés et l’état du pool, surtout si le volume est déjà passé en lecture seule plusieurs fois.

Puis-je forcer un remontage en lecture-écriture assez longtemps pour copier des fichiers ?

Privilégiez la copie depuis l’état existant en lecture seule. Un montage forcé en écriture peut déclencher de nouvelles mises à jour des métadonnées et peut échouer immédiatement si le noyau détecte encore des erreurs. Utilisez-le uniquement dans le cadre d’un plan de récupération spécifique au système de fichiers après avoir protégé la meilleure copie disponible.

Que faire si SMART est valide mais que les journaux montrent toujours des erreurs d’E/S ?

Considérez les journaux comme des preuves non résolues. La panne peut impliquer une interface, un câble, un backplane, un contrôleur, un chemin d’alimentation ou un problème de disque non résumé par le résultat global SMART. Isolez un composant à la fois et arrêtez-vous si les erreurs persistent.

La première vérification la plus sûre est celle qui préserve les options : protéger les données lisibles, identifier la couche bloquée, et laisser les preuves vérifiées—et non un remontage forcé—choisir la prochaine action.