La planification nécessaire pour vivre avec un état Docker persistant
L’auteur voulait des copies hebdomadaires d’AppData vers un pool RAID 1, ainsi qu’une deuxième copie de ce pool vers un disque USB connecté en permanence. Le crontab système et une application de planification communautaire ne conservaient pas les tâches de manière fiable après un redémarrage. Il a donc déplacé la planification dans une stack Ofelia gérée par Portainer et stockée dans les données persistantes de ZimaOS.
La conception obtenue séparait trois couches : des scripts shell sur le stockage RAID, un conteneur Ofelia fournissant la planification et des conteneurs rsync de courte durée effectuant chaque copie.
Stocker les scripts et les journaux sur un stockage persistant
L’exemple plaçait les scripts dans un chemin tel que /media/RAID1/scripts. Ce répertoire était monté en lecture-écriture dans le planificateur sous /scripts. Les journaux étaient écrits à côté des scripts afin de pouvoir être consultés via Files ou un partage réseau une fois la tâche terminée.
Tous les chemins de l’exemple dépendent de l’installation. Copier le nom du RAID de l’auteur sans vérifier le chemin de montage réel peut envoyer une sauvegarde au mauvais endroit ou provoquer un échec silencieux de la tâche.
Ofelia fournissait une planification persistante après redémarrage
La stack Portainer utilisait l’image Ofelia, définissait restart: always, montait le répertoire des scripts et stockait les étiquettes de planification avec le conteneur. L’exemple planifiait AppData à 23 h 30 chaque dimanche et les données NAS générales à 23 h 45.
ofelia.job-local.appdata.schedule: "0 30 23 * * 0"
ofelia.job-local.appdata.command: "/bin/sh /scripts/backup_appdata.sh"
ofelia.job-local.nas_home.schedule: "0 45 23 * * 0"
ofelia.job-local.nas_home.command: "/bin/sh /scripts/backup_nas_home.sh"L’auteur a indiqué que le planificateur et ses tâches revenaient dans un délai d’environ une minute après le redémarrage, sans nécessiter une nouvelle session SSH.
Le script AppData arrêtait Plex avant la copie
Pour réduire le risque de copier une base de données Plex en cours de modification, le script arrêtait Plex, exécutait rsync depuis un montage source AppData en lecture seule, puis redémarrait Plex. Le conteneur du planificateur installait une interface de ligne de commande Docker si nécessaire et contrôlait les conteneurs voisins via le socket Docker.
Monter /var/run/docker.sock donne au planificateur un large contrôle sur l’hôte Docker. L’exécuter en tant que root et en mode privilégié accroît encore cette autorité. La discussion présente cette configuration comme le modèle fonctionnel de l’auteur, et non comme un modèle de sécurité appliquant le principe du moindre privilège.
rsync --delete crée un miroir exact, pas un historique versionné
L’exemple utilisait rsync -avH --delete. L’option --delete supprime les fichiers de destination qui n’existent plus dans la source. Cela produit un miroir exact, mais peut aussi reproduire une suppression accidentelle ou une corruption.
Commencez par tester sans suppression, vérifiez les montages source et destination, puis consultez le journal avant d’activer une planification sans surveillance. Un miroir sur un disque USB toujours connecté n’est pas non plus équivalent à une sauvegarde hors ligne ou immuable.
La persistance après redémarrage n’a pas résolu la reconnexion USB
L’auteur demandait séparément qu’un disque USB connecté cesse d’apparaître comme un nouveau disque après le redémarrage. Ofelia conserve la configuration des tâches, mais un chemin de montage modifié ou indisponible peut tout de même rendre la cible de sauvegarde inaccessible. L’identification stable du stockage et la vérification des montages avant rsync restent des exigences distinctes.
FAQ
Pourquoi cette planification a-t-elle survécu au redémarrage ?
Les définitions des tâches résidaient dans une stack Portainer configurée pour redémarrer, tandis que les scripts étaient stockés sur un stockage persistant plutôt que dans un crontab système éphémère.
Cette configuration crée-t-elle des versions historiques des sauvegardes ?
Non. La commande rsync documentée crée un miroir et utilise --delete. La conservation de versions nécessite une conception différente.
Pourquoi arrêter Plex avant de copier AppData ?
L’auteur le faisait afin de réduire le risque de copier sa base de données pendant sa modification.
