La programmation « Always » d’origine de ZimaOS 1.5.3 indiquait bien que les sources de sauvegarde LAN/cloud devaient être vérifiées chaque jour à 1 h du matin, mais plusieurs utilisateurs ont signalé que les tâches ne démarraient pas automatiquement. Les exécutions manuelles fonctionnaient, ce qui orientait le problème vers la planification ou le comportement du service plutôt que vers un problème d’accès élémentaire à la source ou à la destination.
Le redémarrage de icewhale-files-backup.service permettait à certains utilisateurs de lancer les tâches, mais l’auteur d’origine a explicitement indiqué que cette méthode n’était pas fiable. Elle doit rester une solution de diagnostic, et non devenir le planificateur normal recommandé.
Ce que promettait l’interface de la version 1.5.3
Pour les sources Zima/USB, « Always » signifiait réagir aux modifications de fichiers. Pour les sources cloud ou LAN, l’infobulle décrivait une vérification quotidienne à 1 h, selon l’heure de l’appareil.
Une exécution manuelle réussie ne prouve pas que le planificateur fonctionne
Si « Exécuter maintenant » fonctionne, les identifiants de la source, l’accès au chemin et l’écriture vers la destination sont probablement opérationnels. Les vérifications suivantes concernent le fuseau horaire de l’appareil, l’état de la programmation de la tâche et le service de sauvegarde autour de l’heure de déclenchement prévue.
La solution de redémarrage du service a été vérifiée par la communauté, mais elle n’est pas idéale
Un utilisateur a constaté que le redémarrage de icewhale-files-backup.service lançait les tâches, puis a programmé ce redémarrage avec cron. Un autre utilisateur a utilisé Zima Cron pour la même approche. L’auteur du message d’origine a précisé qu’un crontab normal pouvait être supprimé lors des mises à jour de ZimaOS.
Le guide actuel des sauvegardes ZimaOS décrit désormais des tâches programmées indépendamment, plutôt que de s’appuyer sur cette ancienne méthode de redémarrage du service.
Les versions ultérieures ont présenté un autre problème de sauvegarde
Après la mise à niveau vers la version 1.6.1, un utilisateur a signalé des tâches qui semblaient s’exécuter sans transférer de fichiers. Ce symptôme diffère de celui où « le déclenchement de 1 h ne s’est jamais produit » ; ces deux problèmes doivent donc être diagnostiqués séparément.
Utilisez l’application de sauvegarde actuelle avant de conserver une ancienne solution de contournement
Recréez la tâche sur la version stable actuelle de ZimaOS, définissez une programmation explicite, vérifiez le fuseau horaire de l’appareil et restaurez un fichier de test après la première exécution réussie. La présentation des sauvegardes ZimaOS décrit le modèle produit actuel.
En résumé
Le fil de discussion consacré à la version 1.5.3 documente un véritable problème de planification avec les sources de sauvegarde LAN/NAS, mais le redémarrage nocturne du service n’était qu’une solution de contournement. Avec la version actuelle de ZimaOS, recréez la tâche avec le planificateur moderne, vérifiez le fuseau horaire et les journaux, et distinguez le cas où « la tâche n’a pas démarré » de celui où « la tâche a démarré mais n’a rien transféré ».
