Evite perder a configuração do Plex protegendo os dados persistentes da aplicação antes de uma atualização e alterando apenas a camada substituível do contentor.
Num servidor doméstico, o momento de maior risco não é a transferência da imagem, mas sim recriar o Plex com o caminho de configuração errado, uma cópia de segurança não testada ou sem uma referência de reversão utilizável. Comece por confirmar qual é o diretório persistente que o servidor atual utiliza efetivamente e, em seguida, proteja esse estado antes de qualquer alteração destrutiva. Se o contentor atualizado aparecer como um servidor novo, pare imediatamente e verifique o mapeamento, em vez de reconstruir as definições sobre o estado errado.
Separe a configuração do Plex do contentor descartável
Uma imagem de contentor foi concebida para ser substituível, enquanto o estado do Plex que lhe interessa deve sobreviver a essa substituição. Considere o contentor em execução como a camada da aplicação e os respetivos dados persistentes como um objeto de recuperação separado. Se estas duas camadas não estiverem separadas, uma atualização normal pode transformar-se numa reposição acidental.
A parte persistente é mais do que as suas pastas de filmes e séries. O Plex depende do seu diretório de dados e das definições do servidor para conservar a estrutura da biblioteca, os metadados, as preferências e outro estado do servidor, enquanto os ficheiros multimédia podem permanecer intactos num armazenamento separado. Proteger apenas os ficheiros multimédia não protege, portanto, a configuração do Plex de que precisaria para restaurar o mesmo servidor.
Antes de planear a atualização, identifique o diretório do anfitrião ou o volume nomeado que contém este estado persistente. Em muitas configurações de contentores, este é apresentado no Plex como uma montagem de configuração, como /config, mas é a localização no anfitrião que importa para a recuperação. Se não conseguir indicar essa origem com segurança, considere a atualização bloqueada até o conseguir fazer.
Verifique o caminho de configuração atual antes de atualizar
A primeira verificação deve ser observacional, não destrutiva. Abra a definição do contentor, o ficheiro Compose, as definições da aplicação no NAS ou a interface de gestão de contentores e compare a montagem de configuração ativa com a localização no anfitrião que acredita conter o estado do Plex. Faça isto enquanto o servidor conhecido como funcional ainda está em execução, para dispor de uma referência fiável.
Um mapeamento correto deve conduzir à localização preenchida dos dados da aplicação que o servidor atual já utiliza. Uma implementação do Plex em Docker deve manter o estado da aplicação em volumes persistentes para o Plex, para que os dados sobrevivam aos reinícios e às atualizações do contentor. Quando o contentor for implementado novamente, reutilize a origem de configuração verificada no anfitrião, em vez de apontar o Plex para um diretório vazio ou recém-criado.
Se o mapeamento estiver incorreto, for ambíguo ou apontar para uma localização que o Plex não consegue utilizar, pare antes de transferir ou recriar qualquer elemento. Corrija o caminho ou o problema de acesso enquanto o contentor antigo ainda está disponível; em seguida, abra novamente o Plex e confirme que continua a apresentar o servidor esperado. Essa confirmação transforma o mapeamento, que era uma suposição, numa base de referência verificada.
Registe o mapeamento numa captura de ecrã, num modelo de aplicação exportado ou num ficheiro Compose guardado. O objetivo não é documentar por documentar; é eliminar a memória do processo de recuperação. Após uma atualização, deverá conseguir comparar a nova definição do contentor com a versão conhecida como funcional, sem ter de adivinhar qual o caminho no anfitrião ou a definição de permissões que foi alterada.
Crie uma cópia de segurança recuperável antes de alterar a imagem
Assim que o caminho de configuração ativo estiver verificado, copie esse estado persistente do Plex para uma localização de recuperação separada antes de alterar a imagem. A cópia de segurança pode ser um arquivo, um instantâneo acompanhado de uma cópia independente ou outro método suportado pelo seu NAS, mas deve representar o servidor conhecido como funcional, e não um diretório que apenas espera estar correto.
Tenha cuidado com ficheiros de bases de dados ativos. Se o método de cópia simplesmente copiar os dados da aplicação Plex enquanto a base de dados está a ser alterada, pare ou coloque o contentor do Plex num estado inativo primeiro, a menos que a ferramenta disponibilize um instantâneo consistente com a aplicação ou um método ciente da base de dados. Uma cópia rápida que capture uma base de dados inconsistente não é uma cópia de segurança mais segura apenas porque o arquivo foi concluído sem um erro evidente.
Depois de concluir a cópia, inspecione-a independentemente do diretório ativo. Confirme que contém uma estrutura reconhecível de dados da aplicação Plex, registe a respetiva data e tamanho e teste se o arquivo pode ser aberto ou extraído para uma localização temporária. Se a cópia de segurança não puder ser lida corretamente, corrija o processo de cópia antes de alterar o contentor funcional.
Mantenha a cópia anterior à atualização separada do caminho dos dados ativos da aplicação. Uma cópia de segurança guardada dentro da mesma árvore de diretórios que está prestes a remapear ou limpar pode desaparecer juntamente com a origem que deveria proteger. O objetivo imediato é garantir a recuperação de um erro de atualização; a proteção contra falhas mais abrangentes do disco pode seguir a política habitual de cópias de segurança do seu NAS.
Guarde a definição do contentor e a referência da última imagem funcional
Os dados de configuração são apenas metade de uma reversão útil. Preserve também a definição atual do contentor: referência da imagem, mapeamentos de volumes, valores de ambiente relevantes, modo de rede, mapeamentos de dispositivos e qualquer outra definição difícil de reconstruir de memória. Um ficheiro Compose ou um modelo de aplicação exportado do NAS é mais fiável do que uma reconstrução manual depois de algo falhar.
Registe a última imagem funcional com uma etiqueta versionada, um resumo ou outra referência resolúvel antes de depender de uma etiqueta flutuante como latest. Uma reversão é muito mais difícil quando sabe que ontem funcionava, mas não consegue identificar qual a imagem utilizada ontem. Preservar os dados da aplicação, a definição do contentor e uma referência específica da imagem transforma a configuração atual num ponto de recuperação reproduzível.
Não elimine a imagem anterior nem apague a definição de implementação guardada antes de verificar a atualização. Se o novo contentor falhar por motivos não relacionados com o caminho de configuração, deverá conseguir recriar o ambiente de execução anterior sem alterar os dados protegidos da aplicação. Assim, a reversão mantém-se centrada na camada de software, em vez de misturar a recuperação com uma nova migração de configuração.
Atualize sem alterar o limite do estado persistente
Com a cópia de segurança e o contexto de reversão preparados, substitua ou atualize a imagem do Plex mantendo inalterado o mapeamento da configuração persistente verificado. Reutilizar o mesmo volume persistente ao substituir a imagem do contentor é o que mantém os dados da aplicação fora da camada descartável do contentor. Mantenha também estáveis os caminhos dos ficheiros multimédia e outras montagens conhecidas como funcionais, salvo se o objetivo da manutenção for explicitamente migrá-los.
O resultado esperado é simples: o contentor atualizado inicia utilizando o mesmo estado persistente de /config e o Plex regressa como o servidor existente. Se o mapeamento for preservado, o novo contentor poderá reutilizar a base de dados da biblioteca, as definições e os metadados armazenados, em vez de tratar a implementação como uma primeira instalação. Este é o estado que deverá verificar antes de efetuar novas alterações de configuração.
Se, em vez disso, o Plex apresentar uma configuração inicial, uma biblioteca vazia ou um fluxo de associação, não comece imediatamente a reconstruir o servidor. Pare o novo contentor e compare o respetivo mapeamento de configuração com a definição conhecida como funcional. Um servidor com aspeto novo após a substituição de um contentor é motivo para verificar primeiro a persistência, pois configurar o estado errado pode tornar o caminho de recuperação menos claro.
Se o mapeamento estiver correto, mas a nova imagem continuar a falhar, utilize a referência da imagem e a definição de implementação guardadas para regressar ao último contentor funcional, mantendo os dados protegidos da aplicação no lugar. Se os próprios dados da aplicação parecerem danificados, restaure-os a partir da cópia anterior à atualização, em vez de experimentar na sua única cópia de segurança conhecida como funcional.
Verifique o servidor atualizado antes de remover a cópia de reversão
Um contentor que inicia ainda não representa uma atualização verificada. Compare o servidor atualizado com a base de referência registada antes da manutenção: confirme a identidade esperada do servidor, as bibliotecas, as definições importantes, os caminhos dos ficheiros multimédia e, pelo menos, uma sessão de reprodução representativa. Se alguma destas verificações apresentar diferenças, investigue antes de eliminar os recursos de recuperação.
Mantenha a cópia de segurança dos dados da aplicação anterior à atualização e a referência da última imagem funcional até provar que a recuperação é possível, e não apenas que a nova versão inicia. Um teste de restauro ajuda a confirmar que a cópia de segurança pode transformar-se num caminho de recuperação utilizável, mesmo que o teste se limite a extrair o arquivo ou a restaurar uma cópia para uma localização temporária sem afetar o ambiente de produção.
Quando o servidor atualizado corresponder à base de referência e o pacote de recuperação continuar utilizável, poderá considerar concluída a janela de manutenção. Conserve ou alterne a cópia de segurança de acordo com a sua política habitual, em vez de a eliminar imediatamente apenas porque a atualização funcionou uma vez. Assim, terá margem para lidar com problemas que só surjam depois de as tarefas agendadas, as análises das bibliotecas ou a utilização normal da casa serem retomadas.
Utilize o mesmo procedimento de proteção para futuras alterações que possam substituir ou reinterpretar o estado do Plex: uma atualização da imagem do contentor, uma migração para outro anfitrião, uma alteração do caminho de configuração, uma mudança importante de permissões ou uma alteração do armazenamento dos dados da aplicação. Volte a verificar o mapeamento persistente, crie um novo ponto de recuperação, preserve o contexto de reversão e verifique o resultado antes da limpeza. A rotina está associada a alterações disruptivas, não a um intervalo de calendário arbitrário.
Suporte e Dicas
Mais para Ler

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

