Como verificar uma restauração do Jellyfin antes de desativar o servidor antigo

Não desative o servidor Jellyfin antigo até que um restauro limpo reproduza os utilizadores, caminhos, reprodução, permissões e comportamento de reinício necessários.

A nova instância limita-se a abrir o painel de controlo ou resistiu à mesma carga de clientes e armazenamento que o anfitrião antigo? Mantenha o servidor antigo parado e recuperável enquanto testa. Um início de sessão bem-sucedido é apenas o primeiro sinal; o restauro tem de comprovar o estado e os caminhos de dados que o agregado familiar utiliza efetivamente.

Verifique o estado persistente antes da reprodução

Confirme que a configuração e a base de dados restauradas contêm os utilizadores, bibliotecas, estado de visualização, plug-ins e permissões esperados. Verifique cada caminho de biblioteca a partir do contexto do serviço Jellyfin e leia um ficheiro de amostra de cada localização de armazenamento. Montagens em falta ou propriedade incorreta podem permanecer ocultas até uma análise ou um pedido de reprodução.

Registe o que foi reconstruído intencionalmente, como a cache ou o grafismo transferido, para que uma diferença não seja confundida com um restauro falhado. Mantenha a cópia de segurança e a cópia antiga dos dados da aplicação inalteradas até à próxima etapa.

Compare o número de itens restaurados e um registo conhecido do estado de visualização com o último inventário do servidor antigo. Um arranque bem-sucedido da base de dados não prova que todos os caminhos de multimédia ou permissões de utilizador tenham sido preservados.

Execute a carga de trabalho original dos clientes

Teste uma reprodução local em Direct Play, uma transcodificação forçada, legendas, acesso remoto se for utilizado e uma conta de utilizador restrita. Compare o modo de reprodução, o áudio, a apresentação das legendas, a visibilidade das bibliotecas e o tempo de arranque com o comportamento conhecido do servidor antigo.

Se apenas um cliente falhar, isole a respetiva capacidade ou caminho antes de alterar todo o restauro. O processo de migração é útil como lista de verificação, mas a decisão de aceitação deve basear-se na carga de trabalho do seu próprio agregado familiar.

Repita uma sessão depois de o serviço estar em execução durante tempo suficiente para concluir as tarefas normais de arranque. Isto deteta falhas tardias de montagem, plug-ins ou metadados que um início de sessão rápido não revela.

Supere as etapas de reinício a frio e recuperação

Pare o Jellyfin, reinicie o anfitrião, aguarde pelas montagens de armazenamento e pelos serviços de rede e repita os mesmos testes dos clientes. Crie ou localize uma cópia de segurança recente do estado restaurado da aplicação. Em seguida, execute um segundo teste de restauro ou, pelo menos, verifique se a cópia de segurança contém o diretório de dados exato e as permissões necessárias para a recuperação.

Desative o servidor antigo apenas quando o anfitrião restaurado passar duas vezes nas verificações de estado, caminhos, utilizadores, reprodução, reinício a frio e localização da cópia de segurança. Pare e reverta quando a base de dados não puder ser aberta, a carga de trabalho original dos clientes falhar ou a cópia de recuperação não puder ser lida de forma independente.

Registe o ponto de restauro exato, a propriedade dos ficheiros e o mapeamento dos caminhos que foram aprovados. Esses detalhes tornam-se o procedimento de recuperação caso o novo anfitrião falhe durante a janela de desativação.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Feche a janela de desativação em segurança

Deixe o servidor antigo parado, mas recuperável, até que o anfitrião restaurado passe um segundo teste de arranque a frio e seja possível localizar de forma independente uma cópia de segurança recente.

Desative o anfitrião antigo apenas depois de a reprodução local, a reprodução remota se necessária, o acesso dos utilizadores, as análises das bibliotecas e a documentação de restauro serem todos aprovados. Mantenha os dados antigos da aplicação até terminar o período de retenção.

Pare e reverta quando qualquer cliente necessário falhar, a base de dados restaurada sofrer alterações inesperadas ou a cópia de segurança não conseguir reproduzir o estado testado.