Cette discussion d’avril 2026 a commencé par un message général d’un « nouvel utilisateur dépassé par ZimaOS », portant sur la sauvegarde et la messagerie auto-hébergée. Le problème de messagerie est finalement devenu secondaire : l’utilisateur a réussi à faire fonctionner Mailcow suffisamment bien pour ses besoins. Le problème technique non résolu concernait ZimaOS Backup, dont les tailles affichées étaient incohérentes ; la première exécution se terminait généralement correctement, tandis que les suivantes pouvaient se figer sans activité supplémentaire du disque.
La source est particulièrement utile, car l’utilisateur a testé plusieurs ZimaBoard 2, plusieurs disques internes et externes, une destination réseau Synology, puis ZimaOS 1.6.1. Le problème ne doit donc pas être résumé à un simple disque USB défectueux ou à un chemin réseau incorrect.
L’utilisateur voulait une simple sauvegarde après sinistre, pas un format d’archivage
Le flux souhaité était simple : lancer manuellement une sauvegarde de type 1:1, conserver une structure de dossiers reconnaissable, éviter le chiffrement ou les paquets opaques, et pouvoir récupérer rapidement les données en cas de panne complète d’une ZimaBoard 2.
Cette attente diffère de celle d’un logiciel de sauvegarde avec gestion des versions, qui conserve intentionnellement des copies historiques. Lorsque la rétention des versions est activée, l’espace utilisé sur la destination peut légitimement dépasser la taille du jeu de données source actuel.
Le problème du serveur de messagerie a finalement été dissocié
Le message d’origine décrivait également les difficultés rencontrées pour remplacer Synology Mail Plus. Zima-Jerry a suggéré Stalwart, mais l’utilisateur avait spécifiquement besoin de la récupération via POP3. Le 16 avril, l’utilisateur a indiqué que Mailcow fonctionnait et que les autres applications lui convenaient.
Ce résultat mérite d’être conservé, car il empêche que la discussion ultérieure sur Backup soit interprétée à tort comme la preuve que Mailcow était à l’origine du problème de stockage.
Les tailles de destination des sauvegardes ne correspondaient pas à la réalité
Sur une carte, environ 800 Go à la source correspondaient à environ 2,7 To dans le répertoire de destination. Sur une autre, environ 105 Go à la source semblaient manquer d’environ 2 Go dans la destination.
La conservation des versions peut expliquer une partie de l’augmentation, mais pas le blocage de la deuxième exécution
Zima-Jerry a demandé si la fonction de « conservation des versions » était activée. La conservation des versions précédentes peut légitimement rendre une destination de sauvegarde plus volumineuse que la source active actuelle.
Cependant, l’utilisateur a ensuite réinitialisé le test avec un disque USB externe fraîchement formaté et documenté un autre échec : la première sauvegarde s’est terminée, tandis que la deuxième a copié certaines données avant de cesser d’avancer.
Le test USB vierge a reproduit l’échec de la deuxième exécution
L’utilisateur a supprimé les anciennes tâches, redémarré le ZimaBoard 2, formaté un disque externe et créé une nouvelle sauvegarde manuelle avec les versions activées. La première exécution a pris presque deux jours et a copié environ 1,25 To avec succès.
Après avoir déconnecté puis reconnecté le disque via Fichiers, la deuxième exécution a copié certaines modifications, puis la barre de progression s’est figée et le voyant d’activité USB s’est éteint. Le même comportement s’était produit avec la destination Synology.
IceWhale a fait remonter le problème du comportement de la sauvegarde
Zima-Jerry a remercié l’utilisateur pour ces tests contrôlés et a indiqué que le problème serait transmis à l’équipe de développement pour investigation.
Une réponse ultérieure liée à IceWhale a distingué deux problèmes connus : la sauvegarde de l’ensemble de /media/ZimaOS-HD contenait auparavant du contenu de tubes ou sockets Docker, et la précision de l’affichage de la progression de la sauvegarde devait encore être améliorée.
Sauvegarder l’intégralité du disque système ne revient pas à créer une image système restaurable
La discussion a ensuite porté sur la reprise après sinistre. Une réponse de l’équipe a expliqué que sauvegarder aveuglément l’intégralité du disque système inclut des fichiers Docker et d’exécution jetables, et ne fournit pas automatiquement une procédure prise en charge permettant de « restaurer ce dossier et de retrouver l’intégralité du système ZimaOS exactement comme avant ».
Pour planifier la reprise après sinistre, distinguez les données utilisateur, les données des applications, les bases de données, la configuration et les images de conteneurs remplaçables.
ZimaOS 1.6.0 a modifié les métadonnées de récupération du stockage
Une réponse officielle ultérieure indiquait qu’à partir de ZimaOS 1.6.0, les informations décrivant la manière dont un périphérique de stockage doit être monté étaient également écrites sur le support de stockage lui-même. L’objectif était de faciliter la reconnaissance des systèmes RAID ou à disque unique après un problème sur le disque système.
Cela améliore la récupération d’un ensemble RAID, mais ne transforme pas le RAID en sauvegarde et ne corrige pas à lui seul le blocage de la sauvegarde lors de la deuxième exécution chez l’utilisateur source.
L’utilisateur a encore reproduit le problème sur ZimaOS 1.6.1
Le 27 avril, l’auteur du message original a signalé que la première sauvegarde fonctionnait toujours, mais que la deuxième exécution et les suivantes restaient bloquées pendant plus de six heures, sans nouvelle activité d’écriture. Fermer puis rouvrir l’application Sauvegarde pouvait afficher la destination comme faisant 0 o.
Ils ont indiqué que le comportement avait été testé avec quatre disques internes, deux disques USB externes et trois systèmes ZimaBoard 2.
Le flux de sauvegarde actuel a évolué
La documentation actuelle de ZimaOS décrit désormais les tâches de sauvegarde planifiées vers des destinations locales, USB, NAS et cloud dans le cadre d’une stratégie 3-2-1.
Utilisez le flux de sauvegarde ZimaOS actuel et les options de destination plutôt que de supposer que l’interface des versions 1.5.x/1.6.1 fonctionne encore exactement de la même manière aujourd’hui.
Le guide actuel ne prouve pas à lui seul que tous les anciens problèmes de seconde exécution mentionnés dans ce fil ont été corrigés ; vérifiez donc le comportement réel de la restauration avec la version que vous utilisez.
Vérifier la sauvegarde en dehors de la barre de progression
- comparer, lorsque c’est possible, le nombre de fichiers de la source et de la destination ;
- inspecter la capacité réelle de la destination plutôt que de se fier uniquement à l’interface de sauvegarde ;
- tester une deuxième et une troisième exécution incrémentielle avec gestion des versions ;
- restaurer des fichiers représentatifs vers un autre emplacement ;
- documentez quelles bases de données d’applications et quels paramètres doivent être sauvegardés séparément.
FAQ sur les sauvegardes ZimaOS
Le problème lié à la source se produisait-il uniquement avec un NAS Synology ?
Non. L’utilisateur a reproduit des blocages similaires avec un disque USB externe.
La première sauvegarde a-t-elle échoué ?
La première exécution contrôlée s’est terminée ; le problème récurrent est apparu lors des exécutions suivantes.
Le problème avait-il disparu dans ZimaOS 1.6.1 ?
Non. L’auteur du message original a explicitement indiqué que le problème se reproduisait toujours à cet endroit.
Une destination de sauvegarde peut-elle légitimement être plus grande que la source actuelle ?
Oui lorsque la conservation des versions est activée, mais cela n’explique pas tous les symptômes d’affichage ou de tâches bloquées mentionnés dans le fil.
