Como migrar o Jellyfin de um computador de secretária para uma stack multimédia de código aberto

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Migre o Jellyfin atribuindo funções explícitas ao estado da aplicação, aos conteúdos multimédia, à cache, às cópias de segurança e ao acesso à rede, antes de escolher contentores ou um NAS.

Normalmente, um computador de secretária reúne todas as funções num único sistema de ficheiros e numa única fonte de alimentação. Uma pilha multimédia de código aberto separa essas funções, pelo que a migração só é bem-sucedida quando cada caminho, UID/GID, dependência de serviço e ação de restauro são mapeados antes de o primeiro contentor arrancar. Preserve o computador de secretária como fonte de reversão até que um reinício limpo e um teste real num cliente sejam concluídos com sucesso.

Mapeie o computador de secretária para funções de serviço

Faça o inventário da configuração e da base de dados do Jellyfin, das bibliotecas multimédia, da cache de metadados e imagens, dos plugins, da cache de legendas, dos utilizadores e de quaisquer dependências de proxy inverso ou DNS. Classifique cada elemento como estado persistente da aplicação, conteúdos multimédia insubstituíveis, cache recriável, cópia de segurança ou suporte de recuperação. Não copie uma cache como se fosse uma base de dados e não trate um volume multimédia espelhado como uma segunda cópia de segurança.

A fronteira da migração é clara quando cada função tem um responsável, um destino, um caminho de acesso e uma ação de restauro. Se uma função não puder ser restaurada de forma independente, mantenha-a no computador de secretária até rever o desenho da pilha.

Escolha a topologia de destino antes de selecionar as imagens

Utilize uma função de serviço para o Jellyfin, um volume de dados persistente para a configuração e a base de dados, um volume multimédia com caminhos estáveis e um destino de cópia de segurança separado. Coloque o proxy inverso, a monitorização e os serviços experimentais nos seus próprios caminhos ou redes quando for importante limitar a propagação de falhas. Uma ferramenta de migração de terceiros demonstra por que motivo a tradução de caminhos e o tratamento da base de dados precisam de um plano explícito, em vez de uma simples cópia cega de pastas (notas de migração do Jellyfin com conhecimento dos caminhos).

Preserve os caminhos e as permissões durante a migração

Pare o serviço no computador de secretária, faça uma cópia dos dados persistentes e verifique-a antes de os transformar. No destino, mantenha o caminho multimédia dentro do contentor idêntico ao caminho registado na base de dados sempre que possível. Defina o UID/GID do contentor para uma entidade que possa ler os conteúdos multimédia e escrever apenas nos diretórios da aplicação necessários. Teste a análise de uma biblioteca e o início de sessão de um utilizador antes de importar plugins ou adicionar automatizações.

A decisão é PASS quando o Jellyfin consegue ler todas as bibliotecas pretendidas, escrever na sua base de dados e reiniciar sem alterar o mapa de caminhos. Se as permissões exigirem acesso amplo de escrita à árvore multimédia, separe as funções de dados e da aplicação antes de continuar.

-15% OFF

Valide a reprodução, os utilizadores e a recuperação por camadas

Execute uma reprodução direta local, uma transcodificação representativa, testes de legendas e um segundo perfil de utilizador. Em seguida, pare e recrie a pilha a partir da definição do compose ou da implementação, e não a partir de uma shell interativa. Restaure a cópia de segurança dos dados da aplicação numa localização de teste limpa e confirme se o estado de visualização, os utilizadores e os caminhos das bibliotecas foram preservados ou reconstruídos intencionalmente.

Só depois destes testes deverá adicionar acesso remoto ou serviços adicionais. Um equipamento compacto como o NAS com IA ZimaCube 2 pode ser considerado quando os requisitos neutros — armazenamento persistente, margem de recursos para contentores e um caminho de cópia de segurança separado — já corresponderem à pilha.

Defina os limites de expansão e paragem

Expanda adicionando uma camada de armazenamento, um nó de computação capaz de transcodificar ou uma função de rede separada; não resolva todas as novas cargas de trabalho aumentando um único volume partilhado. Mantenha a cópia de reversão do computador de secretária quando um plugin, uma conversão de caminhos ou uma migração de utilizadores não tiver sido verificada. A pilha está pronta quando uma reconstrução documentada produz o mesmo acesso às bibliotecas e o mesmo resultado de reprodução sem o computador de secretária original estar em execução.

Configuração de NAS e Servidor

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.