Deve fazer uma cópia de segurança do Plex em funcionamento ou parar primeiro o serviço?

Para uma cópia normal, ao nível dos ficheiros, dos dados da aplicação Plex, pare ou coloque primeiro o Plex em estado quiescente. Uma cópia em execução só é adequada quando o método de cópia foi concebido para capturar uma base de dados em execução de forma consistente e o restante estado do Plex está protegido com semântica compatível.

A escolha não é propriamente entre “tempo de inatividade e ausência de tempo de inatividade”. É entre uma “cópia simples e consistente” e um método em execução que compreenda as escritas ativas na base de dados. Se não conseguir explicar de que forma o método em execução preserva uma base de dados Plex válida num determinado momento, agende uma breve paragem e verifique a cópia de segurança, em vez de presumir que é seguro copiar ficheiros abertos.

Escolha o método de cópia de segurança antes de escolher o tempo de inatividade

Comece por identificar a primitiva de cópia de segurança. Um tar, rsync, uma cópia SMB, um cliente de sincronização na nuvem ou um instantâneo genérico de ficheiros ativos comportam-se de forma diferente de um comando de cópia de segurança com conhecimento da base de dados. O estado operacional seguro depende do que a ferramenta consegue garantir, não de a cópia terminar com êxito.

Os dados da aplicação Plex contêm bases de dados, bem como metadados e configuração que podem ser alterados enquanto o servidor está em execução. Uma visão geral das cópias de segurança do Plex observa que o diretório de dados do Plex contém metadados e bases de dados, pelo que proteger o servidor é mais abrangente do que guardar apenas os ficheiros multimédia.

Para esta decisão, considere uma cópia simples do sistema de ficheiros como o caso mais conservador e uma cópia de segurança da base de dados com conhecimento da aplicação como uma técnica separada. Não considere uma cópia em execução segura apenas porque o destino recebe ficheiros com os nomes e tamanhos esperados.

Pare o Plex para fazer uma cópia simples dos dados da aplicação ao nível dos ficheiros

Se a sua tarefa de cópia de segurança se limita a copiar o diretório de dados da aplicação Plex, a predefinição mais segura é parar o serviço ou contentor Plex durante a janela de cópia. Isso elimina as escritas simultâneas da aplicação enquanto a base de dados e o estado relacionado são capturados.

Numa discussão da comunidade Plex, um colaborador técnico de longa data alerta que uma cópia normal de ficheiros em execução pode capturar uma base de dados inconsistente e distingue os ficheiros de metadados estáticos da base de dados aberta. Isto constitui um forte argumento a favor de colocar o Plex em estado quiescente quando a ferramenta de cópia de segurança não dispõe de um mecanismo de consistência da base de dados.

Mantenha a paragem tão curta quanto possível: confirme que não está a decorrer nenhuma análise ou gravação crítica, pare o Plex, execute a cópia preparada, verifique se a tarefa foi concluída e volte a iniciar o Plex. Não desperdice o tempo de inatividade a descobrir problemas de permissões no destino ou de espaço livre que poderiam ter sido verificados antecipadamente.

Utilize uma cópia de segurança em execução apenas quando o método da base de dados o permitir

Parar o Plex não é uma exigência da própria SQLite. Uma cópia de segurança em execução pode ser válida quando o método utiliza funcionalidades compatíveis com SQLite que criam um instantâneo consistente da base de dados enquanto o acesso normal da aplicação continua.

Uma análise sobre cópias de segurança de SQLite em produção explica que a API de cópia de segurança do SQLite pode copiar uma base de dados em execução enquanto outras ligações continuam a escrever; a cópia de segurança representa um estado definido da base de dados, em vez de ser uma cópia cega de ficheiros em alteração.

Essa exceção abrange apenas aquilo que o método com conhecimento da aplicação protege efetivamente. Se o seu fluxo de trabalho utilizar uma cópia de segurança SQLite em execução para a base de dados, mas copiar separadamente os metadados e as preferências, documente de que forma esses componentes ficam alinhados no tempo e teste uma restauração. A elevada disponibilidade não é útil se o artefacto combinado não conseguir recriar o estado do servidor esperado.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Faça uma cópia de segurança de mais do que o ficheiro da base de dados

Uma cópia de segurança apenas da base de dados pode preservar registos importantes da biblioteca, mas uma recuperação completa do Plex também pode depender de metadados, preferências, dados de plug-ins, certificados e definições específicas da plataforma. Decida de quais desses elementos precisaria se o anfitrião original desaparecesse, em vez de fazer uma cópia de segurança apenas do ficheiro mais fácil.

Mantenha a proteção dos ficheiros multimédia como uma decisão de capacidade separada. A configuração do Plex pode ocupar gigabytes, enquanto a biblioteca multimédia pode ocupar terabytes, e esses conjuntos de dados precisam frequentemente de calendários e destinos de cópia de segurança diferentes. Um pequeno arquivo de dados da aplicação não deve criar a ilusão de que os filmes ou os conteúdos multimédia da família estão protegidos.

O guia da ZimaSpace sobre cópias de segurança consistentes de contentores de bases de dados é uma continuação útil quando precisa de coordenar dados da aplicação, o estado da base de dados, volumes persistentes e um teste de restauração em execução num conjunto de serviços de servidor doméstico.

Verifique a cópia de segurança antes de confiar em qualquer um dos métodos

Qualquer que seja o método escolhido, inspecione a cópia de segurança fora do diretório Plex em execução. Confirme que os ficheiros esperados existem, registe a data e hora e o tamanho, e valide a base de dados ou o arquivo com a ferramenta apropriada ao formato da cópia de segurança antes de eliminar a cópia anterior conhecida como válida.

Em seguida, faça um exercício de restauração para um caminho isolado ou uma instância de teste, quando for prático. O objetivo é provar que a cópia de segurança abre como um estado de servidor coerente, e não apenas que o software de cópia de segurança comunicou sucesso. Mantenha pelo menos um ponto de recuperação mais antigo até a cópia mais recente passar esse teste.

Um método de cópia de segurança falha o teste operacional se a restauração exigir suposições não documentadas sobre caminhos, proprietários, credenciais ou sobre qual cópia da base de dados pertence a qual árvore de metadados. Corrija o procedimento enquanto o Plex de produção está saudável, em vez de descobrir essas dependências depois de uma falha.

Escolha o procedimento de menor risco para as suas necessidades de disponibilidade

Para a maioria dos servidores Plex domésticos, uma breve paragem agendada é o procedimento fiável mais simples para uma cópia completa dos dados da aplicação ao nível dos ficheiros. Programe-a para um período de menor utilização, prepare primeiro o destino e automatize o reinício e a verificação para que o tempo de inatividade se mantenha previsível.

Escolha um fluxo de trabalho em execução apenas quando a disponibilidade justificar a complexidade adicional e o método fornecer explicitamente semântica consistente da base de dados para o estado em execução que está a proteger. Mantenha um procedimento de recurso documentado de paragem e cópia, caso a ferramenta de cópia de segurança em execução seja alterada ou o teste de restauração falhe.

A regra de decisão é prática: se a cópia de segurança for uma cópia simples de ficheiros Plex ativos, pare primeiro o serviço; se for um método de base de dados em execução com conhecimento da aplicação, comprove a sua consistência e cobertura através de um teste de restauração. A melhor cópia de segurança é aquela que consegue restaurar repetidamente, não aquela que comunica zero tempo de inatividade.