Cópias de segurança integradas do Jellyfin vs. cópias de segurança ao nível dos ficheiros: qual deve utilizar?

As cópias de segurança integradas do Jellyfin e as cópias de segurança ao nível dos ficheiros protegem âmbitos de recuperação sobrepostos, mas diferentes. O sistema integrado compreende os dados da aplicação Jellyfin e pode criar um arquivo enquanto o servidor permanece online. Uma cópia de segurança manual ao nível dos ficheiros pode captar um estado de implementação mais abrangente, mas o Jellyfin tem de ser parado antes de os dados ativos da aplicação serem copiados em segurança.

O melhor plano muitas vezes não é escolher entre uma opção ou outra. Utilize o método integrado para obter pontos de recuperação frequentes da aplicação e um método ao nível dos ficheiros ou do sistema de ficheiros, com o servidor parado, quando precisar de reproduzir caminhos do anfitrião, configuração, definições de contentores ou um estado mais abrangente do servidor.

As Cópias de Segurança Integradas São Melhores para Pontos de Recuperação Online de Rotina

O sistema atual de cópias de segurança do Jellyfin pode proteger a base de dados e incluir opcionalmente metadados, legendas e dados de trickplay enquanto o servidor está em execução. Isto torna-o prático para pontos de recuperação agendados, sem interromper intencionalmente a reprodução normal.

A documentação de cópias de segurança do Jellyfin afirma que as cópias de segurança integradas podem ser executadas online, enquanto as cópias de segurança manuais do diretório de dados exigem que o servidor seja parado. Mesmo o método online deve ser executado, de preferência, durante períodos de menor atividade e sem uma análise da biblioteca a decorrer em simultâneo.

Esta é a melhor opção predefinida quando o objetivo da recuperação é “devolver esta instância do Jellyfin a um estado de aplicação conhecido”.

As Cópias de Segurança ao Nível dos Ficheiros São Melhores Quando o Âmbito de Recuperação Inclui a Estrutura do Anfitrião

Uma cópia ao nível dos ficheiros pode incluir pastas persistentes da aplicação, ficheiros Compose, ficheiros de ambiente, configuração do proxy inverso, unidades de serviço, scripts, certificados e outros recursos de implementação que um arquivo exclusivo do Jellyfin não conhece automaticamente.

Este âmbito mais abrangente é útil em caso de falha do disco do sistema ou de migração para um anfitrião de substituição. A desvantagem é a consistência: as ferramentas comuns de cópia de ficheiros não compreendem uma base de dados SQLite em alteração, por isso deve parar o Jellyfin corretamente antes de copiar o respetivo estado persistente ativo.

O guia da ZimaSpace sobre estruturas de armazenamento do Jellyfin que representam um risco de recuperação destaca o mesmo problema: uma cópia de segurança fica incompleta quando ninguém consegue reproduzir os caminhos, montagens, permissões e dependências externas necessários para o servidor restaurado.

Uma Cópia de Segurança Sensível à Base de Dados É Diferente de Copiar um Ficheiro SQLite Ativo

O SQLite permite realizar cópias de segurança online consistentes através de interfaces sensíveis à base de dados, mas uma ferramenta de cópia genérica que lê ficheiros enquanto o Jellyfin os altera não recebe automaticamente a mesma garantia.

A API de cópia de segurança do SQLite foi concebida para copiar uma base de dados ativa para um destino consistente através de operações de base de dados coordenadas. É por isso que “os ficheiros foram copiados sem erros” não constitui prova suficiente para uma cópia de segurança manual ativa do Jellyfin.

Se o seu método manual consistir apenas em rsync, cópia SMB, zip ou numa cópia genérica do sistema de ficheiros, pare primeiro o Jellyfin, a menos que o instantâneo de armazenamento seja coordenado com as escritas da aplicação.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Compare o Âmbito Antes de Comparar a Conveniência

Mantenha a Cópia de Segurança Fora do Domínio de Falha Ativo do Jellyfin

Nenhum dos métodos protege contra a perda do conjunto de armazenamento quando todas as cópias de segurança se encontram no mesmo sistema de ficheiros que falhou. Copie os arquivos de cópia de segurança verificados ou os conjuntos de recuperação criados com o servidor parado para outro disco, NAS ou localização externa.

Guarde pelo menos um ponto anterior à atualização, porque o Jellyfin aplica migrações de dados quando é iniciada uma versão mais recente e não disponibiliza um método geral de reversão no local.

Teste ambos os estilos de restauro se fizerem parte do plano de recuperação. Um arquivo integrado comprova a recuperação da aplicação; um teste ao nível dos ficheiros comprova que o ambiente consegue recriar os caminhos persistentes e as permissões associadas.

Perguntas Frequentes

Devo parar o Jellyfin antes de utilizar a cópia de segurança integrada?

Não. O método integrado foi concebido para funcionar enquanto o Jellyfin está em execução, embora seja recomendável haver pouca atividade e nenhuma análise ativa da biblioteca. Pare o servidor para uma cópia manual normal dos dados ativos do Jellyfin.

A cópia de segurança integrada pode substituir a cópia de segurança do meu anfitrião?

Nem sempre. Protege o estado da aplicação Jellyfin, mas uma recuperação completa do anfitrião também pode depender de ficheiros Compose, definições do proxy, certificados, montagens, permissões, scripts e outra configuração externa.