Uma disposição de armazenamento do Plex torna-se um risco para a recuperação quando o estado ativo, os conteúdos multimédia, as cópias de segurança e o trabalho temporário partilham percursos de falha que não podem ser restaurados de forma independente.
O desempenho pode parecer normal enquanto a capacidade de recuperação se degrada silenciosamente. Os sinais de alerta incluem a propriedade pouco clara dos dados da aplicação, cópias de segurança no mesmo dispositivo que a base de dados ativa, pontos de montagem não documentados e diretórios temporários misturados com o estado persistente. Audite a função de cada caminho antes de uma falha o obrigar a descobri-la sob pressão.
O estado ativo e as cópias de segurança partilham o mesmo domínio de falha
Um instantâneo junto à base de dados ativa pode ajudar em caso de erros da aplicação, mas não protege contra a perda do dispositivo ou a corrupção do conjunto de armazenamento. Pelo menos uma cópia de recuperação deve atravessar uma fronteira física ou administrativa.
A capacidade e a rotatividade reais das cópias de segurança devem ser planeadas separadamente do dispositivo que contém o estado ativo, em vez de serem tratadas como espaço livre no mesmo conjunto.
Rastreie o local físico de cada cópia de segurança do Plex. Se uma falha num disco ou conjunto remover tanto o estado ativo como todas as cópias, mova uma camada antes de adicionar mais retenção.
Os dados da aplicação e o trabalho temporário estão misturados
A cache e o resultado da transcodificação podem ser recriados, enquanto a base de dados e os metadados definem o servidor. Misturá-los complica o tamanho das cópias de segurança e torna perigosa a limpeza de emergência.
O armazenamento de metadados do Plex pertence ao estado persistente do servidor, que não deve ser tratado como espaço descartável para transcodificação.
Identifique cada montagem do Plex como estado persistente, conteúdos multimédia, cache recriável, trabalho temporário ou cópia de segurança. Se um caminho contiver várias funções, separe-as antes da próxima migração.
As montagens dependem de nomes ou identidades não documentados
Uma disposição de armazenamento é frágil quando uma restauração depende de se memorizar um caminho no anfitrião, um UID de contentor ou um link simbólico criado manualmente. Esses pressupostos ocultos falham durante uma substituição.
O mapeamento estável de UID e GID do contentor impede que uma montagem vinculada restaurada se torne inesperadamente apenas de leitura num novo anfitrião.
Recrie o mapa de montagens apenas com base na documentação, utilizando um contentor descartável. Qualquer passo que tenha de redescobrir deve fazer parte do procedimento de recuperação. Funções de armazenamento claras para o centro multimédia facilitam perceber quando o estado da base de dados, os conteúdos multimédia em massa e as cópias de segurança foram concentrados no mesmo domínio de falha.
Ninguém cronometrou uma restauração
Uma disposição pode estar logicamente correta, mas ainda assim não cumprir o tempo de inatividade aceitável, porque as montagens dos conteúdos multimédia, as permissões ou as cópias da base de dados demoram demasiado tempo a reconstruir.
Os testes regulares de restauração transformam o desenho do armazenamento num percurso de recuperação medido, em vez de num simples diagrama.
Cronometre uma restauração limpa com a disposição atual e registe o passo mais demorado. Se a recuperação já não couber na janela disponível, simplifique os caminhos ou separe o estado antes de adicionar capacidade.
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»...

