Si icewhale-files-backup consomme plusieurs gigaoctets de RAM et déclenche à plusieurs reprises le tueur OOM sur ZimaOS 1.7.0, mettez d’abord à jour vers ZimaOS 1.7.1 ou une version ultérieure. Les notes de version 1.7.1 d’IceWhale indiquent explicitement la correction d’une consommation mémoire anormale dans certains scénarios d’opérations sur les fichiers, ainsi que de problèmes d’échec ou d’interruption des sauvegardes.
Le fil de discussion source décrivait une grave régression de la version 1.7.0 : la mémoire passait d’environ 3,5 Go à plus de 10 Go, le noyau tuait le processus Backup, Restart=always le relançait, et le cycle déstabilisait le serveur. Masquer le service interrompait la boucle, mais constituait uniquement une solution d’urgence.
Reconnaître la boucle OOM
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hSi le processus Backup redevient régulièrement le plus gros consommateur de mémoire, la boucle de redémarrage peut épuiser les ressources de Docker et des autres services.
Mettre à jour vers la version 1.7.1 ou une version ultérieure
Les notes de version officielles de ZimaOS 1.7.1 répertorient des corrections concernant la consommation mémoire anormale et les tâches de sauvegarde susceptibles d’échouer ou d’être interrompues.
Récupération d’urgence sous ZimaOS 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceLe masquage était nécessaire, car l’arrêt ou la désactivation normaux n’empêchaient pas toujours le relancement du service en raison de sa politique de redémarrage.
Comprendre les conséquences du masquage
Le masquage désactive la fonction Backup intégrée. Utilisez-le uniquement pour stabiliser un hôte inutilisable le temps de le mettre à jour ou de récupérer les données.
Supprimer le masquage après la mise à jour
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceExécutez ensuite une petite sauvegarde contrôlée tout en surveillant la RAM et le swap.
Les sauvegardes vers des périphériques USB constituaient un déclencheur fréquent
Plusieurs utilisateurs ont signalé un comportement similaire avec des cibles de sauvegarde USB. Cela facilite la reproduction du bogue, mais ne prouve pas que le boîtier lui-même en soit la cause.
Vérifier l’intégrité de la sauvegarde
Comparez le nombre de fichiers de la source et de la destination, puis effectuez un test de restauration. Le guide de vérification des sauvegardes aide à réduire la dépendance à une seule tâche.
Vérifier si Docker a été endommagé par le manque de mémoire
Dans le fil de discussion, une pression mémoire prolongée a finalement rendu les applications Docker indisponibles. Une fois l’hôte stabilisé, vérifiez docker ps, le démon Docker et les conteneurs critiques avant de relancer une tâche de sauvegarde importante.
Commencer par une petite sauvegarde après la mise à jour
Ne relancez pas immédiatement la tâche de plusieurs téraoctets ou la tâche USB à l’origine de la panne. Créez une petite tâche de test, surveillez la mémoire pendant 10 à 20 minutes, puis augmentez progressivement le nombre de fichiers et la taille totale. Vous pourrez ainsi déterminer plus facilement si le service corrigé reste dans des limites maîtrisées.
Le nombre de fichiers compte autant que le volume de données
Des centaines de milliers de petits fichiers peuvent générer beaucoup plus de travail de métadonnées que quelques gros fichiers multimédias. Dans un rapport destiné au support, indiquez à la fois le nombre total d’octets et le nombre approximatif de fichiers.
Conserver une solution de sauvegarde indépendante pendant les tests
Si la fonction Backup intégrée était auparavant incomplète ou instable, conservez une autre copie fiable à l’aide d’un outil ou d’une destination distincte jusqu’à ce qu’un test de restauration confirme la fiabilité de la tâche ZimaOS actuelle.
Conserver les journaux avant et après la correction
Enregistrez les messages OOM, les processus consommant le plus de mémoire, la version de ZimaOS et le type de cible de sauvegarde avant la mise à jour. Reproduisez ensuite la même charge de travail contrôlée après la version 1.7.1 ou une version ultérieure, puis comparez l’évolution de la mémoire. Vous disposerez ainsi de preuves que la régression est résolue, au lieu de vous fier uniquement à l’impression que « le serveur semble stable ».
Si la mémoire continue d’augmenter sans limite dans la version corrigée, arrêtez la tâche et transmettez au support ces mesures prises avant et après la mise à jour.
FAQ
La fuite mémoire a-t-elle été confirmée par plusieurs utilisateurs ?
Oui. Plusieurs utilisateurs ont signalé le même comportement sous la version 1.7.0.
La version 1.7.1 corrigeait-elle ce type de problème ?
Oui. Le journal des modifications officiel inclut des corrections liées à la mémoire et aux sauvegardes qui correspondent directement à ce problème.
Dois-je revenir à la version 1.6.2 ?
Il s’agissait d’une solution temporaire avant la version 1.7.1. Les utilisateurs actuels devraient privilégier la version stable corrigée.
Comment savoir si la correction fonctionne ?
Exécutez une sauvegarde contrôlée tout en surveillant la mémoire, le swap, les journaux et l’intégrité de la destination.
