Pourquoi une sauvegarde NAS domestique exclut-elle les fichiers cachés et les métadonnées des applications ?
La sauvegarde exclut généralement un chemin, elle ne perd pas aléatoirement des données cachées.
Sur un NAS domestique, les fichiers cachés et les métadonnées des applications sont souvent manqués parce que la tâche a sélectionné uniquement le partage visible, une règle d’ignorance a correspondu au chemin, l’identité de sauvegarde n’avait pas accès, ou les données se trouvaient dans un volume de conteneur, une base de données, un lien symbolique ou un système de fichiers monté en dehors de l’arborescence choisie. La réparation commence par localiser l’unité de récupération manquante et tester la cause la plus probable et la plus petite.
Associer le Résultat Manquant au Premier Test
Commencez par le résultat de la restauration plutôt que par le statut de réussite verte. Différents schémas de données manquantes indiquent différentes couches du travail de sauvegarde.
Si tous les fichiers pointés sont absents, inspectez les filtres de fichiers cachés et les motifs ; si une application revient sans ses paramètres, cartographiez sa base de données, ses secrets et ses volumes ; si un dossier protégé est absent, testez l’accès avec l’identité de sauvegarde planifiée. Ces observations réduisent la cause avant toute modification des règles de production.
Notez le chemin manquant, le nombre d’éléments attendu, l’emplacement réel de la restauration et le premier test échoué. Ces preuves deviennent la base de comparaison pour l’exécution corrigée.
Le tableau transforme le symptôme visible en une première action à faible risque.
| Résultat Manquant | Couche Probable | Premier Test |
|---|---|---|
| Tous les fichiers pointés manquent | Filtre ou règle d’attribut caché | Inspecter l’ordre d’inclusion/exclusion |
| Les fichiers de l’application existent mais les paramètres ont disparu | Base de données ou volume hors du partage | Cartographier les montages et chemins d’état |
| Seuls les dossiers protégés sont absents | Accès du compte de service | Lister en tant qu’identité de sauvegarde |
| Le sous-arbre monté est vide | Montage ou traversée de lien symbolique | Comparer la cible réelle et l’ID du périphérique |
Utilisez une ligne à la fois. Modifier les filtres, permissions et montages ensemble peut rendre impossible l’attribution du prochain succès.
Vérifier la Portée de la Source et les Règles d’Ignorance comme une Seule Décision
Une tâche ne peut pas protéger des données en dehors de ses racines sélectionnées, même lorsque l’interface NAS imbrique visuellement plusieurs ensembles de données sous un même partage. La portée de la source et les motifs d’ignorance doivent donc être revus ensemble.
Les utilisateurs de Duplicity peuvent exclure les chemins préfixés par un point avec un motif d’exclusion de chemin caché. Des règles similaires peuvent exister dans un modèle NAS, une ligne de commande, une variable d’environnement, un fichier marqueur ou une configuration par dossier.
Exportez les paramètres de la tâche et comparez chaque racine sélectionnée avec le chemin réel de l’élément manquant. Testez le motif suspect sur un petit arbre de mise en scène et réduisez uniquement la règle qui exclut le contenu critique pour la récupération.
Trouver l’État de l’Application en Dehors du Dossier Partagé Visible
Les applications auto-hébergées séparent souvent les fichiers utilisateur de l’état de l’application. Un dossier photo peut contenir les originaux tandis que la base de données, les vignettes, les données faciales, les secrets et la configuration vivent ailleurs.
Les déploiements en conteneur utilisent des volumes Docker persistants et des montages liés pour stocker l’état indépendamment de l’image. Sauvegarder uniquement le partage média peut donc préserver les fichiers visibles tout en omettant l’état nécessaire à la reconstruction de l’application.
Inventoriez l’unité complète de récupération : fichier Compose, variables d’environnement, secrets, volumes nommés, montages liés, dump de base de données, configuration de l’application et chemins des données utilisateur. Ajoutez les sources réelles ou une exportation consciente de l’application au lieu de supposer qu’un seul partage contient tout.
Tester les Permissions et la Traversée en tant qu’Identité de Sauvegarde
Un administrateur peut parcourir un chemin que le compte de sauvegarde planifié ne peut pas lire. Un sous-arbre monté ou un lien symbolique peut aussi sembler local alors que l’outil de sauvegarde refuse de le traverser ou de le suivre.
Un cas de support de sauvegarde a retracé des données NAS ignorées à un accès du compte de sauvegarde. Exécutez une liste non destructive en tant que compte de service exact et enregistrez chaque répertoire refusé avant de modifier les ACL.
Puis comparez les points de montage, les ID de périphérique, les cibles des liens symboliques, l’état des dossiers chiffrés et les mappages UID des conteneurs. Si la cible se trouve ailleurs, ajoutez le chemin réel comme source et documentez si l’outil stocke le lien, le suit ou s’arrête à la limite du système de fichiers ; la gestion réelle des liens symboliques montre pourquoi ce comportement ne peut être supposé.
Séparer les Métadonnées Critiques pour la Récupération des Données Cachées Jetables
Activer chaque dossier caché peut augmenter le temps de scan et la taille du dépôt sans améliorer la récupération. La bonne décision est de savoir si l’élément est nécessaire pour reproduire les données utilisateur ou l’état de l’application.
Les clés, configurations, bases de données, manifestes, secrets, évaluations, albums et sidecars irremplaçables sont généralement critiques pour la récupération. Les caches de vignettes, sockets d’exécution, téléchargements temporaires, fichiers de verrouillage et index facilement régénérables peuvent être jetables ou de priorité moindre.
Documentez la classification dans le plan de sauvegarde. Une exclusion délibérée doit nommer la méthode de reconstruction et le délai de récupération acceptable ; tout ce qui n’a pas de chemin de reconstruction documenté doit rester protégé jusqu’à ce qu’une restauration isolée prouve le contraire.
Vérifier que la Sauvegarde Corrigée Contient Toute l’Unité de Récupération
Effectuez une nouvelle sauvegarde après avoir changé uniquement la cause confirmée, puis comparez les inventaires source et sauvegarde. Un second statut vert reste insuffisant lorsque le nombre d’éléments ou l’état restauré de l’application reste inférieur à ce qui est attendu.
Utilisez le guide existant pour signes d’alerte d’une sauvegarde silencieusement incomplète lorsque la durée, le nombre d’octets, les exclusions, les objets ignorés ou le comportement de restauration s’écartent de la base.
Restaurez les fichiers cachés ou l’état de l’application dans un dossier isolé ou un conteneur de test et ouvrez-le via le chemin utilisateur attendu. Arrêtez et repensez la méthode si la seule capture disponible est une copie en direct non sécurisée d’une base de données en cours d’exécution.
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...
