Pourquoi un disque USB de sauvegarde, après avoir été reconnecté, se voit-il attribuer un chemin de montage suffixé ?
Un disque USB de sauvegarde alterné peut recevoir un chemin de montage suffixé lorsque le répertoire préféré basé sur son étiquette est déjà occupé, dupliqué ou attribué par un autre outil de montage automatique.
La rotation des sauvegardes utilise souvent plusieurs disques similaires, et les administrateurs peuvent cloner des systèmes de fichiers ou réutiliser la même étiquette de volume par commodité. Après un redémarrage, l’ordre de détection, le montage automatique du bureau, d’anciens répertoires de montage, des étiquettes en double ou une entrée fstab concurrente peuvent forcer un disque à apparaître sous un chemin tel que BACKUP_1 au lieu de BACKUP. Le disque peut être en parfait état alors que la tâche de sauvegarde cible désormais le mauvais répertoire. Vérifiez son identité avant de déplacer des fichiers ou de modifier les chemins.
Identifier le système de fichiers derrière le chemin inattendu
Notez le périphérique réel, l’UUID du système de fichiers, l’étiquette, le numéro de série ou le chemin by-id, la source du montage, la cible, le type de système de fichiers et les options pour chaque disque de rotation connecté.
La commande findmnt de Linux associe une cible à sa source active, évitant de confondre un nom de dossier trompeur avec le disque de sauvegarde prévu.
Si le répertoire suffixé correspond au bon UUID, le problème vient de l’attribution du chemin. S’il correspond à un autre disque, interrompez la sauvegarde avant qu’elle n’écrive dans le mauvais ensemble de rotation.
Rechercher les étiquettes ou UUID de systèmes de fichiers en double
Comparez l’UUID, l’étiquette, le PARTUUID, le numéro de série et les noms by-id de chaque disque de rotation, y compris les disques actuellement hors ligne si des relevés sont disponibles.
ArchWiki explique que les étiquettes sont plus faciles à dupliquer que les UUID, ce qui rend le montage automatique basé uniquement sur l’étiquette risqué lorsque plusieurs disques de sauvegarde partagent volontairement un nom convivial.
Le clonage d’un système de fichiers peut également cloner son UUID. Attribuez une identité unique à chaque système de fichiers avant de vous fier à une rotation sans surveillance, et indiquez quel disque physique possède chaque identifiant.
Comprendre pourquoi les outils de montage automatique ajoutent un suffixe
Vérifiez si une session de bureau, un service NAS, un utilitaire UDisks ou un gestionnaire de supports amovibles a monté le disque avant l’intervention de fstab ou du service de sauvegarde.
Le Filesystem Hierarchy Standard autorise l’ajout de chiffres aux répertoires de montage des supports amovibles lorsque plusieurs périphériques nécessitent un emplacement de montage similaire.
La politique exacte de suffixation varie selon l’outil de montage automatique, mais le principe de diagnostic reste le même : le chemin préféré était indisponible ou ambigu lorsque le périphérique est arrivé.
Vérifier si le répertoire de montage préféré était déjà occupé
Inspectez le répertoire attendu avant de connecter le disque. Déterminez s’il contient un autre montage, des fichiers isolés écrits lorsque le disque était absent, un montage bind ou le répertoire de travail obsolète d’un processus.
Les recommandations d’Oracle concernant les supports amovibles indiquent que les étiquettes des supports servent à nommer les chemins de montage, ce qui crée une collision lorsque plusieurs supports présentent le même chemin dérivé de leur étiquette.
Ne supprimez pas un répertoire occupé avant d’avoir vérifié s’il contient des sauvegardes écrites par erreur sur le système de fichiers racine. Déplacez les données isolées vérifiées dans le cadre d’un processus de récupération contrôlé.
Définir un point de montage fstab fixe pour chaque disque de rotation
Choisissez une politique stable : soit chaque disque physique reçoit son propre répertoire fixe, soit un script de rotation monte l’UUID sélectionné à l’emplacement de sauvegarde contrôlé après vérification de son identité.
Red Hat documente le montage persistant via fstab avec un UUID et un point de montage fixe, éliminant l’ordre de détection et les collisions entre étiquettes conviviales du chemin sans surveillance.
Ne créez pas plusieurs entrées fstab actives qui se disputent le même répertoire cible. Un processus de rotation doit confirmer que l’ancien disque est démonté avant de connecter le suivant.
Faire dépendre le démarrage de la sauvegarde du montage vérifié
Vérifiez si le planificateur démarre avant la fin de la détection et du montage USB. Ajoutez une vérification préalable de l’UUID, du point de montage, de l’état accessible en écriture et du fichier marqueur attendu.
La documentation Debian sur les montages systemd explique que les entrées fstab deviennent des dépendances de montage systemd, permettant aux services de sauvegarde d’attendre un montage précis plutôt qu’un répertoire arbitraire.
La simple vérification de l’existence du répertoire est insuffisante, car le répertoire nu existe même lorsque le disque est absent. Validez l’identité du système de fichiers monté.
Tester toute la rotation après un redémarrage et un échange de disques
Pour chaque disque, effectuez un démontage propre, une déconnexion, un redémarrage, une reconnexion, une validation de l’identité, une écriture temporaire, une simulation de sauvegarde et une vérification par relecture. Notez le chemin et l’UUID attendus.
L’article de ZimaSpace sur les montages par UUID et les chemins d’application stables présente la conception générale basée sur des chemins fixes ; cet article se concentre sur les collisions créées par la rotation de plusieurs disques de sauvegarde amovibles.
Le problème est résolu lorsque chaque disque de rotation correspond à son chemin documenté après plusieurs tests de redémarrage et d’échange, et que la sauvegarde refuse de s’exécuter lorsque l’UUID attendu est absent ou monté ailleurs.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
