Preserve o estado do Plex que define o servidor e a biblioteca; trate os dados temporários de cache e transcodificação como reconstruíveis, salvo se o seu plano de recuperação exigir o contrário.
A chave é a capacidade de recuperação, não o tamanho das pastas. A configuração, as bases de dados, os metadados, as imagens, as referências ao estado de visualização e a identidade do servidor são difíceis ou demorados de recriar de forma consistente, enquanto os ficheiros temporários de transcodificação e muitos artefactos de cache podem ser regenerados. Classifique cada caminho pelo que aconteceria após a sua eliminação antes de decidir onde o incluir.
O estado do servidor é mais do que um ficheiro de definições
Uma implementação do Plex é definida por um conjunto de ficheiros persistentes, não apenas pelas preferências visíveis na interface Web. A base de dados da biblioteca e os diretórios de metadados contêm relações e o estado do servidor que fazem com que uma instância restaurada se pareça com a antiga.
O armazenamento de metadados do Plex inclui bases de dados, imagens, índices e outros ficheiros de estado do servidor.
Enumere todos os caminhos do Plex montados e assinale quais seriam necessários para reproduzir as mesmas bibliotecas e metadados num anfitrião limpo. Se um caminho contiver o estado da base de dados ou dos metadados do servidor, inclua-o no conjunto de cópias de segurança persistentes. Manter os dados persistentes dos contentores fora do ambiente de execução substituível ajuda a separar as camadas reconstruíveis do estado que tem de sobreviver à substituição do contentor.
O cache é valioso, mas normalmente reconstruível
O cache pode reduzir a latência sem ser a cópia oficial da biblioteca. Perder um cache aquecido pode tornar o servidor mais lento durante algum tempo, mas não deve ser tratado da mesma forma que a perda da base de dados.
O caching de páginas do Linux pode reduzir o acesso repetido ao armazenamento assim que os dados ficam carregados na memória.
Reinicie uma instância de teste apenas com o cache descartável conhecido limpo e compare o comportamento de aquecimento com o do servidor intacto. Se o servidor perder a identidade da biblioteca ou as definições, o caminho removido não era apenas cache descartável.
A integridade da base de dados altera a prioridade da cópia de segurança
Os dados persistentes só são úteis se a base de dados capturada for internamente consistente. Uma base de dados copiada durante operações de escrita pode ser menos fiável do que uma cópia de segurança produzida durante um estado controlado e sem atividade.
A segurança das escritas no SQLite favorece escritas controladas, pelo que a base de dados Plex ativa não deve ser usada como teste de permissões.
Programe uma janela de cópia de segurança que, quando possível, coloque o processo de escrita em pausa ou o pare; em seguida, verifique se é possível abrir a base de dados copiada. Quando o teste de restauro falhar apesar de os ficheiros terem sido copiados com sucesso, corrija primeiro a consistência da cópia de segurança antes de aumentar a retenção.
O espaço temporário de transcodificação pertence a uma classe de recuperação diferente
A saída da transcodificação é constituída por dados de trabalho criados para um percurso de reprodução, não pela biblioteca oficial. Pode ser colocada tendo em conta a velocidade e a capacidade, sem impor a mesma política de durabilidade da base de dados Plex.
Quando é necessária a transcodificação do Plex, a compatibilidade do cliente transfere para o servidor o trabalho de descodificação e codificação.
Documente as montagens de transcodificação e cache separadamente da montagem de dados persistentes do Plex no ficheiro de implementação. Se um caminho temporário for o único local onde existe uma definição exclusiva ou um ficheiro de base de dados, reclassifique-o antes da próxima migração.
Centro de Tecnologia e IA
Mais para Ler

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

