Pourquoi Restic ou Borg signalent-ils qu’un dépôt est introuvable ou a été déplacé après une modification du point de montage ?
Restic ou Borg peuvent sembler avoir oublié un dépôt lorsque le chemin configuré pointe désormais vers un répertoire vide, un autre système de fichiers ou l’emplacement modifié d’un dépôt existant.
Les données du dépôt peuvent toujours être intactes sur le disque de sauvegarde, mais la tâche peut ouvrir le simple répertoire de montage avant l’arrivée du disque, utiliser un chemin de conteneur modifié, lire une variable d’environnement obsolète ou refuser un dépôt Borg dont l’identifiant apparaît à un nouvel emplacement. Diagnostiquez la source montée et l’identité du dépôt avant toute initialisation. Exécuter une commande d’initialisation sur le mauvais chemin vide peut créer un second dépôt et masquer le problème initial.
Confirmer ce qui est monté sur le chemin de dépôt configuré
Notez le chemin du dépôt utilisé par la tâche planifiée, puis comparez-le avant et après le montage du disque de sauvegarde. Relevez la source du système de fichiers, l’UUID, le point de montage et la capacité disponible.
L’utilitaire Linux findmnt détermine le montage actif associé à un chemin cible. C’est donc la première vérification à effectuer lorsqu’un répertoire familier peut en réalité être le dossier hôte non monté.
Si le chemin appartient au système de fichiers racine plutôt qu’au disque de sauvegarde, arrêtez le service de sauvegarde avant qu’il n’écrive un nouveau dépôt ou un nouvel ensemble de sauvegardes dans ce répertoire vide.
Vérifier l’emplacement exact du dépôt Restic
Comparez le chemin transmis avec -r, --repository-file ou RESTIC_REPOSITORY au point de montage actuel. Vérifiez les scripts intermédiaires, les champs du NAS, les fichiers d’identifiants et les environnements des tâches planifiées.
Restic définit un dépôt local comme un répertoire spécifique contenant sa configuration, ses données, son index, ses clés, ses verrous et ses instantanés. Modifier le point de montage modifie donc l’emplacement que la commande tente d’ouvrir.
N’exécutez pas restic init simplement parce que le nouveau chemin indique qu’aucun dépôt n’existe. Localisez d’abord les répertoires de configuration et de données du dépôt d’origine sur le disque monté.
Gérer délibérément l’avertissement de déplacement de dépôt de Borg
Notez l’URL du dépôt Borg, son identifiant, son ancien emplacement, son emplacement actuel, le chemin du cache et le répertoire de sécurité. Confirmez que le même dépôt a bien été déplacé volontairement.
La FAQ de Borg explique que le logiciel demande une approbation après le déplacement d’un dépôt, car voir le même identifiant de dépôt à un nouveau chemin peut également signaler une substitution dangereuse.
N’autorisez le déplacement qu’après avoir comparé l’identifiant du dépôt et le contenu du stockage. Ne désactivez pas l’avertissement globalement lorsque plusieurs dépôts amovibles peuvent être connectés via des chemins changeants.
Remplacer les chemins dépendant de l’ordre des périphériques par une identité de stockage persistante
Vérifiez si la configuration du montage fait référence à /dev/sdX, à un libellé dupliqué, à l’UUID du système de fichiers, à l’UUID de partition ou à un identifiant de périphérique. Comparez tous les disques utilisés en rotation afin de détecter les identifiants en double.
L’ArchWiki indique que les UUID réduisent les collisions de noms par rapport aux libellés et aux noms de périphériques attribués par le noyau, qui peuvent changer selon l’ordre de détection.
Un identifiant stable doit néanmoins correspondre au répertoire de montage fixe prévu. L’UUID empêche les changements liés à l’ordre des disques, mais il ne met pas à jour une tâche de sauvegarde qui contient encore l’ancien chemin.
Vérifier la traduction des chemins des conteneurs et des montages liés
Pour une interface Restic, Borg ou de sauvegarde conteneurisée, comparez le point de montage hôte avec la source du montage lié et le chemin du dépôt à l’intérieur du conteneur. Inspectez le conteneur en cours d’exécution plutôt que son seul fichier compose enregistré.
Docker précise que les montages liés dépendent du chemin hôte exact. Déplacer un disque de /mnt/backup-a vers /media/backup-a peut donc laisser le conteneur associé à un répertoire vide.
Conservez le chemin matériel stable sur l’hôte et exposez un seul chemin stable dans le conteneur. N’enregistrez pas directement dans la configuration du dépôt des chemins de supports amovibles propres à l’hôte lorsqu’un mappage fixe est disponible.
Faire attendre le service de sauvegarde jusqu’au montage
Comparez les horodatages du démarrage et du service. Confirmez que le montage est terminé avant que le planificateur de sauvegarde, le conteneur, l’interface du dépôt ou la tâche de maintenance ne tente d’y accéder.
Les recommandations de Red Hat concernant les montages persistants préconisent de définir un montage fixe dans fstab, qui peut ensuite être associé à des dépendances de service et à une validation préalable au démarrage.
L’option de démarrage nofail peut convenir à un disque de sauvegarde amovible, mais le service de sauvegarde doit tout de même refuser de démarrer lorsque le système de fichiers requis est absent.
Reconnecter le dépôt existant avant d’exécuter une sauvegarde
Arrêtez les planifications, montez le système de fichiers prévu sur le chemin fixe, vérifiez la structure du dépôt, ouvrez-le en lecture seule ou listez les instantanés, puis effectuez une petite vérification du dépôt avant de réactiver les écritures.
L’article de ZimaSpace sur les chemins d’application stables fondés sur l’UUID présente la chaîne de montage générale ; cet article se concentre sur l’identité du dépôt et la sécurité des outils de sauvegarde après une modification du chemin.
Le problème est résolu lorsque le même identifiant de dépôt et le même historique d’instantanés s’ouvrent au chemin prévu après plusieurs tests de redémarrage et de rotation des disques, sans qu’aucun nouveau dépôt ne soit créé dans le simple répertoire de montage.
Questions fréquentes
Un dépôt Restic peut-il être déplacé vers un autre point de montage ?
Oui, à condition que l’intégralité du dépôt soit déplacée sans modification et que toutes les tâches fassent désormais référence au nouvel emplacement. Restic identifie le dépôt à partir du chemin ou du backend fourni à la commande.
Pourquoi Borg affiche-t-il un avertissement alors que les données du dépôt n’ont pas changé ?
Borg enregistre l’identité du dépôt et son emplacement précédent à des fins de sécurité. La présence du même identifiant à un autre chemin nécessite une approbation explicite.
Dois-je initialiser un dépôt au nouvel emplacement ?
Non, pas avant d’avoir prouvé que l’ancien dépôt est absent. Initialiser un point de montage vide crée un dépôt distinct au lieu de reconnecter le dépôt d’origine.
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,...
