Comment auto-héberger Duplicati en 2026 : sauvegardes chiffrées, montages et tests de restauration

Si vous avez déjà essayé d’auto-héberger Duplicati, vous connaissez probablement cette situation frustrante : l’interface s’affiche, mais le conteneur voit un chemin vide parce que les sources de l’hôte ont été montées ailleurs. Recréer le conteneur suffit rarement à résoudre un désaccord entre les URL, l’état et les dépendances.

Ce guide utilise un critère de validation concret : sauvegarder un répertoire de test vers la destination choisie, supprimer un fichier source, puis le restaurer dans un autre chemin propre. Chaque choix de configuration est évalué par rapport à ce critère, et non à la présence d’un badge vert sur le conteneur.

Ports, processus et services privés

Un schéma utile de Duplicati montre la route publique, le port privé 8200, la frontière d’état et toutes les dépendances nécessaires. Indiquez quelles flèches transportent des identifiants et lesquelles correspondent à du trafic utilisateur ordinaire. Le contrat réseau de Duplicati consiste en des montages de sources en lecture seule et en un stockage de destination de sauvegarde accessible. Gardez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Duplicati un identifiant de service aux permissions limitées.

Validez le schéma avec une action réelle : sauvegardez un répertoire de test vers la destination choisie, supprimez un fichier source, puis restaurez-le dans un autre chemin propre. Les principaux facteurs de charge sont probablement le nombre de fichiers sources, la compression, le chiffrement, la latence de la destination et le chevauchement des tâches planifiées ; surveillez ce parcours plutôt que de considérer toutes les requêtes HTTP comme équivalentes.

Diagnostiquer un Duplicati qui semble fonctionner

Construisez les tableaux de bord autour du nombre de fichiers sources, de la compression, du chiffrement, de la latence de la destination et du chevauchement des tâches planifiées. Un graphique CPU dépourvu de ce contexte de charge ne peut pas expliquer pourquoi Duplicati est lent. Ajoutez un contrôle synthétique ou planifié qui tente de sauvegarder un répertoire de test vers la destination choisie, de supprimer un fichier source et de le restaurer dans un autre chemin propre à l’aide de données de test inoffensives.

Avant une mise à niveau, tenez compte de ce risque propre à l’application : les modifications de la base de données de configuration et du format de sauvegarde de Duplicati doivent être testées sans réécrire l’unique jeu de sauvegardes distant. Restaurez une sauvegarde récente dans un déploiement isolé, exécutez-y les migrations et comparez le comportement. Si le conteneur voit un chemin vide parce que les sources de l’hôte ont été montées ailleurs, inspectez la frontière concernée — origine publique, stockage ou dépendance — avant de modifier des paramètres sans rapport.

Ce qui doit être validé avant l’arrivée des vraies données Duplicati

Le compte rendu de mise en production de Duplicati doit contenir des faits, pas un simple « ça semble fonctionner ». Enregistrez le digest de l’image sélectionnée, la somme de contrôle de la configuration, le nom d’hôte public et le résultat horodaté de l’opération suivante : sauvegarder un répertoire de test vers la destination choisie, supprimer un fichier source, puis le restaurer dans un autre chemin propre. Utilisez des données d’exemple hors production afin que ce contrôle puisse être exécuté après chaque déploiement.

Validez séparément deux événements du cycle de vie. Le remplacement d’un conteneur doit préserver le fonctionnement normal ; une récupération complète doit montrer qu’une nouvelle instance de Duplicati peut importer la configuration et restaurer les fichiers sélectionnés avec des hashes vérifiés. Pendant l’exécution des contrôles, mesurez le nombre de fichiers sources, la compression, le chiffrement, la latence de la destination et le chevauchement des tâches planifiées, puis conservez le résultat comme enveloppe de référence pour cette version.

Testez également une condition de refus ou d’invalidité : refusez temporairement à l’identité de test l’accès aux montages de sources en lecture seule et au stockage de destination de sauvegarde accessible. Duplicati doit échouer de manière explicite et ne doit pas écraser un état sain. Rétablissez la condition valide, relancez l’exemple et joignez les logs pertinents après suppression des informations sensibles. Ces éléments fournissent des preuves concrètes pour une future décision de rollback.

Transformer la commande locale en service inspectable

La commande suivante rend la frontière du conteneur visible sans prétendre provisionner tous les services externes.

docker run -d \
  --name duplicati \
  --restart unless-stopped \
  -p 127.0.0.1:8200:8200 \
  -v duplicati-data:/config \
  -v /srv/data:/source:ro \
  -e SETTINGS_ENCRYPTION_KEY=replace-with-a-long-random-value \
  lscr.io/linuxserver/duplicati:latest

Avant d’ouvrir l’ingress, inspectez l’environnement résolu, les montages et le listener. Ajoutez les paramètres de connexion validés pour les montages de sources en lecture seule et le stockage de destination de sauvegarde accessible ; utilisez des noms privés pour les services privés. Un lancement réussi ne se termine que lorsque vous pouvez sauvegarder un répertoire de test vers la destination choisie, supprimer un fichier source et le restaurer dans un autre chemin propre, et non lorsque docker ps affiche Up.

