Error en la migración de ZimaOS: NTFS, EXT4 y comprobaciones previas

Conclusión: NTFS fue la causa raíz en este caso resuelto, pero no es una explicación universal para todos los fallos de migración

En la prueba reproducible, ZimaOS copió los datos parcialmente y luego falló porque el destino NTFS no pudo completar la etapa final de copia de permisos. Reformatear el destino como EXT4 permitió que esa migración específica se completara correctamente. Respuestas posteriores informaron de fallos con otras configuraciones, por lo que «formatearlo todo como EXT4» debe considerarse una solución específica para ese caso y una comprobación previa útil, no una cura universal.

Pantalla de error de migración de ZimaOS que indica que algo salió mal al mover la base de datos de usuarios a sda1 — La pantalla de error original muestra que la migración de la base de datos de usuarios se interrumpió al mover los datos de ZimaOS-HD a sda1.

La migración actual debe comenzar con la herramienta de migración de datos compatible

Cuadro de diálogo de ZimaOS para seleccionar la ubicación de almacenamiento de la base de datos de usuarios, con sda1 seleccionado como destino de migración — El flujo de migración seleccionó sda1 como la nueva ubicación de almacenamiento de la base de datos de usuarios.

Cuadro de diálogo de preparación de la migración de ZimaOS que advierte que los servicios de Docker se pausarán durante el traslado — El paso de confirmación advierte que los servicios de Docker se pausan mientras el modo de migración está activo.

Pantalla de progreso de la migración de la base de datos de usuarios de ZimaOS al 70 por ciento — La transferencia alcanzó el 70 % antes de que la migración probada fallara posteriormente.

La guía actual de migración de datos de ZimaOS mueve las imágenes de Docker, los datos de las aplicaciones de Docker y las carpetas de usuario por categorías. La guía de rutas de migración de ZimaOS es el mejor complemento actual para determinar qué se mueve realmente.

Comprueba el sistema de archivos de destino antes de pulsar Iniciar

lsblk -f
blkid

Confirma el dispositivo de destino, el tipo de sistema de archivos, el espacio disponible y el estado de montaje. Si el destino utiliza un sistema de archivos con una semántica de propiedad y permisos de Linux diferente, espera que la migración de datos de las aplicaciones sea más sensible que una simple copia de arrastrar y soltar. El manual de lsblk y la documentación de ext4 son referencias útiles para la validación.

Por qué aparece «Detener Docker» durante la migración

Ese mensaje es un comportamiento esperado, no el fallo en sí. Los datos de las aplicaciones no se pueden mover de forma segura mientras los contenedores sigan escribiendo en ellos. El flujo de migración pausa Docker, copia los datos administrados, actualiza la ubicación y luego reanuda el servicio.

Pantalla de error de migración de ZimaOS después de mover 1,08 GB a sda1 — La prueba de mayor tamaño también terminó con el mensaje «Algo salió mal» después de que la fase de copia pareciera completarse.

Configuración de aplicaciones de ZimaOS que muestra las ubicaciones de migración de los datos de las aplicaciones, las imágenes de las aplicaciones y la base de datos de usuarios — Esta pantalla muestra las categorías de migración independientes para los datos de las aplicaciones, las imágenes de Docker y la base de datos de usuarios.

Cuando la migración sigue fallando en EXT4

No vuelvas a formatear de inmediato. Registra el sistema de archivos de origen y destino, el espacio libre, la categoría de migración, la versión de ZimaOS y si el destino es un disco individual o un RAID. Luego reproduce el problema con una categoría pequeña, si es posible. Un fallo posterior en un almacenamiento creado por Zima demuestra que el tipo de sistema de archivos es solo una de las ramas del árbol de decisión.

Antes de cualquier nuevo intento destructivo, protege tus datos importantes mediante el flujo de trabajo de copias de seguridad de ZimaOS.