Orchestrer des sauvegardes restic depuis une interface auto-hébergée

Zerobyte : État du dépôt et positionnement

Les métadonnées du dépôt décrivent Zerobyte comme « Backup automation for self-hosters. Built on top of restic ». Le README précise qu'il s'agit d'un outil d'automatisation de sauvegardes qui aide à enregistrer vos données sur plusieurs backends de stockage, et qu'il fournit une interface web moderne pour planifier, gérer et surveiller des sauvegardes chiffrées de votre stockage distant. Le projet est actuellement en version 0.x.x. Le README avertit qu'il est sujet à des changements majeurs d'une version à l'autre et que les fonctionnalités de base sont encore en cours de développement avec collecte de retours. Toute personne envisageant une utilisation en production doit donc considérer que les interfaces et le comportement sont potentiellement instables.

Pour vérifier Zerobyte, créez d’abord un espace de test contenant uniquement les entrées documentées. Relevez la version, la commande docker compose up -d et chaque clé BASE_URL, APP_SECRET, TZ, /var/lib/zerobyte, puis conservez la sortie complète. Un lancement réussi ne suffit pas : comparez le fichier produit, le journal et l’état attendu dans le README. Si une étape dépend d’un service, d’un GPU, d’un dépôt Nix ou d’un compte de jeu, notez séparément cette dépendance et son effet sur le résultat. Le matériau disponible ne fournit pas de matrice exhaustive de performance ou de compatibilité ; ces points restent à établir dans votre environnement.

Dans ce projet, l’observation utile porte sur BASE_URL, APP_SECRET, TZ, /var/lib/zerobyte. Ne transformez pas une absence de précision dans le README en promesse implicite : consignez plutôt le comportement constaté, le système utilisé et le chemin exact du résultat. Cette méthode permet de distinguer la fonction annoncée de ce que votre installation démontre réellement.

Zerobyte : Installation et déploiement

Selon le README, l'exécution de Zerobyte nécessite Docker et Docker Compose sur le serveur. L'exemple compose.yaml fourni utilise l'image ghcr.io/nicotsx/zerobyte:v0.41, inclut la capacité SYS_ADMIN et le périphérique /dev/fuse pour le montage de partages distants, et définit les variables d'environnement TZ, BASE_URL et APP_SECRET. L'exemple mappe /var/lib/zerobyte comme volume persistant. La commande de démarrage est docker compose up -d, après quoi l'interface web est disponible à l'adresse http://<your-server-ip>:4096. Le README déconseille fortement d'exécuter Zerobyte sur un serveur accessible depuis Internet, recommandant plutôt de se lier à 127.0.0.1 et d'utiliser un tunnel sécurisé avec authentification. Il avertit également de ne pas pointer /var/lib/zerobyte vers un partage réseau et donne aux utilisateurs TrueNAS une alternative avec un dataset ZFS dédié.

Zerobyte : Variables d'environnement et configuration principale

Zerobyte se configure principalement via des variables d'environnement. Le README liste BASE_URL et APP_SECRET comme obligatoires : la première définit l'URL de l'instance et le comportement de sécurité des cookies, la seconde est une clé secrète aléatoire de 32 caractères ou plus utilisée pour chiffrer les données sensibles dans la base de données. APP_SECRET_FILE est une alternative mutuellement exclusive pour les secrets Docker ou Kubernetes. PORT a pour défaut 4096, RESTIC_HOSTNAME a pour défaut zerobyte, TZ est décrit comme crucial pour une planification précise des sauvegardes, et TRUST_PROXY plus TRUSTED_ORIGINS couvrent les scénarios de reverse proxy et de CORS. Les autres variables incluent WEBHOOK_ALLOWED_ORIGINS, WEBHOOK_TIMEOUT, LOG_LEVEL, SERVER_IDLE_TIMEOUT, RCLONE_CONFIG_DIR et PROVISIONING_PATH. GOMAXPROCS peut limiter les threads du scheduler Go utilisés par les processus restic enfants afin de réduire la pression CPU pendant les sauvegardes.

Zerobyte : Flux de sauvegarde : volumes, dépôts et tâches

