¿Jellyfin puede ejecutarse en ARM y x86 con los mismos datos?

Por lo general, sí, pero considera la migración de ARM a x86 como una migración controlada del host, no como una prueba de que todos los componentes de Jellyfin son independientes de la arquitectura. En las versiones actuales de Jellyfin, el destino ARM pertinente es ARM64; del mismo modo, el destino x86 debe ser una plataforma de 64 bits compatible. Mantén intacto el origen hasta que el destino haya superado las comprobaciones de reinicio y reproducción.

El límite importante es operativo: detén el origen antes de copiar el estado persistente y nunca permitas que dos instancias de Jellyfin en hosts diferentes escriban en el mismo directorio de datos activo. Jellyfin no documenta ARM64 a x86-64 como una ruta de migración especial y sin riesgos, así que conserva una copia para revertir los cambios y reconstruye por separado los elementos específicos de la plataforma, como los paquetes de FFmpeg, las asignaciones de dispositivos para la aceleración por hardware, las dependencias nativas de los complementos, los permisos y las rutas del host.

Verifica que la arquitectura del destino sea realmente compatible

Empieza confirmando que el destino sea una plataforma de Jellyfin de 64 bits actualmente compatible. No des por hecho que una placa ARM antigua, un sistema operativo de 32 bits o una máquina x86 obsoleta sean aceptables simplemente porque Linux todavía arranque en ella.

Jellyfin 10.11 eliminó oficialmente la compatibilidad con ARM32, incluido armhf, y ahora requiere un sistema operativo ARM64 en las plataformas ARM. Si el origen todavía ejecuta una compilación ARM de 32 bits, planifica primero un destino compatible de 64 bits en lugar de tratar el entorno antiguo como un objetivo de migración actual.

En x86, utiliza un host x86-64 compatible que cumpla los requisitos de la versión de Jellyfin que pretendas ejecutar. Si el destino depende de un paquete no oficial, un sistema operativo no compatible o una CPU obsoleta, resuelve ese problema de plataforma antes de mover el estado persistente.

Considera el estado almacenado como portátil, pero la implementación como específica de la plataforma

Una implementación estándar de Jellyfin mantiene el estado persistente del servidor en su base de datos, junto con archivos de configuración y metadatos. En las instalaciones que utilizan SQLite, el formato de la base de datos en disco está diseñado para ser portátil entre arquitecturas de procesador, por lo que la familia de CPU, por sí sola, no es motivo para convertir la base de datos a nivel de bytes antes de una migración.

SQLite documenta su formato de archivo como un formato de base de datos multiplataforma, incluida la portabilidad entre sistemas de 32 y 64 bits y con distintas convenciones de orden de bytes. Esto respalda la parte de la migración relacionada con el formato de la base de datos, pero no garantiza que todos los complementos de Jellyfin, ejecutables externos, controladores o rutas específicas de la implementación sobrevivan sin cambios.

Mantén clara la distinción: los registros almacenados portátiles son solo una capa. La compatibilidad de versiones de Jellyfin, la cobertura completa de datos y configuración, la coherencia de las rutas multimedia, las dependencias de los complementos, los permisos y el acceso a los dispositivos de hardware siguen determinando si el destino se comporta como el origen.

Detén Jellyfin antes de mover el estado activo

Para realizar una migración de arquitectura controlada, apaga el proceso de Jellyfin del origen antes de crear la copia de migración. Esto evita que una base de datos activa o un estado de escritura anticipada cambien mientras se copian los archivos y te proporciona un único punto de reversión coherente.

Copia todo el ámbito de datos y configuración en lugar de seleccionar únicamente jellyfin.db. Una copia parcial puede conservar los usuarios y perder la configuración, los complementos, los metadatos u otro estado que el destino espera.

El mismo modelo de protección utilizado en un plan de copias de seguridad con varias copias se aplica aquí: mantén intacto el origen hasta que el destino haya superado una restauración real y una validación de reproducción.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Reconstruye los elementos específicos de la arquitectura en el nuevo host

Instala el paquete nativo de Jellyfin del destino o utiliza la imagen de contenedor multi-arquitectura correcta. Vuelve a crear las asignaciones de dispositivos GPU, los permisos de grupo, los paquetes de FFmpeg y cualquier ruta específica del host, en lugar de copiar binarios de la arquitectura antigua.

Revisa los complementos después del primer inicio. Los complementos que dependan de bibliotecas nativas, binarios incluidos o ejecutables externos pueden requerir una compilación que coincida con la nueva arquitectura. Desactiva temporalmente un complemento dudoso durante la primera validación si impide el inicio y vuelve a añadirlo solo después de confirmar su compatibilidad.

Si las rutas multimedia difieren entre los hosts, conserva las mismas rutas mediante montajes cuando resulte práctico. De lo contrario, planifica una migración de rutas compatible en lugar de editar manualmente los registros internos de la base de datos de Jellyfin.

Valida la migración antes de reutilizar el origen

Inicia únicamente la instancia del destino y confirma los usuarios, las bibliotecas, el estado de reproducción, las ilustraciones, las tareas programadas y una reproducción directa junto con una transcodificación necesaria. Comprueba en los registros si faltan bibliotecas nativas, si hay fallos de permisos o si alguna ruta todavía hace referencia al host antiguo.

Reinicia el destino dos veces y repite una prueba de reproducción para que el éxito sea persistente y no un inicio puntual. Si el destino falla, detenlo y restaura la copia de migración o vuelve al origen intacto, en lugar de permitir que ambas instancias escriban en el mismo estado.

La migración solo se completa cuando el nuevo host supera los reinicios y el uso doméstico normal. Si quieres mantener disponible la máquina antigua, asígnale una copia restaurada independiente o déjala apagada; no utilices un único directorio de datos activo de Jellyfin como almacenamiento compartido entre servidores ARM y x86.