Uma cópia de segurança do Plex só está comprovada quando uma instância limpa consegue reconstruir, a partir dessa cópia, o estado do servidor, as permissões, as bibliotecas e uma reprodução representativa.
A contagem de ficheiros e os trabalhos de cópia concluídos com sucesso não são testes de restauro. Utilize um ambiente de execução isolado, caminhos de multimédia duplicados ou apenas de leitura e propriedade documentada, para que a recuperação não dependa de elementos ocultos da produção. Teste tanto um ponto recente como um ponto mais antigo quando a retenção se destina a proteger contra falhas detetadas tardiamente.
Comece com um Ambiente de Execução Limpo
Um teste de restauro deve começar sem o contentor ativo, a base de dados ou o caminho de metadados montados. Caso contrário, o teste pode ser bem-sucedido porque o estado de produção continua disponível.
Um teste de restauro independente valida uma cópia de segurança reconstruindo um serviço utilizável, em vez de confirmar apenas que existe um arquivo.
Crie um contentor ou anfitrião descartável e associe apenas a cópia de segurança copiada, juntamente com acesso não destrutivo aos suportes multimédia. Registe todos os passos manuais necessários para chegar à página de início de sessão.
Verifique a Identidade, as Bibliotecas e as Permissões
O servidor pode iniciar-se mesmo tendo perdido as relações entre bibliotecas, as políticas das contas ou as permissões de escrita. Inclua estes comportamentos no teste de aceitação.
O mapeamento correto de UID e GID é necessário quando um restauro em contentor transfere o estado para um anfitrião com uma propriedade diferente.
Abra bibliotecas representativas, faça uma alteração de estado inofensiva e verifique contas restritas e não restritas. Corrija o procedimento de recuperação em vez de aplicar permissões root não documentadas.
Teste Mais do que a Cópia Mais Recente
A cópia de segurança mais recente pode ter sido criada depois de uma corrupção silenciosa ou de uma atualização defeituosa. A retenção só é útil quando também é possível selecionar e restaurar um ponto mais antigo conhecido como íntegro.
Um histórico de cópias de segurança útil preserva pontos de recuperação conhecidos como íntegros anteriores à entrada da falha no sistema.
Restaure um ponto recente e um ponto mais antigo segundo um calendário. Se apenas a cópia mais recente for testada, o nível de retenção mais antigo ainda não está comprovado. Uma topologia de servidor multimédia doméstico documentada deve esclarecer o destino do restauro, o caminho dos suportes multimédia e o domínio de falha da cópia de segurança antes de um incidente real.
Meça o Tempo de Recuperação
Um restauro tecnicamente bem-sucedido pode ainda não cumprir o objetivo de tempo de indisponibilidade da casa. Cronometre o processo e identifique o passo manual ou de armazenamento mais demorado.
Muitas migrações de anfitrião são bem-sucedidas ou falham devido à migração do estado, sobretudo quando os dados da aplicação e os caminhos de montagem têm de permanecer consistentes.
Registe o tempo desde um ambiente de execução vazio até à reprodução validada. Repita o processo depois de alterar a disposição do armazenamento, as permissões ou as ferramentas de cópia de segurança, para que a estimativa continue credível.
Suporte e Dicas
Mais para Ler

Deve fazer uma cópia de segurança do Jellyfin em funcionamento ou parar primeiro o serviço?
Prefira cópias de segurança com o serviço parado, pela sua simplicidade; utilize instantâneos em funcionamento apenas quando o estado da aplicação for capturado de...

Porque é que o Jellyfin funciona a altas temperaturas ou faz ruído quando ninguém está a transmitir?
O calor em inatividade normalmente indica atividade em segundo plano ou uma carga de trabalho de um anfitrião partilhado; por isso, identifique o processo...

Quando deve reconstruir em vez de reparar o Jellyfin?
Escolha recriar em vez de reparar quando o problema for a divergência do ambiente de execução e o estado persistente estiver salvaguardado; não «recrie»...

