Conceba a recuperação e a expansão do Plex em conjunto, separando o estado da aplicação, os conteúdos multimédia, as cópias de segurança, os destinos de restauro e os gatilhos de crescimento antes da primeira alteração de capacidade.
Uma cópia de segurança só é útil quando consegue recriar o serviço que prometeu, e a expansão só é segura quando esse percurso de recuperação continua a funcionar depois. Defina o que tem de ser reposto, quanta perda de dados é aceitável e quanto tempo a família pode esperar. Depois, atribua funções distintas ao estado do Plex, aos conteúdos multimédia, às credenciais, às cópias de segurança, ao espaço de recuperação e ao armazenamento futuro, para que possam ser testados após cada migração ou atualização.
Defina a promessa de recuperação antes da disposição do armazenamento
Registe o que a família espera após uma falha da unidade de arranque, a eliminação da base de dados, danos no disco de conteúdos multimédia ou a perda do servidor. A resposta pode variar consoante a classe de dados. As preferências do Plex, os utilizadores, o estado de visualização, os cartazes personalizados e as definições de automatização podem ser difíceis de reconstruir, mesmo quando os ficheiros multimédia continuam disponíveis. As gravações pessoais podem ser irrecuperáveis, enquanto os conteúdos comerciais podem ser obtidos novamente a partir de outra fonte.
Defina uma idade aceitável para cada cópia recuperável e um tempo máximo para repor o serviço essencial. Estas são promessas operacionais, não siglas abstratas. Se for aceitável perder um dia do estado de visualização, mas não um único vídeo familiar, essas duas funções não devem partilhar a mesma frequência ou destino de cópia de segurança. Se a família puder esperar um fim de semana por um restauro completo dos conteúdos multimédia, não dimensione todos os componentes para uma recuperação instantânea.
A disposição inicial do armazenamento só é válida quando cada promessa tem um responsável, uma cópia, uma ação de restauro e um local para onde restaurar. Um plano que enumera ficheiros de cópia de segurança, mas não tem um destino temporário de recuperação, está incompleto. Um plano que pressupõe que a matriz principal continua disponível não cobre uma falha dessa matriz.
Separe o estado do Plex da capacidade dos conteúdos multimédia
Mantenha a base de dados, os metadados, as preferências e a configuração do serviço Plex num local persistente claramente identificado. Armazene os conteúdos multimédia no seu próprio nível de capacidade. Coloque os ficheiros de transcodificação e outras caches reconstruíveis num espaço de trabalho descartável. Mantenha as credenciais, as chaves de encriptação e a configuração das cópias de segurança fora da árvore de conteúdos multimédia, para que uma cópia de ficheiros de grande dimensão nunca seja confundida com uma recuperação completa do servidor.
Esta separação encurta o primeiro passo da recuperação. Pode restaurar uma cópia pequena e consistente do estado da aplicação para um serviço isolado, associar-lhe um subconjunto representativo dos conteúdos multimédia e verificar se a instalação arranca antes de iniciar uma transferência de vários terabytes. Também impede que um volume multimédia completo esconda problemas relacionados com a recuperação da base de dados, das permissões ou dos pontos de montagem dos contentores.
Registe a propriedade, os identificadores, os pontos de montagem e as expectativas de caminhos juntamente com a função dos dados. Uma base de dados restaurada que aponta para um caminho multimédia diferente pode estar intacta, mas continuar inutilizável. Uma pasta de contentor copiada com a identidade de serviço errada pode arrancar e, ainda assim, não conseguir ler a biblioteca. A recuperação depende da topologia e das permissões, não apenas da presença dos ficheiros.
Atribua um percurso de recuperação diferente a cada falha
Utilize o sistema principal para o serviço, um destino de cópia de segurança separado para uma recuperação local rápida e outro domínio de falha para os dados cuja perda seria inaceitável. O terceiro local pode ser armazenamento externo, capacidade de nuvem encriptada ou suportes rotativos guardados noutro lugar. O objetivo é a independência: uma falha de energia, uma conta comprometida, uma eliminação acidental ou uma falha do controlador de armazenamento não devem afetar todas as cópias através do mesmo percurso.
Aplique retenção de versões ao estado pequeno e frequentemente alterado do Plex, para que uma atualização defeituosa ou um problema na base de dados não substitua a última cópia utilizável. Proteja os conteúdos multimédia irrecuperáveis com a profundidade de cópias adequada ao impacto da sua perda. Os conteúdos multimédia que podem ser transferidos novamente podem seguir uma política de menor custo, se o tempo de restauro e a disponibilidade da fonte forem aceitáveis. A redundância dentro do chassis principal é uma camada de disponibilidade, não um destes percursos de recuperação independentes.
Torne observável a conclusão das cópias de segurança. Registe a última cópia bem-sucedida do estado da aplicação, o estado da proteção dos conteúdos multimédia, a capacidade do destino e o resultado da verificação. Uma tarefa que termina com sucesso, mas não pode ser desencriptada, montada ou associada novamente ao caminho esperado, não cumpriu a promessa de recuperação.
Ensaie um restauro antes de a expansão alterar os caminhos
Restaure o estado do Plex para um contentor isolado, uma máquina virtual, um anfitrião suplente ou um diretório temporário que não possa escrever na biblioteca de produção. Utilize, sempre que possível, a mesma identidade de serviço e a mesma estrutura de caminhos. Associe uma pequena amostra de conteúdos multimédia e confirme que a base de dados abre, as bibliotecas aparecem, as permissões funcionam, a reprodução começa e as preferências ou o histórico críticos estão presentes.
Cronometre o ensaio a partir de um destino vazio, incluindo a obtenção das credenciais, a localização da cópia correta, o restauro dos ficheiros, a correção da propriedade e a validação do serviço. O resultado medido é mais útil do que uma velocidade de transferência estimada, porque a recuperação fica frequentemente à espera de decisões sobre caminhos e de notas em falta, e não da velocidade bruta do armazenamento.
Mantenha um registo breve da recuperação com a versão do software, a data da cópia de segurança, o destino, as ações, as exceções e as verificações finais. Repita o teste após alterações à imagem do contentor, ao sistema operativo, à montagem do armazenamento, à identidade do serviço, ao método de encriptação ou à ferramenta de cópia de segurança. Se o registo antigo já não descrever o sistema atual, a expansão já invalidou parte do percurso de recuperação.
Atualize o orçamento de cópias de segurança em cada expansão
Trate uma nova prateleira de discos, um conjunto maior, um NAS separado ou um nó de computação adicional como uma alteração da topologia, e não apenas como uma atualização de capacidade. Recalcule a quantidade de dados que tem de ser protegida, quanto tempo demorará a janela de cópia de segurança, quanto espaço livre o destino necessita e onde poderia ser feito um restauro equivalente. Atualize os caminhos de montagem, as permissões, a monitorização e o inventário antes de mover os dados de produção.
Prepare a alteração por fases, mantendo disponível o percurso de recuperação anterior até o novo passar no teste. Copie ou replique os dados, valide as contagens e os ficheiros representativos, altere um caminho e, em seguida, execute verificações do Plex e das cópias de segurança antes de retirar o local antigo. Evite alterar o armazenamento, a identidade do serviço, a versão da aplicação e o método de cópia de segurança na mesma janela de manutenção; demasiadas variáveis em simultâneo dificultam o diagnóstico de um restauro falhado.
A expansão fica bloqueada quando o destino das cópias de segurança não consegue absorver o novo conjunto protegido, quando o destino de restauro já não tem espaço suficiente ou quando o tempo de recuperação medido excede a promessa feita à família. Aumente a capacidade de proteção ou reduza a promessa de recuperação antes de o novo armazenamento se tornar a única cópia de produção.
Utilize provas de recuperação para decidir quando separar funções
Separe a computação do armazenamento dos conteúdos multimédia quando a substituição do servidor ou a manutenção da aplicação estiver a ser atrasada pela dimensão ou pela ligação da biblioteca. Adicione um destino dedicado para cópias de segurança quando o sistema principal já não conseguir conter as cópias de produção e de recuperação sem partilharem a mesma falha. Aumente a capacidade de rede quando as janelas de cópia de segurança e restauro forem limitadas pelo percurso, e não pelos discos em cada extremidade.
Utilize as previsões de espaço livre, a duração das cópias de segurança, o tempo dos ensaios de restauro e os testes de reprodução em carga máxima como gatilhos de expansão. Um novo componente tem de melhorar um desses limites medidos e preservar os restantes. Se adicionar um segundo espaço de nomes de armazenamento, credenciais não documentadas ou uma nova dependência de montagem sem melhorar a promessa de recuperação, aumentou a complexidade em vez da resiliência.
Pare quando o sistema já não puder ser ensaiado pela pessoa que deverá recuperá-lo, quando todas as cópias dependerem da mesma conta de administrador ou quando proteger a biblioteca expandida exigir mais tempo e capacidade do que a família aceita. Reduza a retenção, reclassifique os conteúdos multimédia substituíveis ou simplifique a topologia antes de voltar a expandir.
Regra final de configuração
Uma expansão do Plex só está concluída depois de a capacidade das cópias de segurança, o destino de restauro, as permissões, os caminhos e o tempo de recuperação medido terem sido atualizados e comprovados face à nova topologia.
Configuração de NAS e Servidor
Mais para Ler

Como a análise e a automatização semelhantes à IA alteram as necessidades de armazenamento e computação do Jellyfin
A automatização e a análise de IA associada acrescentam digitalizações, dados derivados, processamento de CPU/GPU, cache, espaço temporário e agendamento em segundo plano, para...

Como integrar o Jellyfin numa rede de um apartamento pequeno ou arrendado
Crie uma rede Jellyfin adequada para arrendamento, com endereçamento local estável, cablagem mínima, hardware silencioso, acesso remoto compatível com CGNAT e alterações reversíveis.

Quantos utilizadores e tarefas em segundo plano deverá suportar um único servidor Jellyfin?
Trate os utilizadores do Jellyfin e as tarefas em segundo plano como uma única capacidade de carga partilhada; a capacidade esgota-se quando a latência...

