Planeie em conjunto a recuperação e a expansão do Plex, separando o estado da aplicação, os conteúdos multimédia, as cópias de segurança, os destinos de restauro e os critérios de expansão antes da primeira alteração de capacidade.
Uma cópia de segurança só é útil se permitir recriar o serviço prometido, e a expansão só é segura se esse processo de recuperação continuar a funcionar depois. Defina o que tem de ser reposto, que perda de dados é aceitável e quanto tempo a família pode esperar. Em seguida, 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 restauro e ao armazenamento futuro, para que possam ser testados após cada migração ou atualização.
Defina o compromisso 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, a avaria de um disco com conteúdos multimédia ou a perda do servidor. A resposta pode variar consoante a categoria de dados. As preferências do Plex, os utilizadores, o histórico de visualização, os cartazes personalizados e as definições de automatização podem ser difíceis de reconstruir, mesmo que os ficheiros multimédia continuem disponíveis. As gravações pessoais podem ser insubstituíveis, enquanto os conteúdos multimédia comerciais poderão ser recuperados de outra origem.
Defina uma antiguidade máxima aceitável para cada cópia recuperável e um tempo máximo para repor o serviço essencial. São compromissos operacionais, não siglas abstratas. Se for aceitável perder um dia do histórico de visualização, mas não um vídeo de família, estas duas categorias não devem partilhar a mesma frequência nem o mesmo destino de cópia de segurança. Se a família puder esperar um fim de semana pela recuperação completa dos conteúdos multimédia, não dimensione todos os componentes para uma recuperação instantânea.
A disposição inicial do armazenamento só está concluída quando cada compromisso tem um responsável, uma cópia, uma ação de restauro e um destino para o restauro. Um plano que identifica ficheiros de cópia de segurança, mas não prevê um destino temporário para a recuperação, está incompleto. Um plano que pressupõe que o conjunto de discos principal continuará disponível não cobre uma falha desse conjunto.
Separe o estado do Plex da capacidade de armazenamento multimédia
Mantenha a base de dados do Plex, os metadados, as preferências e a configuração do serviço numa localização persistente claramente identificada. Guarde os conteúdos multimédia num nível de capacidade próprio. 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 grandes dimensões nunca seja confundida com uma recuperação completa do servidor.
Esta separação encurta a primeira etapa de recuperação. Pode restaurar uma cópia pequena e consistente do estado da aplicação num serviço isolado, associar um subconjunto representativo de 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 oculte a possibilidade de recuperar a base de dados, as permissões ou as montagens dos contentores.
Registe a propriedade, os identificadores, os pontos de montagem e as expectativas relativas aos caminhos, juntamente com a função dos dados. Uma base de dados restaurada que aponta para um caminho de conteúdos multimédia diferente pode estar intacta, mas ser inutilizável. Uma pasta de contentor copiada com a identidade de serviço errada pode iniciar-se 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.
Associe um caminho de recuperação diferente a cada falha
Use o sistema principal para executar o serviço, um destino de cópia de segurança separado para uma recuperação local rápida e um domínio de falha distinto para os dados cuja perda seria inaceitável. O terceiro local pode ser um armazenamento externo, espaço na cloud encriptado ou suportes rotativos guardados noutro sítio. O essencial é a independência: uma falha de energia, uma conta comprometida, uma eliminação acidental ou uma avaria do controlador de armazenamento não deve afetar todas as cópias pelo mesmo caminho.
Aplique uma política de retenção de versões ao estado pequeno e frequentemente alterado do Plex, para que uma atualização mal-sucedida ou um problema na base de dados não substitua a última cópia utilizável. Proteja os conteúdos multimédia insubstituíveis com a quantidade de cópias necessária em caso de 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 caminhos 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 êxito, mas cujos dados não podem ser desencriptados, montados ou associados ao caminho esperado, não cumpriu a promessa de recuperação.
Ensaie o restauro antes de a expansão alterar os caminhos
Restaure o estado do Plex para um contentor isolado, uma máquina virtual, um servidor de reserva ou um diretório temporário que não possa escrever na biblioteca de produção. Sempre que possível, use a mesma identidade de serviço e a mesma estrutura de caminhos. Adicione uma pequena amostra de conteúdos multimédia e confirme que a base de dados abre, que as bibliotecas são apresentadas, que as permissões funcionam, que a reprodução começa e que as preferências ou o histórico essenciais estão presentes.
Cronometre o ensaio a partir de um destino vazio, incluindo a obtenção das credenciais, a localização da cópia de segurança 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 taxa de transferência estimada, porque a recuperação costuma ficar à espera de decisões sobre os caminhos e de notas em falta, e não da velocidade bruta de transferência 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 processo de recuperação.
Atualize o orçamento das cópias de segurança a 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 como uma simples atualização da capacidade. Recalcule a quantidade de dados que tem de ser protegida, quanto tempo demorará a cópia de segurança, de quanto espaço livre o destino precisa e onde poderá ser recuperada uma cópia equivalente. Atualize os caminhos de montagem, as permissões, a monitorização e o inventário antes de transferir os dados de produção.
Implemente a alteração por etapas, mantendo disponível o percurso de recuperação anterior até o novo estar validado. Copie ou replique os dados, valide as contagens e os ficheiros representativos, altere um caminho e, em seguida, verifique o Plex e as cópias de segurança antes de desativar a localização antiga. 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 se o destino das cópias de segurança não conseguir acomodar o novo conjunto protegido, se o destino de restauro já não tiver espaço suficiente ou se o tempo de recuperação medido exceder o prazo prometido à família. Acrescente capacidade de proteção ou reduza o prazo prometido para a recuperação antes de o novo armazenamento se tornar a única cópia de produção.
Use as provas de recuperação para decidir quando separar as funções
Separe a capacidade de computação do armazenamento multimédia quando a substituição do servidor ou a manutenção da aplicação estiver a ser adiada devido ao tamanho da biblioteca ou à forma como está ligada. Acrescente um destino de cópia de segurança dedicado quando o sistema principal já não conseguir conter as cópias de produção e de recuperação sem partilharem um mesmo ponto de falha. Acrescente capacidade de rede quando as janelas medidas para cópias de segurança e restauro forem limitadas pela ligação e não pelos discos em qualquer uma das extremidades.
Use 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 períodos de pico como critérios para expandir. Um novo componente tem de melhorar um desses limites medidos e preservar os restantes. Se acrescentar um segundo espaço de armazenamento, credenciais não documentadas ou uma nova dependência de montagem sem melhorar a garantia de recuperação, está a aumentar a complexidade, não a resiliência.
Pare se a pessoa que deverá recuperar o sistema não conseguir ensaiar o processo, se todas as cópias dependerem da mesma conta de administrador ou se proteger a biblioteca expandida consumir mais tempo e capacidade do que a família aceita. Reduza o período de retenção, reclassifique os ficheiros multimédia que podem ser substituídos ou simplifique a topologia antes de voltar a expandir.
Regra final de configuração
A expansão do Plex só está concluída quando a capacidade de cópia de segurança, o destino de restauro, as permissões, os caminhos e o tempo de recuperação medido tiverem sido atualizados e validados em função da nova topologia.
Configuração de NAS e servidor
Mais para ler

Um servidor no dormitório pode funcionar silenciosamente o suficiente para dormir, estudar e fazer videochamadas?
Sim - um servidor num dormitório pode passar despercebido se o hardware consumir pouca energia, as vibrações do armazenamento forem controladas, as tarefas mais...

Um homelab de estudante que pode passar do quarto da residência universitária para o primeiro apartamento
Mantenha um homelab de estudante portátil, separando os serviços da rede específica de cada divisão, minimizando o hardware, criando cópias de segurança do estado...

Como partilhar um servidor doméstico com colegas de casa sem partilhar contas nem ficheiros privados
Dê a cada pessoa que partilha a casa uma identidade própria, armazenamento privado e apenas os privilégios partilhados de que precisa; mantenha a administração,...



