Deverá pausar os contentores de aplicações ou utilizar cópias de segurança das aplicações antes de criar um instantâneo do NAS?

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.

A abordagem segura consiste em tratar a escolha específica da carga de trabalho entre uma cópia de segurança da aplicação, uma suspensão coordenada ou uma paragem limpa antes do instantâneo como uma sequência de etapas observáveis, e não como um único comando.

Numa aplicação em contentores num NAS compatível com instantâneos, o risco prático é a incerteza sobre se um instantâneo ativo do NAS irá restaurar os contentores com estado de forma consistente. Registe a identidade atual e o ponto de recuperação, comece pelo fator de distinção menos invasivo, interprete os resultados aprovados e reprovados antes de alterar outra variável e pare quando o armazenamento se tornar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina quando a carga de trabalho original funcionar ou quando as evidências atingirem um limite de escalada.

Tome a decisão sobre a consistência antes de tocar na stack

Use uma cópia de segurança nativa da aplicação quando a aplicação ou a base de dados disponibilizar uma. Use um hook coordenado de suspensão e criação de instantâneo apenas quando a base de dados suportar esse fluxo de trabalho, e use uma paragem limpa quando for aceitável uma breve indisponibilidade. Considere uma simples pausa do contentor, no melhor dos casos, consistente em termos de falha, e não automaticamente consistente em termos da aplicação.

A distinção é importante porque o comportamento de pausa do Docker congela os processos sem executar o respetivo percurso normal de encerramento e descarga. Pode impedir novas gravações durante um instantâneo do sistema de ficheiros muito curto, mas não pode provar que os buffers da base de dados, os diários, os anexos e os serviços dependentes representam um estado da aplicação que possa ser restaurado.

Registe o motor da base de dados, a funcionalidade de cópia de segurança da aplicação, os caminhos dos volumes, os caminhos de carregamento, os segredos, a versão da imagem e o tempo de indisponibilidade aceitável. Se algum componente com estado for desconhecido, a decisão permanece por resolver e o instantâneo não deve ser promovido a cópia de segurança testada.

Escolha o caminho válido menos disruptivo

Para PostgreSQL, MariaDB e outras bases de dados de serviços, prefira o processo de exportação ou de cópia de segurança física suportado por cada uma. Para SQLite, use a exportação da aplicação ou a cópia de segurança online do SQLite, quando disponível. Recolha os ficheiros carregados e a configuração na mesma janela de recuperação, para que a base de dados não aponte para ficheiros em falta ou futuros.

Quando não existir um caminho online suportado, pare primeiro os processos que efetuam gravações e, em seguida, pare a base de dados de forma limpa, confirmando que os processos terminaram antes de criar o instantâneo. A pausa pode servir de ponte estreita apenas quando a documentação e um teste de restauro demonstrarem que a recuperação após falha é suficiente para esta carga de trabalho específica; não é um substituto geral de uma cópia de segurança da aplicação.

Uma pequena stack de servidor doméstico pode seguir as cópias de segurança consistentes de contentores de bases de dados adjacentes, para exportações nativas da base de dados e cópias com paragem limpa. Mantenha o âmbito deste artigo mais restrito: este decide a ação antes do instantâneo, enquanto o guia associado aborda o conteúdo do pacote de cópia de segurança mais abrangente.

Execute uma janela de instantâneo coordenada

Suspenda as tarefas agendadas e as gravações dos utilizadores, execute a preparação selecionada da aplicação ou da base de dados e verifique o seu sucesso antes de criar o instantâneo do sistema de ficheiros. Crie rapidamente o instantâneo e, em seguida, liberte a suspensão ou reinicie a stack; copie ou replique o instantâneo depois, para que o tempo de indisponibilidade não seja igual ao tempo de transferência.

Adicione uma armadilha de falha a cada hook personalizado. Se a preparação falhar, não crie o instantâneo; se a criação do instantâneo falhar, retome sempre a aplicação; se a retoma falhar, mantenha os utilizadores impedidos de aceder e restaure o serviço deliberadamente. Registe cada transição para que um tempo limite silencioso do pré-hook não produza uma tarefa de cópia de segurança falsamente bem-sucedida.

Considere aprovado quando a aplicação regressar ao funcionamento normal, o instantâneo tiver o carimbo de data e hora e os conjuntos de dados esperados e nenhuma dependência tiver sido capturada fora da janela. Reverta a automatização se algum contentor permanecer pausado ou se a base de dados comunicar recuperação em todos os instantâneos de rotina.

Comprove a escolha com um restauro isolado

Restaure o instantâneo ou a cópia de segurança nativa num projeto descartável, com portas e caminhos de armazenamento diferentes. Inicie primeiro a base de dados, execute a verificação da respetiva integridade, ligue depois a aplicação e inspecione os registos recentes, os utilizadores, os anexos, as tarefas agendadas e as permissões. Não teste na base de dados de produção.

Uma aprovação exige mais do que um arranque limpo do contentor: a aplicação tem de ler e atualizar o estado restaurado, os ficheiros relacionados têm de corresponder às referências da base de dados e um segundo reinício tem de continuar limpo. Compare esse resultado com um restauro de uma cópia de segurança nativa se tencionar depender de instantâneos consistentes em termos de falha.

Utilize o método de instantâneos apenas depois de a carga de trabalho original passar este teste. Se a recuperação baseada em pausa for intermitente, se for necessária uma reparação da base de dados ou se não for possível associar um componente ao mesmo ponto de recuperação, mude para uma cópia de segurança nativa da aplicação ou para uma paragem limpa e conserve o instantâneo que falhou como evidência, em vez de o substituir.

Suporte e Dicas

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.