¿Puedes conservar el historial de reproducciones durante una migración del servidor multimedia?
Sí, el historial de reproducción puede conservarse cuando la migración incluye la base de datos de usuarios, la identidad de los archivos multimedia y el estado compatible de la aplicación en el nuevo servidor.
Copiar solo los archivos de películas no transfiere las marcas de reproducción, las posiciones de reanudación, los favoritos, las cuentas de usuario ni las preferencias por pista. Esos registros se almacenan en la base de datos persistente del servidor multimedia y están vinculados a identificadores de usuarios y archivos multimedia. La opción más segura es realizar una migración completa de una instancia en la misma plataforma, con una copia de seguridad coherente hecha con el servicio detenido, versiones coincidentes, rutas de contenedor estables y una prueba de restauración aislada antes de convertir el destino en el servidor activo.
Define si vas a mover una instancia o cambiar de plataforma
Una migración de la misma aplicación de un host a otro normalmente puede conservar el estado completo del servidor. Un cambio de Plex a Jellyfin, de Emby a Jellyfin o entre otras plataformas requiere una exportación, un servicio de sincronización, un complemento o una traducción basada en API, porque las bases de datos utilizan esquemas e identificadores diferentes.
Los usuarios de Jellyfin han solicitado una exportación más sencilla de cuentas, historial de reproducción y ajustes de usuario precisamente porque los datos de usuario no se reducen a copiar una carpeta multimedia.
Elige una ruta antes de comenzar: restauración de la instancia completa para el mismo servidor multimedia, o transferencia documentada del estado de reproducción para un cambio de plataforma. No combines ambas opciones copiando parcialmente una base de datos en un destino recién escaneado.
Haz una copia de seguridad del estado persistente completo del servidor
Haz un inventario de la configuración, la base de datos, los usuarios, los complementos, los metadatos, los certificados, los ajustes de tareas programadas y el entorno del contenedor. Registra la versión en ejecución de la aplicación, la etiqueta de la imagen, la ubicación de la base de datos y todos los montajes persistentes.
El estado de reproducción puede incluir más que un valor booleano. Una conversación de Jellyfin identifica campos como el estado de reproducción, el número de reproducciones, la posición de reproducción, la fecha de la última reproducción, los favoritos y las pistas seleccionadas en los registros de datos de usuario.
Haz una copia de seguridad de todo el conjunto de persistencia compatible en lugar de exportar una sola tabla, salvo que no exista una ruta de restauración completa. Un trasplante parcial de la base de datos puede conservar un campo y, al mismo tiempo, romper los identificadores de usuario, las referencias multimedia, las expectativas del esquema o el historial de migraciones más reciente.
Detén el servidor o utiliza una instantánea coherente de la base de datos
Impide la reproducción, los escaneos, las actualizaciones de metadatos y los cambios de usuario mientras creas la copia de seguridad final. Detén el proceso del servidor multimedia antes de copiar archivos SQLite, a menos que el almacenamiento y la aplicación admitan un método coherente de copia de seguridad en línea.
Una conversación sobre copias de seguridad de Jellyfin advierte que copiar archivos SQLite activos puede capturar un estado incoherente, porque la base de datos puede estar en uso durante una copia de seguridad normal del sistema de archivos.
Registra las sumas de comprobación y los tamaños de los archivos después de detener el servicio y mantén el servidor de origen sin cambios hasta que el destino supere la verificación. No permitas que ambos servidores escriban en la misma base de datos ni en el mismo destino de sincronización del estado de reproducción durante el cambio.
Mantén controladas las versiones de la aplicación y la dirección de actualización
Cuando sea posible, restaura primero en la misma versión de la aplicación. Confirma que los complementos, el esquema de la base de datos y las rutas de los contenedores coincidan antes de actualizar el destino.
Las migraciones de bases de datos pueden ser unidireccionales, y una instancia restaurada puede fallar cuando el estado de migración registrado no coincide con el esquema real. Un problema actual de Jellyfin documenta un conflicto del estado de migración restaurado.
Inicia el servidor restaurado sin acceso público de los clientes, revisa su registro de migración y crea otra instantánea antes de realizar cualquier actualización. Nunca pruebes una versión más reciente con la única copia de la base de datos y esperes que la versión antigua del servidor pueda volver a abrirla.
Conserva las rutas multimedia estables y la identidad de los elementos
Mantén las mismas rutas visibles dentro del contenedor aunque cambien los discos del host. Por ejemplo, asigna el nuevo grupo de almacenamiento a las rutas existentes /media/movies y /media/tv en lugar de enseñar al destino unas raíces de biblioteca completamente nuevas.
Cambiar las rutas puede crear nuevos registros multimedia o dejar entradas obsoletas junto a las restauradas. Un problema de Jellyfin relaciona las rutas de biblioteca eliminadas con metadatos obsoletos persistentes y un comportamiento duplicado de contenido pendiente de reproducción.
Verifica una película y un episodio mediante la ruta del archivo y la identidad interna del elemento antes de iniciar un escaneo completo. Si el destino considera que todos los archivos son nuevos, detente y corrige la asignación de rutas antes de que los vínculos del estado de reproducción se dispersen entre registros duplicados.
Mantén la coherencia de los usuarios y sus identificadores
Restaura los usuarios con la base de datos en lugar de recrear manualmente las cuentas con los mismos nombres visibles. Que el nombre de usuario sea igual no demuestra que el usuario del destino tenga el mismo identificador interno.
La restauración manual del historial suele dirigirse a la tabla de datos de usuario, pero los registros dependen tanto de las referencias de usuario como de las multimedia. Por ello, mover las ubicaciones de las bibliotecas sin perder los metadatos ha requerido gestionar cuidadosamente las rutas y la base de datos, en lugar de hacer un escaneo ciego de los archivos movidos.
Después de la restauración, inicia sesión como cada usuario representativo y compara las marcas de reproducción, los elementos en curso, las posiciones de reanudación, los favoritos y las preferencias de audio y subtítulos. No evalúes el éxito únicamente desde la cuenta de administrador.
Utiliza una ruta de sincronización o exportación para los cambios entre plataformas
Cuando las aplicaciones de origen y destino sean diferentes, exporta el historial mediante un complemento compatible, una herramienta de API o un servicio neutral de seguimiento de reproducciones. Prueba con una muestra pequeña antes de sincronizar toda la biblioteca.
Relaciona explícitamente los usuarios y los títulos, y considera que los episodios, las ediciones, los montajes alternativos y los archivos renombrados pueden generar conflictos de identidad. El título de una película por sí solo es demasiado impreciso cuando varios años o versiones comparten el mismo nombre.
Conserva una exportación del historial de origen incluso después de que la primera importación se complete correctamente. La transferencia debe poder repetirse o auditarse para corregir usuarios ausentes y títulos mal relacionados sin tener que reiniciar la migración.
Realiza una restauración aislada y cambia de servidor solo después de verificarla
Inicia el destino en un puerto temporal, con los escaneos programados, los webhooks y la sincronización externa desactivados. Verifica los usuarios, el número de elementos de las bibliotecas, los totales de contenido reproducido, las posiciones de reanudación, las listas de reproducción, las colecciones y varios títulos seleccionados al azar.
El flujo de trabajo de migración de datos NAS de ZimaSpace establece la regla general: conserva el origen hasta haber verificado desde el destino el estado copiado.
La migración solo está completa cuando la instancia restaurada supera un reinicio, las rutas permanecen estables, los usuarios representativos conservan su historial y las nuevas reproducciones actualizan correctamente el destino. Mantén el origen desconectado, pero recuperable, hasta que el nuevo servidor haya superado varios días de uso normal y disponga de una copia de seguridad reciente.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