Le README présente l'utilisation de Zerobyte en trois étapes : ajouter un volume, créer un dépôt, et configurer une tâche de sauvegarde. Un volume représente les données sources à sauvegarder ; les backends pris en charge incluent NFS, SMB, WebDAV, SFTP et les répertoires locaux. Un dépôt est l'endroit où les sauvegardes sont stockées chiffrées ; les backends pris en charge incluent les répertoires locaux, le stockage compatible S3, Google Cloud Storage, Azure Blob Storage et les remotes rclone pour plus de 40 fournisseurs cloud. Une tâche de sauvegarde définit le calendrier, la politique de rétention et les chemins à inclure. La restauration s'effectue en sélectionnant une tâche de sauvegarde, en choisissant un instantané spécifique et en restaurant les fichiers ou répertoires sélectionnés à leur emplacement d'origine.

Zerobyte : Authentification et contrôle d'accès

Zerobyte utilise better-auth pour l'authentification et la gestion des sessions. Le README indique que le projet ne fournit actuellement pas de RBAC fin pour les opérations de sauvegarde. Les membres authentifiés d'une organisation sont considérés comme des opérateurs de confiance pour les dépôts, volumes, planifications de sauvegarde, restaurations et destinations de notification au sein de leur organisation. Les rôles d'organisation restreignent principalement les actions de gestion de l'organisation et de l'instance. La sécurité des cookies est déterminée par BASE_URL : une URL http:// avec une adresse IP désactive le flag Secure, tandis qu'un domaine https:// l'active. Pour les déploiements derrière un reverse proxy, BASE_URL doit être défini sur le domaine HTTPS et le proxy doit transmettre l'en-tête X-Forwarded-Proto. Le README note également que si BASE_URL est en HTTPS, les navigateurs n'enverront les cookies d'authentification que via HTTPS, donc un accès HTTP simple ne fonctionnera pas pour les flux authentifiés.

Zerobyte : Politique réseau et ressources provisionnées

Zerobyte applique une politique réseau aux webhooks de sauvegarde et aux notifications sortantes. WEBHOOK_ALLOWED_ORIGINS restreint les origines HTTP pouvant être ciblées, et la correspondance est exacte : le schéma, l'hôte et le port doivent correspondre, tandis que les chemins sont ignorés. La politique s'applique aux URL de webhooks avant/après sauvegarde, aux URL de notification HTTP génériques, aux URL de serveur Gotify, aux URL de serveur ntfy auto-hébergé et aux URL Shoutrrr personnalisées pointant vers des cibles HTTP ou SMTP génériques. Le service public ntfy.sh et les fournisseurs fixes comme Slack, Discord, Pushover et Telegram n'ont pas besoin de la liste blanche. Les webhooks de sauvegarde ne suivent pas les redirections. Par ailleurs, PROVISIONING_PATH permet aux opérateurs de synchroniser des dépôts et volumes à partir d'un fichier JSON au démarrage, les identifiants étant résolus depuis des variables d'environnement ou /run/secrets/*.

Zerobyte : Licence et composants tiers

Zerobyte est publié sous licence AGPL-3.0. Selon l'extrait de licence, il s'agit d'une licence copyleft spécifiquement conçue pour les logiciels de serveur réseau : elle exige que l'opérateur d'un serveur réseau fournisse aux utilisateurs de ce serveur le code source de la version modifiée qui y est exécutée. La licence accorde la permission de copier, distribuer et modifier le logiciel, et exige que le code source soit disponible. Le README liste également les composants tiers : restic est inclus sous licence BSD 2-Clause, copyright Alexander Neumann, statut « Included unchanged ». Une liste complète des licences tierces est référencée dans NOTICES.md. Le texte de licence lui-même ne dit rien sur la posture de sécurité, le support ou la garantie, et le README n'offre pas non plus de telles garanties.

Conclusion éditoriale

Zerobyte convient aux lecteurs dont le besoin correspond aux entrées documentées et qui peuvent contrôler BASE_URL, APP_SECRET, TZ, /var/lib/zerobyte. Il ne convient pas à ceux qui exigent une garantie absente du README. Commencez par docker compose up -d, observez le résultat propre à ce projet, puis décidez sur cette preuve.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes