É possível preservar o histórico de visualizações durante a migração de um servidor multimédia?

Sim, o histórico de visualização pode ser preservado quando a migração inclui a base de dados dos utilizadores, a identidade dos conteúdos multimédia e o estado compatível da aplicação no novo servidor.

Copiar apenas os ficheiros de filmes não transfere os indicadores de reprodução, as posições de retoma, os favoritos, as contas de utilizador nem as escolhas por faixa. Esses registos estão na base de dados persistente do servidor multimédia e estão associados a identificadores de utilizadores e conteúdos. A opção mais segura é uma migração completa da instância na mesma plataforma, com uma cópia de segurança consistente feita com o serviço parado, versões correspondentes, caminhos de contentor estáveis e um teste de restauro isolado antes de o destino se tornar o servidor ativo.

Defina se Está a Mover uma Instância ou a Mudar de Plataforma

Uma migração da mesma aplicação de um anfitrião para outro consegue normalmente preservar o estado completo do servidor. Uma mudança do Plex para o Jellyfin, do Emby para o Jellyfin ou para outra plataforma requer uma exportação, um serviço de sincronização, um plugin ou uma tradução baseada em API, porque as bases de dados utilizam esquemas e identificadores diferentes.

Os utilizadores do Jellyfin têm pedido uma exportação mais simples de contas, histórico de visualização e definições de utilizador precisamente porque os dados dos utilizadores não são uma simples cópia da pasta multimédia.

Escolha uma abordagem antes de começar: restauro completo da instância para o mesmo servidor multimédia ou uma transferência documentada do estado de visualização para uma mudança de plataforma. Não combine as duas abordagens copiando parcialmente uma base de dados para um destino recém-analisado.

Faça uma Cópia de Segurança de Todo o Estado Persistente do Servidor

Faça o inventário da configuração, da base de dados, dos utilizadores, dos plugins, dos metadados, dos certificados, das definições de tarefas agendadas e do ambiente dos contentores. Registe a versão da aplicação em execução, a etiqueta da imagem, a localização da base de dados e todos os montagens persistentes.

O estado de visualização pode incluir mais do que um valor booleano. Uma discussão do Jellyfin identifica campos como o estado de reprodução, a contagem de reproduções, a posição de reprodução, a data da última reprodução, os favoritos e as faixas selecionadas nos registos de dados do utilizador.

Faça uma cópia de segurança de todo o conjunto de persistência suportado, em vez de exportar apenas uma tabela, salvo quando não existir um método de restauro completo. Um transplante parcial da base de dados pode preservar um campo e, ao mesmo tempo, danificar os IDs dos utilizadores, as referências aos conteúdos, as expectativas do esquema ou o histórico de migrações mais recente.

Pare o Servidor ou Utilize um Instantâneo Consistente da Base de Dados

Impeça a reprodução, as análises, as atualizações de metadados e as alterações dos utilizadores enquanto cria a cópia de segurança final. Pare o processo do servidor multimédia antes de copiar ficheiros SQLite, salvo quando o armazenamento e a aplicação suportarem um método consistente de cópia de segurança em funcionamento.

Uma discussão sobre cópias de segurança do Jellyfin alerta para o facto de que copiar ficheiros SQLite ativos pode capturar um estado inconsistente, porque a base de dados pode estar a ser utilizada durante uma cópia de segurança normal do sistema de ficheiros.

Registe as somas de verificação e os tamanhos dos ficheiros depois de parar o serviço e mantenha o servidor de origem inalterado até o destino passar a verificação. Não permita que ambos os servidores escrevam na mesma base de dados ou no mesmo destino de sincronização do estado de visualização durante a transição.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mantenha as Versões da Aplicação e a Direção das Atualizações sob Controlo

Quando possível, faça primeiro o restauro para a mesma versão da aplicação. Confirme que os plugins, o esquema da base de dados e os caminhos dos contentores correspondem antes de atualizar o destino.

As migrações da base de dados podem ser unidirecionais, e uma instância restaurada pode falhar quando o estado de migração registado não corresponde ao esquema real. Um problema atual do Jellyfin documenta um conflito no estado da migração restaurada.

Inicie o servidor restaurado sem acesso de clientes externos, consulte o respetivo registo de migração e crie outro instantâneo antes de qualquer atualização. Nunca teste uma versão mais recente com a única cópia da base de dados e espere depois que a versão antiga consiga reabri-la.

Preserve os Caminhos Multimédia Estáveis e a Identidade dos Itens

Mantenha os mesmos caminhos visíveis nos contentores, mesmo que os discos do anfitrião mudem. Por exemplo, remapeie um novo conjunto de armazenamento para os caminhos existentes /media/movies e /media/tv, em vez de ensinar ao destino raízes de biblioteca completamente novas.

A alteração dos caminhos pode criar novos registos multimédia ou deixar entradas obsoletas junto das restauradas. Um problema do Jellyfin associa caminhos de biblioteca removidos a metadados obsoletos persistentes e a um comportamento duplicado de continuação da visualização.

Verifique um filme e um episódio pelo caminho do ficheiro e pela identidade interna do item antes de iniciar uma análise completa. Se o destino considerar todos os ficheiros como novos, pare e corrija o mapeamento dos caminhos antes que as associações do estado de visualização se dispersem por registos duplicados.

Mantenha os Utilizadores e os Respetivos Identificadores Consistentes

Restaure os utilizadores com a base de dados, em vez de recriar manualmente contas com os mesmos nomes apresentados. Um nome de utilizador visível não prova que o utilizador no destino tenha o mesmo identificador interno.

O restauro manual do histórico normalmente visa a tabela de dados do utilizador, mas os registos dependem tanto das referências aos utilizadores como das referências aos conteúdos. Por isso, mover localizações de bibliotecas sem perder metadados exige um tratamento cuidadoso dos caminhos e da base de dados, e não uma nova análise cega dos ficheiros movidos.

Depois do restauro, inicie sessão como cada utilizador representativo e compare os indicadores de visualização, os itens em curso, as posições de retoma, os favoritos, as escolhas de áudio e as escolhas de legendas. Não avalie o sucesso apenas através da conta de administrador.

Utilize uma Rota de Sincronização ou Exportação para Mudanças entre Plataformas

Quando as aplicações de origem e de destino são diferentes, exporte o histórico através de um plugin suportado, de uma ferramenta de API ou de um serviço neutro, como uma plataforma de acompanhamento de visualizações. Teste uma amostra pequena antes de sincronizar toda a biblioteca.

Associe explicitamente os utilizadores e os títulos e trate os episódios, as edições, as versões alternativas e os ficheiros renomeados como potenciais conflitos de identidade. Um título de filme, por si só, é demasiado pouco específico quando vários anos ou versões partilham o mesmo nome.

Conserve uma exportação do histórico de origem mesmo depois de a primeira importação ser bem-sucedida. A transferência deve ser repetível ou auditável, para que os utilizadores em falta e os títulos incompatíveis possam ser corrigidos sem reiniciar a migração.

Faça um Restauro Isolado e Só Conclua a Transição Após a Verificação

Inicie o destino numa porta temporária, com as análises agendadas, os webhooks e a sincronização externa desativados. Verifique os utilizadores, as contagens das bibliotecas, os totais de conteúdos vistos, as posições de retoma, as listas de reprodução, as coleções e vários títulos selecionados aleatoriamente.

O fluxo de trabalho de migração de dados NAS do ZimaSpace apresenta a regra geral: preserve a origem até o estado copiado ter sido verificado a partir do destino.

A migração só está concluída quando a instância restaurada sobrevive a um reinício, os caminhos permanecem estáveis, os utilizadores representativos mantêm o respetivo histórico e novas reproduções atualizam corretamente o destino. Mantenha a origem offline, mas recuperável, até o novo servidor ter passado vários dias de utilização normal e ter uma cópia de segurança recente.