Como testar a aceitação de um novo servidor Plex antes de transferir os dados de produção

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Mova os dados de produção do Plex apenas depois de um teste de aceitação a partir de um arranque a frio comprovar que o estado, os caminhos, os utilizadores, a reprodução e a recuperação funcionam no novo anfitrião.

Mantenha o servidor antigo parado e inalterado enquanto testa o novo anfitrião segundo o mesmo fluxo de trabalho doméstico. A dependência essencial não é um início de sessão bem-sucedido; é um percurso repetível desde a montagem do armazenamento até à base de dados da biblioteca e à reprodução no cliente. Trate o acesso remoto como uma etapa independente e mantenha uma cópia para reversão até localizar e testar uma cópia de segurança recente.

Congele o servidor antigo e defina o percurso de aceitação

Comece com o anfitrião antigo parado, uma cópia de segurança dos dados da aplicação e uma lista escrita das bibliotecas, dos utilizadores, dos clientes remotos e das tarefas agendadas. Isto impede que duas identidades de servidor alterem o mesmo fluxo de trabalho enquanto compara os resultados. Um guia independente de migração também recomenda manter uma cópia para reversão ao mover a biblioteca e os metadados (guia de migração da biblioteca do Plex). Conclua esta etapa apenas quando conseguir indicar a localização dos dados antigos, a localização dos dados novos e a ação de restauro.

Valide os caminhos de armazenamento, a propriedade e o estado da aplicação

Para cada biblioteca, abra o caminho a partir do anfitrião do Plex, em vez de utilizar um explorador de ficheiros na sua estação de trabalho. Verifique se a montagem está presente após o reinício, se a conta de serviço consegue ler os conteúdos multimédia e se o diretório de dados da aplicação tem permissões de escrita e é persistente. Teste um ficheiro de cada localização de armazenamento. Mantenha o estado do sistema, a base de dados do Plex, os conteúdos multimédia insubstituíveis, as miniaturas que podem ser recriadas e as cópias de segurança como funções de dados distintas; a redundância não é uma cópia de segurança.

Um caminho que só funciona porque foi montado manualmente representa uma migração falhada. A decisão de saída é PASS quando todas as bibliotecas são resolvidas a partir do contexto do serviço e a base de dados sobrevive a um reinício do serviço sem que uma nova análise destrua o estado.

Teste a reprodução em todo o conjunto real de clientes

Utilize uma pequena matriz em vez de um único filme reproduzido com sucesso: um ficheiro em reprodução direta, um ficheiro que normalmente é transcodificado, um conteúdo com muitas legendas, uma sessão remota se a visualização remota fizer parte do fluxo de trabalho e uma conta com acesso restrito à biblioteca. Registe a hora de início, o modo de reprodução, o comportamento do áudio e das legendas e se o utilizador esperado vê a biblioteca esperada. O novo servidor não está pronto se a reprodução só funcionar na conta de administrador ou apenas na rede local.

-15% OFF

Execute as etapas de reinício a frio e de reversão

Pare o Plex corretamente, reinicie o anfitrião, aguarde pelas montagens do armazenamento e da rede e repita os testes representativos de reprodução e de acesso dos utilizadores. Crie uma cópia de segurança recente dos dados da aplicação após o reinício e verifique onde pode ser restaurada. Um procedimento prático semelhante para mover metadados mantém o diretório antigo com outro nome até a nova localização ser confirmada (prática de reversão de metadados).

Desative o anfitrião antigo apenas quando todas as etapas forem aprovadas duas vezes: estado e caminhos, reprodução representativa, utilizadores previstos, reinício a frio e localização da cópia de segurança. Se alguma etapa falhar, corrija o novo anfitrião enquanto a cópia antiga permanece disponível; não amplie a alteração eliminando o objetivo de reversão.

Utilize um limite de paragem mensurável

Pare a migração quando o novo anfitrião tiver passado a matriz de aceitação e o próximo critério de expansão for conhecido, como mais transcodificações simultâneas ou um nível de armazenamento que já não seja suficiente. Mantenha o anfitrião antigo enquanto as permissões, a persistência das montagens, o encaminhamento remoto ou a recuperação não tiverem sido demonstrados. A migração segura mais económica é aquela que mantém um caminho de recuperação conhecido.

Configuração de NAS e Servidor

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.