Deve manter os metadados multimédia no SSD ou juntamente com a biblioteca?
Mantenha a base de dados e a cache ativa do servidor multimédia num SSD, armazenando os ficheiros NFO portáteis e as imagens selecionadas juntamente com a biblioteca quando a migração for importante.
“Metadados” combina vários elementos diferentes: a base de dados da aplicação, o estado do utilizador, índices, caches, imagens transferidas, imagens de capítulos, pré-visualizações trickplay, ficheiros NFO auxiliares e imagens selecionadas manualmente. Colocá-los todos no mesmo local cria latência desnecessária no HDD ou reduz a portabilidade. Um servidor multimédia doméstico funciona normalmente melhor com uma disposição dividida, cujos limites de cópia de segurança e recuperação estejam documentados.
Classifique os metadados antes de escolher uma unidade
Faça um inventário da base de dados da aplicação, configuração, contas de utilizador, histórico de visualização, índices, caches, miniaturas, cartazes, imagens de fundo, ficheiros NFO, legendas e dados dos plugins. Classifique cada item como autoritativo, portátil, recriável ou temporário.
A base de dados da aplicação e o estado do utilizador são normalmente específicos do servidor e alteram-se com frequência. Os ficheiros NFO e as imagens armazenados junto dos conteúdos multimédia são complementos ao nível dos ficheiros que podem ser lidos por outra biblioteca compatível, enquanto as caches e miniaturas geradas podem ser descartáveis.
Não escolha uma localização apenas pelo nome da pasta. Um diretório chamado “metadados” pode conter tanto edições manuais irrepetíveis como caches de imagens facilmente regeneráveis, pelo que o seu conteúdo exige regras diferentes de cópia de segurança e colocação.
Coloque as bases de dados, os índices e as caches ativas num SSD
As consultas à base de dados, a navegação na biblioteca, a pesquisa, as atualizações do estado dos utilizadores e a procura de miniaturas envolvem muitas leituras e escritas pequenas. Um SSD reduz a latência destas operações e mantém-nas afastadas da carga sequencial dos conteúdos multimédia.
O armazenamento rápido não dispensa um sistema de ficheiros seguro nem um volume com capacidade suficiente. Um problema do Jellyfin relata bloqueios da base de dados e uma interface sem resposta durante a utilização normal, ilustrando que a base de dados da aplicação é uma dependência operacional ativa, não uma cache descartável.
Coloque toda a unidade persistente de dados da aplicação num SSD com espaço livre adequado, snapshots e cópias de segurança. Evite colocar a base de dados ativa numa partilha de rede, exceto quando a aplicação suportar explicitamente o seu comportamento de bloqueio e latência.
Mantenha os ficheiros NFO portáteis e as imagens selecionadas junto dos conteúdos multimédia quando for útil
Os ficheiros NFO auxiliares, os cartazes locais, as etiquetas de edição e as imagens selecionadas manualmente podem facilitar a reconstrução de uma biblioteca noutra instância. Permanecem visíveis na pasta do filme quando a base de dados da aplicação é perdida.
A portabilidade não é garantida entre todas as versões e analisadores. Um relatório de migração do Jellyfin descreve ficheiros NFO existentes a serem ignorados e substituídos após uma transferência, pelo que é necessário testar a importação antes de depender dos ficheiros auxiliares como único método de recuperação.
Armazene apenas os metadados que a aplicação consiga ler de forma consistente e que pretenda preservar. Mantenha uma cópia de segurança dos ficheiros selecionados manualmente e impeça que os fornecedores automáticos os substituam sem um teste controlado.
Respeite os limites de bibliotecas só de leitura e as permissões
Uma montagem de conteúdos multimédia só de leitura protege os ficheiros de origem contra alterações acidentais da aplicação, mas também impede o servidor de escrever ficheiros NFO, imagens, coleções e pré-visualizações locais junto da biblioteca.
Um problema do Jellyfin identificou falhas na criação de coleções com um sistema de ficheiros multimédia só de leitura, apesar de a configuração da aplicação ter permissões de escrita no SSD. O caso demonstra por que motivo a localização de escrita afeta as funcionalidades de metadados.
Se a imutabilidade da origem for importante, mantenha os conteúdos multimédia em modo só de leitura e direcione os metadados geridos pela aplicação para o seu volume SSD. Conceda acesso de escrita à biblioteca apenas quando os ficheiros auxiliares locais forem uma parte intencional do plano de recuperação, limitando esse acesso à identidade do serviço.
Mantenha os dados de pré-visualização recriáveis separados do estado crítico
As imagens trickplay, as miniaturas de capítulos, as grelhas de pré-visualização extraídas e as caches temporárias podem tornar-se muito maiores do que a base de dados principal. Também têm um valor diferente para cópias de segurança, pois podem frequentemente ser regeneradas.
O Jellyfin disponibiliza opções para guardar imagens e imagens trickplay junto dos conteúdos multimédia, o que melhora a visibilidade e a migração em algumas disposições. O código da interface descreve a colocação de imagens locais e trickplay como opções separadas, e não como uma única localização universal de metadados.
Utilize uma cache ou um subvolume de metadados dedicado quando o crescimento das pré-visualizações for significativo. Faça cópias de segurança da base de dados e dos metadados manuais com maior frequência do que das miniaturas recriáveis e documente quais as pastas que podem ser eliminadas durante a recuperação.
Escolha a disposição com base nas necessidades de recuperação e migração
Utilize metadados da aplicação exclusivamente no SSD quando um único servidor for responsável pela biblioteca, a montagem dos conteúdos multimédia dever permanecer só de leitura e a navegação rápida for mais importante do que a portabilidade ao nível dos ficheiros. Utilize ficheiros NFO e imagens locais quando os metadados selecionados tiverem de acompanhar os ficheiros ou quando várias ferramentas compatíveis partilharem a biblioteca.
Uma disposição dividida proporciona normalmente o melhor limite: base de dados, utilizadores, índices e caches ativas no SSD; conteúdos multimédia de origem no armazenamento de capacidade; ficheiros NFO selecionados e imagens escolhidas junto dos conteúdos; pré-visualizações recriáveis de grandes dimensões numa cache com capacidade dimensionada separadamente ou num caminho local suportado.
| Tipo de dados | Localização preferida | Prioridade da cópia de segurança |
|---|---|---|
| Base de dados da aplicação, utilizadores, estado de visualização | Volume SSD da aplicação | Alta |
| Índices e cache ativa | SSD ou cache dedicada | Baixa a média |
| Ficheiros NFO e imagens selecionados | Junto dos conteúdos multimédia quando a portabilidade for importante | Alta se tiverem sido editados manualmente |
| Imagens trickplay e de capítulos | Cache dimensionada ou caminho local suportado | Normalmente recriável |
| Filmes e séries de origem | Armazenamento de capacidade | Com base na possibilidade de substituição |
O guia da ZimaSpace sobre a escolha de unidades NAS para cargas de trabalho de aplicações e metadados fornece o contexto de desempenho de armazenamento para esta divisão.
Verifique a disposição com testes de cópia de segurança e restauro
Pare o servidor multimédia e faça uma cópia de segurança do volume SSD da aplicação, bem como de quaisquer metadados auxiliares armazenados com a biblioteca. Restaure-os numa instância isolada utilizando os mesmos caminhos de contentores e permissões.
Confirme que os utilizadores, o histórico de visualização, as coleções, as correspondências manuais, as imagens e um item com trickplay ativado regressam conforme esperado. Em seguida, teste uma segunda recuperação utilizando apenas os ficheiros multimédia e os ficheiros auxiliares, para perceber o que seria perdido sem a base de dados da aplicação.
A disposição está correta quando a navegação continua responsiva, o armazenamento da aplicação apresenta um crescimento previsível, os conteúdos multimédia podem permanecer só de leitura conforme previsto e a cópia de segurança documentada recria todas as partes não recriáveis. Altere a colocação apenas depois de o teste de restauro revelar um problema real de velocidade, capacidade ou portabilidade.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
