Un message de Duplicati indiquant qu’un .dblock.zip.aes qu’un fichier .dblock est manquant évoque une corruption de la sauvegarde, mais le fil d’origine montre pourquoi une réparation destructive ne doit pas être la première réaction. La destination de sauvegarde existait sur l’hôte ZimaOS et était visible via Samba, mais le conteneur Duplicati ne pouvait pas réellement voir ce disque dur via ses mappages de volumes Docker.
Une fois que l’utilisateur a mappé le véritable disque dur de l’hôte dans le conteneur et sélectionné la nouvelle destination côté conteneur, il a répondu que cela semblait fonctionner. La discussion s’est donc conclue par une résolution confirmée liée au mappage des chemins Docker, et non par une purge confirmée d’une sauvegarde endommagée.
L’erreur initiale ressemblait à un dépôt Duplicati endommagé
Duplicati a indiqué que la réparation avait échoué, car il manquait un fichier chiffré spécifique dans la destination de stockage de la sauvegarde : dblock fichier. Le message proposait deux pistes de récupération : reconstruire les fichiers de blocs manquants à partir des données sources locales ou purger les entrées de sauvegarde qui ne pouvaient plus être restaurées.
Ces options sont bien des fonctionnalités de Duplicati, mais elles n’ont de sens qu’après avoir vérifié que la destination de sauvegarde consultée est la bonne et qu’elle est complète.
L’utilisateur sauvegardait un disque local sur un autre
La configuration prévue était la suivante :
- données sources sur un SSD local ;
- destination de sauvegarde sur un disque dur distinct ;
- Duplicati a été installé depuis l’App Store de ZimaOS et s’exécutait donc dans Docker.
L’utilisateur a sélectionné des chemins via le sélecteur de dossiers de l’application et a supposé que cela signifiait que le conteneur pouvait voir le même stockage de l’hôte.
Un chemin d’hôte ZimaOS et un chemin de conteneur Duplicati ne sont pas la même chose
Une application Docker ne voit que les dossiers de l’hôte qui ont été montés dans le conteneur. ZimaOS peut accéder à un disque via Fichiers ou Samba, tandis que Duplicati ne voit rien si ce disque est absent de la configuration des volumes de l’application.
C’est pourquoi un simple test de connexion peut être trompeur : le type de destination peut être valide alors que le contenu du dossier souhaité n’est pas réellement visible dans l’espace de noms du conteneur.
Le test avec un fichier temporaire a révélé le véritable problème
L’utilisateur a créé un temp.txt dans le dossier de destination. Il était visible via Samba, mais pas dans le navigateur de fichiers de Duplicati. Cela indiquait fortement que Duplicati ne voyait pas le contenu réel du disque dur de l’hôte.
À ce stade, l’intervenant de la communauté a explicitement changé d’approche et conseillé de ne pas lancer de purge ni de reconstruction pour le moment.
La solution fonctionnelle consistait à mapper le disque dur dans le conteneur
L’intervenant a demandé à l’utilisateur d’ouvrir les paramètres de l’application ZimaOS, d’ajouter le disque dur comme volume de l’hôte et de le mapper vers un chemin simple dans le conteneur, tel que /backup, redémarrez le conteneur, puis choisissez une destination sous ce chemin du conteneur.
L’auteur du message initial a répondu : « Cela semble fonctionner maintenant. »
Cela a confirmé que le mappage des volumes était la solution concrète.
Les disques sources supplémentaires nécessitent leurs propres mappages
L’utilisateur a ensuite demandé si une même tâche Duplicati pouvait contenir plusieurs dossiers sources. La réponse de la communauté était oui, à condition que chaque chemin source soit également visible dans le conteneur.
Si un deuxième disque n’est pas exposé par les volumes Docker de l’application, il n’apparaîtra pas correctement dans Duplicati, quelle que soit la validité du chemin de l’hôte.
Utilisez le mappage actuel des volumes d’application de ZimaOS au lieu de deviner les chemins bruts
ZimaOS affiche actuellement les chemins de l’hôte et du conteneur dans les paramètres des applications et explique comment le stockage persistant est mappé dans les applications Docker.
Utilisez le modèle actuel de chemins Docker de ZimaOS lors de l’ajout de sources ou de destinations de sauvegarde.
Quand la réparation Duplicati est appropriée
La documentation actuelle de Duplicati en ligne de commande indique que la réparation peut reconstruire la base de données locale à partir du stockage distant ou tenter de reconstituer les données distantes manquantes lorsque le contenu source local requis est toujours disponible.
La documentation avancée --rebuild-missing-dblock-files Cette option tente spécifiquement de recréer les fichiers de blocs manquants à partir des données sources locales, mais Duplicati avertit que les données peuvent avoir changé et que la récupération peut être incomplète ou lente.
purge-broken-files est destructif pour l’historique des restaurations
La documentation actuelle de Duplicati indique purge-broken-files supprime des fichiers des versions de sauvegarde qui ne peuvent plus être restaurées afin que l’ensemble de sauvegarde puisse continuer à fonctionner. Cette commande ne doit être utilisée que lorsque les données distantes manquantes ne peuvent pas être récupérées.
Avant toute purge, consultez les commandes de récupération actuelles de Duplicati et leurs conséquences. Une simulation ou une liste des fichiers endommagés est plus sûre que de supprimer aveuglément l’historique des sauvegardes.
Le message d’erreur était réel, mais la destination sous-jacente était incorrecte
Duplicati signalait correctement que la vue du dépôt à laquelle il avait accès ne contenait pas les fichiers attendus. L’élément trompeur était de supposer que cette vue du dépôt représentait le véritable disque dur. Le mappage des chemins Docker dirigeait l’application vers une vue incomplète ou différente du système de fichiers.
FAQ sur les fichiers dblock de Duplicati
Le dépôt de sauvegarde source a-t-il été confirmé comme corrompu ?
Non. Le problème de la source a été résolu après la correction du mappage du volume Docker.
La purge des fichiers endommagés doit-elle être la première étape ?
Non. Vérifiez que la destination complète et correcte est montée et visible avant toute réparation destructive.
Une tâche Duplicati peut-elle sauvegarder plusieurs disques ZimaOS ?
Oui, mais chaque disque source doit être mappé dans le conteneur Duplicati.
