L’installation d’UrBackup de la source a échoué pour plusieurs raisons indépendantes avant de fonctionner : le téléchargement de l’image a été réécrit via un miroir réservé à la Chine continentale, les premiers chemins de montage ne correspondaient pas à des dossiers présents sur l’hôte ZimaOS, les droits du répertoire de sauvegarde étaient incorrects et l’URL et les ports du lanceur de l’application prêtaient à confusion.
La leçon durable est de traiter UrBackup comme une application Docker avec état classique : utiliser de vrais chemins de stockage hôte, conserver les données de sauvegarde ainsi que la base de données et l’état d’UrBackup, vérifier les droits de l’utilisateur d’exécution, puis confirmer les ports de l’interface WebUI et du réseau avant de lui confier les sauvegardes des clients.
Le premier téléchargement de l’image a été réécrit vers un miroir inutilisable
Le démon a renvoyé un message indiquant que l’image ne pouvait pas être téléchargée pour docker.1panel.live/uroni/urbackup-server. La page officielle de téléchargement d’UrBackup indique toujours uroni/urbackup-server comme image Docker officielle.
Consultez l’image Docker officielle actuelle d’UrBackup.
Les montages de liaison doivent pointer vers de vrais dossiers hôtes de ZimaOS
Le récapitulatif fonctionnel utilisait un stockage réel dans des chemins tels que /media/Safe-Storage/UrBackup/backups et /media/Safe-Storage/UrBackup/data, associés à /backups et /var/urbackup. Inspectez le chemin réel sur votre hôte au lieu de recopier littéralement le nom du stockage de la source.
Accès refusé : l’utilisateur du conteneur ne peut pas écrire
La source a rencontré l’erreur Aucune autorisation d’accès à « /backups/urbackup_tmp_files ». Sa correction utilisait un UID/GID précis ainsi que les droits correspondants sur l’hôte. Ne figez pas 1000:100 comme identité universelle ; vérifiez l’utilisateur d’exécution actuel.
Conserver les deux sauvegardes ainsi que l’état d’UrBackup
Le dépôt contient les données de sauvegarde des clients, tandis que /var/urbackup contient la base de données et l’état du serveur. Un plan de récupération utilisable doit préserver les deux, selon les besoins.
La source utilisait le réseau de l’hôte
La version maintenue uroni/urbackup-server image documente actuellement le réseau de l’hôte comme l’un des modes Docker pris en charge et expose les ports de service UrBackup habituels. Le réseau de l’hôte simplifie la découverte, mais supprime l’isolation réseau de Docker.
L’interface WebUI doit utiliser le bon port
La source a corrigé le lanceur ZimaOS pour utiliser le port 55414. Le lanceur n’est qu’une URL pratique ; il faut vérifier l’état réel du service dans les journaux et sur les ports en écoute.
Privilégier une définition Compose reproductible
L’App Store 2.0 actuel de ZimaOS et les flux de travail pour applications personnalisées prennent en charge Docker Compose standard. Regroupez l’image, les chemins persistants, le fuseau horaire, la stratégie de redémarrage et le réseau dans une seule définition Compose.
Utilisez le modèle Compose actuel de ZimaOS.
Un tableau de bord fonctionnel ne constitue pas le test final
Enregistrez un client, effectuez une petite sauvegarde, redémarrez le conteneur ou l’hôte, puis restaurez un fichier. Cela vérifie simultanément le réseau, les autorisations, la persistance de la base de données et le stockage des sauvegardes.
Placez le référentiel de sauvegarde sur le stockage de données, pas sur le disque système
UrBackup peut consommer des centaines de gigaoctets, voire davantage. Le chemin du référentiel doit pointer vers un véritable espace de stockage ZimaOS dont la capacité et l’état sont connus, et non vers le petit disque du système d’exploitation.
Avant d’intégrer des clients, confirmez le chemin hôte dans ZimaOS et surveillez l’espace libre pendant la première sauvegarde complète.
La base de données UrBackup fait partie du système de restauration
Les fichiers sous /backups ne constituent qu’une moitié d’un serveur utilisable. L’état et la base de données d’UrBackup, situés sous /var/urbackup assure le suivi des clients, des métadonnées de sauvegarde, de la rétention et de la configuration du serveur.
Documentez et protégez les deux mappages persistants afin qu’une recréation du conteneur ne laisse pas un amas de fichiers de sauvegarde sans l’état attendu du serveur.
Utilisez un accès en écriture avec le principe du moindre privilège
L’ajustement de l’UID/GID propre à la source a corrigé un déploiement, mais les modifications récursives de propriété sur l’ensemble d’un pool de stockage sont risquées. Créez un répertoire UrBackup dédié et accordez à l’identité du conteneur l’accès à ce répertoire, plutôt qu’un accès en écriture étendu à des données NAS sans rapport.
Le réseau de l’hôte expose directement les services UrBackup sur ZimaOS
Lorsque le réseau de l’hôte est utilisé, les écouteurs UrBackup sont des écouteurs de l’hôte. Si ZFW ou un autre pare-feu protège le NAS, n’autorisez que les ports et les réseaux clients nécessaires à la sauvegarde et à la découverte. Ne publiez pas directement les ports de service UrBackup sur Internet public.
Testez une restauration avant de considérer le serveur de sauvegarde comme opérationnel
Effectuez une sauvegarde complète d’un client, redémarrez ZimaOS ou recréez le conteneur, vérifiez que l’historique du client est conservé, puis restaurez plusieurs fichiers vers un emplacement distinct. Cela valide la disponibilité de l’image, les autorisations, l’état persistant, le réseau et la récupérabilité réelle, et pas seulement l’affichage vert du tableau de bord.
FAQ sur UrBackup sur ZimaOS
L’utilisateur de la source a-t-il finalement réussi à faire fonctionner UrBackup ?
Oui.
Tous les systèmes ZimaOS doivent-ils utiliser PUID 1000 et PGID 100 ?
Non. Il s’agissait de valeurs spécifiques à la source.
L’utilisation du réseau de l’hôte est-elle obligatoire ?
Pas universellement. Il s’agit d’une option d’image documentée que la source a utilisée avec succès, mais elle réduit l’isolation réseau.
