Este hilo de abril de 2026 comenzó como una publicación general de un «nuevo usuario abrumado por ZimaOS» que trataba sobre las copias de seguridad y el correo electrónico autohospedado. El problema del correo acabó siendo secundario: el usuario logró que Mailcow funcionara suficientemente bien para sus necesidades. La historia técnica no resuelta era la Copia de seguridad de ZimaOS, cuyos tamaños mostrados eran incoherentes, cuya primera ejecución normalmente terminaba y cuyas ejecuciones posteriores podían bloquearse sin más actividad del disco.
La fuente es especialmente útil porque el usuario probó más de un ZimaBoard 2, varias unidades internas y externas, un destino de red Synology y, posteriormente, ZimaOS 1.6.1. Por tanto, el problema no debe resumirse como un simple fallo de un disco USB o de una ruta de red incorrecta.
El usuario quería una copia de seguridad sencilla ante desastres, no un formato de archivo
El flujo de trabajo deseado era sencillo: iniciar manualmente una copia de seguridad de estilo 1:1, conservar una estructura de carpetas reconocible, evitar el cifrado o los paquetes opacos y poder recuperarse rápidamente si un ZimaBoard 2 fallaba por completo.
Esta expectativa es diferente de la del software de copias de seguridad con versiones, que conserva deliberadamente copias históricas. Cuando la retención de versiones está activada, el uso del destino puede superar legítimamente el tamaño del conjunto de datos actual del origen.
El problema del servidor de correo terminó separándose
La publicación original también describía dificultades para reemplazar Synology Mail Plus. Zima-Jerry sugirió Stalwart, pero el usuario necesitaba específicamente recuperar mensajes mediante POP3. Para el 16 de abril, el usuario informó que Mailcow funcionaba y que las demás aplicaciones eran satisfactorias.
Vale la pena conservar ese resultado porque evita que la conversación posterior sobre Copia de seguridad se interprete erróneamente como evidencia de que Mailcow causó el problema de almacenamiento.
Los tamaños del destino de la copia de seguridad no coincidían con la realidad
En una placa, aproximadamente 800 GB en la fuente correspondían a unos 2,7 TB en el directorio de destino. En otra, aproximadamente 105 GB en la fuente parecían tener un faltante de unos 2 GB en el destino.
La retención de versiones puede explicar parte del crecimiento, pero no una segunda ejecución congelada
Zima-Jerry preguntó si la función «conservar versiones» estaba activada. Conservar versiones anteriores puede hacer legítimamente que un destino de copia de seguridad sea más grande que la fuente activa actual.
Sin embargo, posteriormente el usuario restableció la prueba con un disco USB externo recién formateado y documentó un fallo diferente: la primera copia de seguridad se completó; la segunda copió algunos datos y luego dejó de mostrar avances.
La prueba USB limpia reprodujo el fallo de la segunda ejecución
El usuario eliminó los trabajos antiguos, reinició el ZimaBoard 2, formateó una unidad externa y creó una nueva copia de seguridad manual con las versiones activadas. La primera ejecución tardó casi dos días y copió correctamente aproximadamente 1,25 TB.
Después de desconectar y volver a conectar la unidad mediante Archivos, la segunda ejecución copió algunos cambios; luego la barra de progreso se congeló y el indicador LED de actividad USB se apagó. El mismo comportamiento se había producido con el destino de Synology.
IceWhale escaló el problema del comportamiento de la copia de seguridad
Zima-Jerry agradeció al usuario las pruebas controladas y dijo que el problema se enviaría al equipo de desarrollo para investigarlo.
Una respuesta posterior relacionada con IceWhale separó dos áreas problemáticas conocidas: hacer una copia de seguridad de todo /media/ZimaOS-HD anteriormente había incluido contenido de tuberías y sockets de Docker, y aún era necesario mejorar la precisión de la visualización del progreso de la copia de seguridad.
Hacer una copia de seguridad de toda la unidad del sistema no equivale a una imagen del sistema restaurable
La conversación pasó después a la recuperación ante desastres. Una respuesta del equipo explicó que hacer una copia de seguridad ciega de todo el disco del sistema incluye archivos desechables de Docker y del entorno de ejecución, y no proporciona automáticamente un flujo de trabajo compatible para «restaurar esta carpeta y devolver todo el sistema ZimaOS exactamente a su estado anterior».
Para la planificación ante desastres, distingue entre datos de usuario, datos de aplicaciones, bases de datos, configuración e imágenes de contenedores reemplazables.
ZimaOS 1.6.0 cambió los metadatos de recuperación del almacenamiento
Una respuesta oficial posterior indicó que, a partir de ZimaOS 1.6.0, también se escribía en el propio almacenamiento la información que describía cómo debía montarse un dispositivo de almacenamiento. El objetivo era facilitar el reconocimiento del almacenamiento RAID o de un solo disco después de un problema con el disco del sistema.
Esto mejora la recuperación de la matriz, pero no convierte RAID en una copia de seguridad ni soluciona por sí solo el bloqueo de Copia de seguridad en la segunda ejecución del usuario de origen.
El usuario siguió reproduciendo el problema en ZimaOS 1.6.1
El 27 de abril, el autor original informó que la primera copia de seguridad seguía funcionando, pero que la segunda ejecución y las posteriores se bloqueaban durante más de seis horas sin ninguna actividad adicional de escritura. Al cerrar y volver a abrir Copia de seguridad, el destino podía aparecer como 0 B.
Indicaron que el patrón se había probado con cuatro unidades internas, dos unidades USB externas y tres sistemas ZimaBoard 2.
El flujo de trabajo actual de copias de seguridad ha evolucionado
La documentación actual de ZimaOS describe ahora tareas de copia de seguridad programadas en destinos locales, USB, NAS y en la nube como parte de una estrategia 3-2-1.
Use el flujo de trabajo actual de copias de seguridad de ZimaOS y las opciones de destino en lugar de suponer que la interfaz de las versiones 1.5.x/1.6.1 funciona hoy de forma idéntica.
La guía actual, por sí sola, no demuestra que se hayan corregido todos los errores históricos de la segunda ejecución mencionados en este hilo, así que verifique el comportamiento real de restauración en la versión que utilice.
Verifique la copia de seguridad fuera de la barra de progreso
- compare, cuando sea práctico, el número de archivos de origen y destino;
- inspeccione la capacidad real del destino en lugar de consultar únicamente la interfaz de Copia de seguridad;
- pruebe una segunda y una tercera ejecución incremental o con versiones;
- restaure archivos representativos en otra ubicación;
- documente qué bases de datos y ajustes de las aplicaciones deben respaldarse por separado.
Preguntas frecuentes sobre las copias de seguridad de ZimaOS
¿El problema de origen ocurría únicamente con un NAS Synology?
No. El usuario reprodujo congelamientos similares con una unidad USB externa.
¿Falló la primera copia de seguridad?
La primera ejecución controlada se completó; el problema recurrente apareció en ejecuciones posteriores.
¿Había desaparecido el problema en ZimaOS 1.6.1?
No. El autor original indicó explícitamente que el problema seguía reproduciéndose allí.
¿Puede un destino de copia de seguridad ser legítimamente más grande que la fuente actual?
Sí, cuando la retención de versiones está habilitada, pero eso no explica todos los síntomas de visualización ni de trabajos congelados del hilo.