Rendre la récupération de Duplicati mesurable

Répertoriez l’état avant la création du premier enregistrement réel : la base de données de configuration de Duplicati ainsi que les jeux de sauvegardes vérifiés séparément. Montez /config avant l’initialisation, écrivez des données d’exemple inoffensives et remplacez le conteneur pour prouver que ce chemin est réellement persistant. Confirmez le montage en écrivant des données inoffensives, en remplaçant Duplicati, puis en les relisant.

Les snapshots sont précieux pour effectuer rapidement un rollback, mais une sauvegarde indépendante est nécessaire si l’hôte ou le volume disparaît. Restaurez dans un environnement vide avec l’image épinglée et vérifiez qu’une nouvelle instance de Duplicati peut importer la configuration et restaurer les fichiers sélectionnés avec des hashes vérifiés. Utilisez les volumes persistants et les snapshots pour maintenir distincts ces deux mécanismes de récupération.

TLS est simple ; les URL générées, beaucoup moins

Exposez un seul hostname HTTPS pour Duplicati et gardez le port brut 8200 privé. Gardez l’interface d’administration privée ou protégez-la fortement derrière HTTPS. Les navigateurs et les clients API ne pourront ainsi pas découvrir deux adresses concurrentes.

Depuis un client propre, exécutez la transaction connue comme fonctionnelle et inspectez la première requête en échec. Utilisez le guide des domaines personnalisés lorsque le DNS ou TLS est incorrect. Considérez « le conteneur voit un chemin vide parce que les sources de l’hôte ont été montées ailleurs » comme un diagnostic applicatif distinct une fois la route validée.

Sécuriser Duplicati après l’initialisation

Les identifiants d’initialisation sont temporaires ; le modèle de confiance, lui, est permanent. Avec Duplicati, surveillez notamment les montages de sources de sauvegarde en lecture-écriture et la perte de la passphrase de chiffrement. Montez les sources en lecture seule, gardez l’interface d’administration privée et stockez la passphrase de sauvegarde en dehors du serveur.

Générez SETTINGS_ENCRYPTION_KEY une seule fois, ne le stockez pas dans Git et conservez-le avec le manifeste de récupération, car sa modification peut invalider l’état applicatif chiffré ou signé. Exécutez l’image sans capabilities Linux superflues et n’exposez que la route applicative publique. Gardez une trace de l’activité des administrateurs sans enregistrer les valeurs secrètes.

Utiliser Dockup pour la couche plateforme

Pour Duplicati, Dockup peut créer la route et le certificat TLS, préserver les montages, fournir les secrets et placer les montages de sources en lecture seule ainsi que le stockage de destination de sauvegarde accessible sur un réseau privé, lors d’un déploiement sur Dockup ou sur des serveurs associés.

Le gate de mise en production reste la transaction Duplicati concrète : sauvegarder un répertoire de test vers la destination choisie, supprimer un fichier source, puis le restaurer dans un autre chemin propre. Vérifiez également la condition de restauration : une nouvelle instance de Duplicati peut importer la configuration et restaurer les fichiers sélectionnés avec des hashes vérifiés. Ces deux contrôles montrent si le déploiement fonctionne et s’il peut être récupéré.

Foire aux questions

De quoi Duplicati a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Duplicati sur le port 8200 via une seule origine HTTPS. La dépendance réseau est constituée de montages de sources en lecture seule et d’un stockage de destination de sauvegarde accessible. Ne considérez pas Duplicati comme prêt tant que vous ne pouvez pas sauvegarder un répertoire de test vers la destination choisie, supprimer un fichier source et le restaurer dans un autre chemin propre.

Quelles données Duplicati faut-il sauvegarder ?

Rendez /config persistant et incluez la base de données de configuration de Duplicati ainsi que les jeux de sauvegardes vérifiés séparément dans le même manifeste de récupération. Une restauration complète de Duplicati n’est validée que lorsqu’une nouvelle instance de Duplicati peut importer la configuration et restaurer les fichiers sélectionnés avec des hashes vérifiés.

Duplicati nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Duplicati et gardez le port 8200 sur la route interne. Appliquez correctement le paramètre Duplicati : gardez l’interface d’administration privée ou protégez-la fortement derrière HTTPS. Pour Duplicati, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transport et garantit un comportement cohérent des clients vis-à-vis de l’origine.

Comment tester une mise à niveau de Duplicati ?

Restaurez l’état actuel de Duplicati dans un déploiement isolé, appliquez la version candidate et répétez sa transaction de validation. Soyez particulièrement vigilant, car les modifications de la base de données de configuration et du format de sauvegarde de Duplicati doivent être testées sans réécrire l’unique jeu de sauvegardes distant. Conservez l’image Duplicati précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.