Si icewhale-files-backup consume varios gigabytes de RAM y activa repetidamente el asesino OOM en ZimaOS 1.7.0, actualiza primero a ZimaOS 1.7.1 o una versión posterior. Las notas de la versión 1.7.1 de IceWhale corrigen explícitamente el uso anómalo de memoria en ciertos escenarios de operaciones con archivos, así como los fallos e interrupciones de las copias de seguridad.
El hilo original documentó una regresión grave de la versión 1.7.0: la memoria aumentaba de aproximadamente 3,5 GB a más de 10 GB, el kernel terminaba el proceso de Backup, Restart=always lo iniciaba de nuevo y el ciclo desestabilizaba el servidor. Enmascarar el servicio detenía el ciclo, pero solo era una solución de emergencia.
Reconocer el ciclo OOM
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hSi el proceso de Backup vuelve a aparecer repetidamente como el principal consumidor de memoria, el ciclo de reinicio puede dejar sin recursos a Docker y a otros servicios.
Actualiza a 1.7.1 o una versión posterior
Las notas oficiales de la versión 1.7.1 de ZimaOS enumeran correcciones para el uso anómalo de memoria y para tareas de copia de seguridad que podían fallar o interrumpirse.
Recuperación de emergencia en 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceEra necesario enmascarar el servicio porque detenerlo o deshabilitarlo normalmente no siempre impedía que se iniciara de nuevo debido a la política de reinicio del servicio.
Comprende qué se interrumpe al enmascararlo
Enmascarar el servicio deshabilita la función integrada de Backup. Úsalo solo para estabilizar un equipo inutilizable durante el tiempo suficiente para actualizarlo o recuperar los datos.
Desenmascara el servicio después de actualizar
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceDespués, ejecuta una copia de seguridad pequeña y controlada mientras supervisas la RAM y la memoria de intercambio.
Las cargas de trabajo de copias de seguridad USB eran un desencadenante habitual
Varios usuarios informaron de un comportamiento similar con destinos de copia de seguridad USB. Esto ayuda a reproducir el error, pero no demuestra que la carcasa fuera la causa.
Verifica que la copia de seguridad esté completa
Compara el número de archivos del origen y del destino, y realiza una prueba de restauración. La guía de verificación de copias de seguridad ayuda a reducir la dependencia de una sola tarea.
Comprueba si Docker resultó dañado por la falta de memoria
En el hilo, la presión prolongada sobre la memoria acabó haciendo que las aplicaciones de Docker dejaran de estar disponibles. Cuando el equipo esté estable, verifica docker ps, el demonio de Docker y los contenedores críticos antes de reiniciar una carga de trabajo de copia de seguridad grande.
Comienza con una copia de seguridad pequeña después de actualizar
No vuelvas a ejecutar inmediatamente la tarea de varios terabytes o la tarea USB que provocó el fallo. Crea una tarea de prueba pequeña, supervisa la memoria durante 10–20 minutos y aumenta gradualmente el número de archivos y el tamaño total. Esto facilita comprobar si el servicio corregido mantiene acotado su consumo.
El número de archivos importa tanto como los bytes
Cientos de miles de archivos pequeños pueden generar mucho más trabajo de metadatos que unos pocos archivos multimedia grandes. Al enviar un informe de asistencia, incluye tanto el total de bytes como el número aproximado de archivos.
Mantén una ruta de copia de seguridad independiente durante las pruebas
Si la función integrada de Backup estaba incompleta o era inestable, conserva otra copia fiable mediante una herramienta o un destino independiente hasta que una prueba de restauración confirme que la tarea actual de ZimaOS es confiable.
Conserva los registros anteriores y posteriores a la corrección
Guarda los mensajes OOM, los procesos que más memoria consumen, la versión de ZimaOS y el tipo de destino de la copia de seguridad antes de actualizar. Después, repite la misma carga de trabajo controlada tras actualizar a 1.7.1 o una versión posterior y compara el crecimiento de la memoria. Así tendrás pruebas de que la regresión se resolvió, en lugar de basarte únicamente en que «el servidor parece estable».
Si la memoria sigue creciendo sin límite en la versión corregida, detén la tarea y envía esas mediciones anteriores y posteriores al equipo de asistencia.
Preguntas frecuentes
¿La fuga de memoria fue confirmada por varios usuarios?
Sí. Varios usuarios informaron del mismo comportamiento en la versión 1.7.0.
¿La versión 1.7.1 solucionó este tipo de problema?
Sí. El registro de cambios oficial incluye correcciones de memoria y de copias de seguridad que coinciden directamente con este problema.
¿Debería volver a la versión 1.6.2?
Era una solución temporal anterior a la versión 1.7.1. Los usuarios actuales deberían preferir la versión estable corregida.
¿Cómo sé si la corrección funcionó?
Ejecuta una copia de seguridad controlada mientras supervisas la memoria, la memoria de intercambio, los registros y la integridad del destino.
