Lista de comprobación previa a la actualización para contenedores y dependencias de Jellyfin

Antes de actualizar un contenedor de Jellyfin, conserva ambos lados del despliegue: el estado persistente de Jellyfin y la definición exacta del contenedor que sabe cómo acceder a él. Descargar una imagen nueva es fácil; recuperar una base de datos migrada, un montaje modificado o una asignación de dispositivo olvidada no lo es.

Usa la lista de comprobación en orden de dependencias. Primero demuestra que puedes recuperar los datos; después registra la imagen actual y la configuración del entorno de ejecución; luego revisa la ruta de lanzamiento y solo entonces reemplaza la imagen. Después, prueba las mismas bibliotecas, usuarios, modos de reproducción, tareas programadas y comportamiento de reinicio antes de eliminar la copia de reversión.

Registra la última imagen funcional y la definición del contenedor

Guarda la etiqueta de imagen actual de Jellyfin y, cuando sea práctico, también su resumen criptográfico. Exporta o copia el archivo Compose o la definición de la aplicación que contenga los puertos, las redes, los montajes, los valores de entorno, la política de reinicio, la asignación de usuarios, los grupos suplementarios, los dispositivos GPU y cualquier relación con un proxy inverso.

La documentación oficial del contenedor de Jellyfin distingue entre etiquetas móviles como latest y etiquetas explícitas de versión mayor, menor y de parche. comportamiento de las etiquetas de imagen de Jellyfin Una reversión es más sencilla cuando conoces la versión exacta que funcionaba, en lugar de recordar únicamente que «latest funcionaba ayer».

No elimines la imagen antigua ni borres la definición guardada hasta que la nueva versión supere todo el periodo de validación. Si la actualización falla antes de modificar los datos persistentes, conservar la imagen y la definición te proporciona la ruta de recuperación menos invasiva.

Crea una copia de seguridad recuperable del estado de Jellyfin

Protege los directorios de datos y configuración de Jellyfin antes de cambiar la imagen. La copia de seguridad debe estar fuera de la ruta de la aplicación activa y poder leerse de forma independiente; una segunda copia o instantánea en el mismo conjunto de datos solo resulta útil si entiendes frente a qué fallo te protege.

La documentación de copias de seguridad de Jellyfin advierte que las actualizaciones pueden requerir restaurar los datos porque no existe un mecanismo general de reversión después de aplicar las migraciones. También documenta las copias de seguridad integradas y el requisito de detener limpiamente el servicio para realizar copias manuales de archivos. guía de copias de seguridad y restauración de Jellyfin

En un flujo de trabajo con contenedores, el mismo principio se aborda en el flujo de trabajo de ZimaSpace para crear un punto de reversión antes de actualizar. Detente aquí si no puedes identificar las rutas persistentes o verificar el contenido de la copia de seguridad.

Captura los montajes, UID/GID y dependencias de hardware

Enumera cada montaje enlazado y volumen con nombre, e indica si es de solo lectura o de lectura y escritura. Registra el UID/GID del entorno de ejecución, las pertenencias a grupos y la propiedad de los directorios de datos de Jellyfin. Captura también las asignaciones de GPU o dispositivos de renderizado si está activada la aceleración por hardware.

La guía de contenedores de Jellyfin muestra que los medios, la configuración y la caché se montan por separado, y que el contenedor puede ejecutarse con un UID/GID especificado. rutas persistentes y asignación de usuarios Estos valores son dependencias, no elementos decorativos: un contenedor recreado puede iniciarse correctamente mientras ve un directorio de configuración vacío o pierde el permiso para acceder a un dispositivo.

Compara la definición guardada con el contenedor en ejecución efectivo, no solo con una plantilla que crees que está actualizada. Si el entorno de ejecución tiene cambios manuales que faltan en Compose o en la definición de la aplicación del NAS, corrige esa desviación antes de actualizar para que el despliegue antiguo sea reproducible.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comprueba la ruta de actualización compatible y el riesgo de los complementos

Lee las notas de lanzamiento de cada límite entre versiones mayores que haya entre la versión actual y la de destino. Busca versiones intermedias obligatorias, migraciones de la base de datos, cambios de configuración, compatibilidad de complementos, requisitos de FFmpeg o tareas de inicio prolongadas.

La documentación de actualización de Jellyfin insiste repetidamente en la importancia de las copias de seguridad y explica por qué los cambios de esquema pueden hacer imposible una simple reversión. límites de actualización y reversión Las notas de lanzamiento de versiones mayores pueden añadir requisitos previos específicos, así que no deduzcas que el salto es seguro solo porque exista la imagen del contenedor.

Si un complemento es esencial, confirma que haya una versión compatible antes de actualizar el servidor. Si un complemento es opcional y tiene antecedentes de bloquear el inicio, registra su versión actual y prepárate para desactivar únicamente ese complemento si los registros del nuevo servidor lo identifican como la fuente del fallo.

Realiza la actualización sin cambiar el límite del estado

Detén Jellyfin limpiamente, descarga la imagen prevista y recrea únicamente el servicio de Jellyfin con las mismas rutas persistentes y dependencias del entorno de ejecución ya verificadas. No combines la actualización con una migración de almacenamiento, un rediseño de UID/GID, una reescritura del proxy inverso y una reconfiguración de la GPU, a menos que esos cambios sean el objetivo real del mantenimiento.

Observa el registro del primer inicio. Una migración puede tardar legítimamente en una biblioteca grande, mientras que un mensaje inmediato de «permiso denegado», base de datos vacía, ruta ausente o esquema incompatible apunta a una situación diferente. No reinicies repetidamente una migración solo porque la interfaz no esté disponible de inmediato.

Si el contenedor se abre como un servidor nuevo, detenlo antes de configurar nada. Ese síntoma suele indicar que el nuevo servicio apunta al estado persistente equivocado. Corrige primero la asignación de montajes; configurar una instancia nueva y vacía puede crear archivos nuevos que dificulten la recuperación.

Valida la nueva versión antes de eliminar los recursos de reversión

Verifica la identidad del servidor original, los usuarios, las bibliotecas, los metadatos y las configuraciones importantes. Reproduce un elemento mediante reproducción directa y otro mediante transcodificación representativa; después, ejecuta u observa una tarea programada importante para tu configuración. Comprueba los registros en busca de errores recurrentes de migración, base de datos, permisos y FFmpeg.

Reinicia el contenedor una vez después de la primera sesión correcta. La nueva versión no estará completamente validada hasta que pueda volver a abrir los mismos datos y dispositivos tras una recreación o un reinicio limpio. Esto detecta la dependencia accidental de un montaje temporal o de un estado transitorio del entorno de ejecución.

Conserva la copia de seguridad previa a la actualización, la referencia de la imagen anterior y la definición guardada hasta que el servidor haya superado su periodo de carga de trabajo normal. Si es necesario revertir después de una migración de la base de datos, sigue el límite de restauración documentado por Jellyfin en lugar de apuntar una imagen antigua a un estado ya migrado.