La mejor estrategia de migración: trata CasaOS como tres capas: el sistema operativo del host, las definiciones de las aplicaciones y los datos persistentes. Reinstalar CasaOS es la parte fácil. Lo importante es conservar las carpetas y la configuración que realmente utilizan tus contenedores y, después, recrear las mismas rutas en la máquina nueva.
Haz un inventario antes de copiar
- las versiones de CasaOS y de la base de Linux;
- las imágenes de los contenedores, los puertos y las variables de entorno;
- todas las rutas de origen de los montajes vinculados;
-
/DATA/AppDatay las carpetas personalizadas de las aplicaciones; - los puntos de montaje de los discos multimedia/de datos;
- la propiedad UID/GID;
- la IP estática, el DNS, el proxy, la VPN y las reglas del firewall.
Las aplicaciones de la tienda de CasaOS suelen conservar los datos en /DATA/AppData/$AppID. El patrón de AppData de CasaOS demuestra por qué copiar únicamente un contenedor de Docker no constituye una migración.
Detén las aplicaciones con muchas escrituras antes de la copia final
Las bases de datos y el estado de las aplicaciones pueden cambiar mientras realizas la copia. Detén los contenedores relevantes —o Docker para la sincronización final— antes de realizar la última copia de seguridad.
sudo systemctl stop casaos-app-management
sudo systemctl stop dockerDespués, copia los datos con una herramienta que conserve los metadatos, como rsync -aHAX cuando tus sistemas de archivos lo admitan.
Haz también un inventario de los volúmenes con nombre
Algunas aplicaciones utilizan volúmenes de Docker en lugar de montajes vinculados del host. Los volúmenes persistentes de Docker sobreviven a los contenedores, pero aun así deben migrarse deliberadamente.
Recrea primero las rutas de almacenamiento
En el nuevo host, monta los discos antes de iniciar las aplicaciones. Si Jellyfin utilizaba /DATA/Media/Movies, restaurar esa misma ruta evita que se dañen las bibliotecas. Si las rutas cambian, edita las asignaciones de los contenedores antes del primer inicio.
Conserva la propiedad numérica
A los contenedores les importan los UID/GID numéricos. Compara los directorios importantes de los sistemas antiguo y nuevo:
stat -c '%u:%g %a %n' /DATA/AppData/*Restablece los servicios por etapas
- Instala una base de Linux compatible.
- Instala CasaOS.
- Monta todos los discos de datos.
- Restaura los datos persistentes.
- Recrea o importa las definiciones de las aplicaciones.
- Inicia las aplicaciones con estado una por una.
- Valida las bases de datos, los archivos multimedia, los permisos y las programaciones.
- Cambia la IP/DNS solo después de que las pruebas sean satisfactorias.
La estructura Docker de CasaOS explica por qué los datos de las aplicaciones y los contenedores son cuestiones independientes. La plataforma de aplicaciones autoalojadas es relevante si vas a migrar a ZimaOS en lugar de reconstruir CasaOS.
Para un reemplazo x86 compacto, ZimaBoard 2 puede adaptarse a implementaciones más pequeñas.
Clasifica cada aplicación según su tipo de estado
No todos los contenedores se migran de la misma manera:
- Sin estado: la configuración se puede recrear a partir de Compose y del entorno.
- Basadas en archivos: copia las carpetas montadas mediante bind.
- SQLite: detén la aplicación antes de copiar el archivo de la base de datos.
- PostgreSQL/MySQL: cuando sea posible, utiliza una copia de seguridad de la aplicación o de la base de datos en lugar de depender únicamente de una copia del sistema de archivos activo.
- Aplicaciones con volúmenes con nombre: exporta o copia el volumen de Docker de forma intencionada.
Captura la configuración actual de Docker
Para cada contenedor importante, guarda lo siguiente:
docker inspect <container> > container-inspect.jsonNo es un archivo de Compose listo para importar, pero registra los montajes, puertos, variables de entorno, redes y dispositivos para que puedas verificar que el servicio reconstruido coincide con el anterior.
Planifica el cambio de IP y nombre de host
Si los clientes utilizan el nombre de host del servidor, la migración será más sencilla: dirige el DNS a la nueva IP después de la validación. Si todas las aplicaciones están configuradas de forma fija con la IP antigua, quizá prefieras asignar la dirección estática antigua al nuevo host cuando el anterior esté desconectado.
Mantén el servidor antiguo intacto hasta que ya no sea necesaria la reversión
No borres la fuente inmediatamente después del primer inicio de sesión exitoso. Mantenla apagada, pero intacta, durante al menos un ciclo de copia de seguridad y un periodo de uso normal. Así tendrás una reversión conocida y funcional si se omitió una tarea programada, una base de datos o un cliente remoto.
Valida los datos, no solo los contenedores
Un estado verde de Docker solo demuestra que el proceso está en ejecución. Valida lo siguiente:
- biblioteca y estado de reproducción de Jellyfin;
- estado de las carpetas de Syncthing;
- tareas de copia de seguridad y pruebas de restauración;
- aplicaciones de bases de datos;
- rutas de las unidades externas;
- certificados del proxy inverso;
- acceso remoto mediante VPN/túnel.
Preguntas frecuentes
¿Puedo clonar el disco de arranque?
A veces, pero un clon conserva supuestos de red, arranque y montaje específicos del hardware. Un host limpio con los datos restaurados suele ser más fácil de validar.
¿Cuándo puedo retirar el servidor antiguo?
Solo después de que los inicios de sesión de las aplicaciones, las bases de datos, las rutas de medios, los permisos, las tareas programadas, las copias de seguridad y el acceso remoto funcionen correctamente en el nuevo host.
