Qu’est-ce qui peut faire apparaître un jeu de données ZFS vide après son montage réussi ?
Un jeu de données ZFS peut indiquer qu’il est monté tout en sembler vide lorsque les données attendues se trouvent dans un jeu de données enfant, un point de montage masqué ou une autre racine d’importation.
L’indicateur de montage prouve qu’un jeu de données est attaché à un chemin, mais ne prouve pas que ce chemin est celui attendu par une application ou un utilisateur, que les jeux de données enfants y sont montés ou qu’un descendant chiffré a été déverrouillé. Un jeu de données parent vide peut être parfaitement sain tandis que tous les fichiers réels se trouvent dans ses enfants. Commencez par comparer les propriétés des jeux de données, l’espace référencé, les tables de montage et le contenu du répertoire avant de copier des données ou de modifier la structure du pool.
Comparez l’espace du jeu de données avec le répertoire ouvert
Notez le nom du jeu de données ainsi que ses valeurs USED, REFER, AVAIL, MOUNTPOINT et MOUNTED. Listez ensuite le répertoire exact affiché à l’utilisateur ou à l’application.
Si le jeu de données indique qu’il contient presque aucune donnée référencée, les fichiers peuvent appartenir à un jeu de données enfant, à un instantané, à un clone ou à un autre jeu de données portant un nom similaire. Le manuel ZFS de FreeBSD décrit les jeux de données comme des systèmes de fichiers gérés séparément ; l’utilisation du pool et le contenu d’un répertoire ouvert ne représentent donc pas nécessairement le même jeu de données.
Ne concluez pas à une perte de données en vous fondant uniquement sur l’explorateur de fichiers graphique. Comparez l’affichage des propriétés ZFS, la table de montage du système d’exploitation et un shell local avec les privilèges root, situé en dehors de tout conteneur ou espace de noms d’application restreint.
Vérifiez ensemble mountpoint, mounted et canmount
Vérifiez si le point de montage du jeu de données est explicite ou hérité, s’il est effectivement monté à ce chemin et si canmount vaut on, off ou noauto.
Les recommandations d’Oracle concernant les propriétés ZFS expliquent que mountpoint et canmount déterminent si un jeu de données est monté automatiquement, uniquement à la demande ou utilisé seulement pour transmettre des propriétés à ses descendants.
Un jeu de données peut fournir des propriétés héritées à ses enfants tout en restant volontairement démonté. À l’inverse, un jeu de données utilisant un point de montage legacy peut sembler correct dans les propriétés ZFS, mais dépendre d’une entrée de montage système distincte qui n’a pas été exécutée.
Inspectez les montages des jeux de données parents et enfants
Affichez l’arborescence complète des jeux de données sous le pool et triez-la par point de montage. Comparez le jeu de données parent avec chaque enfant censé contenir des fichiers utilisateur, des données d’application, des sauvegardes ou des fichiers multimédias.
Un parent vide est fréquent lorsqu’il sert uniquement à organiser les propriétés et les points de montage. L’espace de noms des jeux de données ZFS de FreeBSD traite chaque enfant comme un jeu de données géré séparément ; pool/data peut donc être vide tandis que pool/data/photos contient les fichiers réels.
Si le parent est monté mais pas un enfant, diagnostiquez l’enfant indépendamment. Vérifiez canmount, les clés de chiffrement, les points de montage en conflit, les importations échouées et si un service a démarré avant la fin du montage de l’enfant.
Vérifiez si le montage a masqué des fichiers déjà présents dans le répertoire
Des fichiers peuvent exister dans le répertoire ordinaire avant qu’un jeu de données ne s’y monte. Une fois le jeu de données ZFS monté, ces fichiers sous-jacents sont masqués depuis ce chemin, même s’ils restent présents sur le système de fichiers racine.
Ne démontez le jeu de données que pendant une fenêtre de maintenance contrôlée, puis inspectez le répertoire sous-jacent depuis l’hôte. Le manuel Linux consacré à mount indique que le contenu préexistant du point de montage devient invisible tant que le système de fichiers monté occupe ce chemin.
L’échec inverse peut également se produire : un montage ZFS attendu échoue, laissant visible aux utilisateurs et aux conteneurs le répertoire sous-jacent vide. Un jeu de données sain peut alors sembler vide alors qu’il n’est simplement pas attaché au chemin servi.
Écartez une racine alternative et un comportement de montage legacy
Vérifiez si le pool a été importé avec une racine alternative, une option de récupération, un chemin de montage temporaire ou un nom de pool différent. Un jeu de données peut être monté avec succès sous un chemin de récupération préfixé plutôt qu’à son emplacement de production habituel.
L’importation d’un pool avec une racine alternative réécrit les emplacements de montage des jeux de données par rapport à cette racine temporaire. La documentation de référence de zpool import d’Ubuntu précise que -R définit altroot, tandis que -N permet d’importer le pool sans monter les systèmes de fichiers.
Inspectez également les jeux de données dont le point de montage vaut legacy. Dans ce mode, ZFS ne gère pas automatiquement le montage ; la configuration de montage du système d’exploitation devient donc la source de vérité.
Vérifiez les enfants chiffrés et les espaces de noms de montage des conteneurs
Un jeu de données enfant chiffré peut rester indisponible après le montage de son parent si la clé n’a pas été chargée ou si le montage de l’enfant a échoué. Le répertoire parent paraît alors vide ou incomplet, même si le pool est en ligne.
Vérifiez l’état de la clé et du montage pour chaque descendant chiffré, puis comparez le chemin de l’hôte avec celui présenté au conteneur. La documentation LXD de Canonical explique que les périphériques disque des conteneurs associent les sources de l’hôte à des chemins distincts dans les instances ; un jeu de données enfant visible sur l’hôte peut donc rester absent d’un ancien montage de conteneur.
Si l’hôte voit les données mais pas un conteneur, inspectez la source du bind mount du conteneur et la propagation du montage. Un conteneur créé avant le montage de l’enfant ZFS peut continuer à voir le répertoire sous-jacent vide jusqu’à la recréation du service ou à la propagation correcte du montage.
Rétablissez la vue correcte sans copier le jeu de données
Corrigez uniquement la propriété ou le chemin dont le problème est avéré : montez l’enfant manquant, corrigez un point de montage hérité, supprimez une racine alternative involontaire, réparez l’entrée de montage legacy, chargez la clé de chiffrement ou recréez le conteneur avec la bonne source de bind mount.
La liste de contrôle de récupération d’un serveur domestique de ZimaSpace fournit la règle complémentaire : vérifiez la couche de stockage et l’état des montages avant d’exécuter des outils de réparation ou de restaurer des données.
Le diagnostic est terminé lorsque le jeu de données attendu et ses enfants sont montés aux chemins prévus, que l’espace référencé correspond aux fichiers visibles, que les applications voient la même arborescence que l’hôte et que la configuration résiste à un export, une importation, un redémarrage du service et un redémarrage du système.
Produits recommandés
Assistance et conseils
Plus à lire
Guide de stockage pour l’enregistrement de la télévision en direct : capacité, conservation et nettoyage
Mesurez les enregistrements réels, prévoyez une marge de sécurité, combinez les limites d’ancienneté et de capacité, et vérifiez que le programme admissible le plus...
Flux de récupération des métadonnées multimédias à domicile après la restauration d’une base de données
Protégez l’état restauré, vérifiez l’identité et les chemins des médias, puis corrigez les illustrations ou les correspondances manquantes dans une bibliothèque pilote avant d’appliquer...
Liste de contrôle de compatibilité du client Jellyfin pour l’audio, la vidéo et les sous-titres
Testez des fichiers représentatifs en ne faisant varier qu’un paramètre à la fois, puis consignez pour chaque client la lecture directe, le remuxage, la...
