Os backups da sua aplicação auto-hospedada são consistentes? Teste o banco de dados, os arquivos e a ordem de restauração

Um backup pode ser concluído enquanto a aplicação continua inconsistente

Uma aplicação empresarial pode armazenar registros em um banco de dados e os arquivos enviados em um diretório separado ou serviço de armazenamento. Os backups desses componentes podem ser legíveis e, ainda assim, corresponder a momentos diferentes. Depois da restauração, um registro pode apontar para um anexo ausente, ou um arquivo pode existir sem o registro que o vincula a ele.

O objetivo é determinar se a aplicação pode ser reconstruída a partir de um conjunto compatível de backups — e não apenas verificar se os arquivos de backup foram criados. Um relatório de execução bem-sucedida mostra que um processo foi executado; por si só, não comprova que todo o serviço possa ser restaurado.

• Escolha um registro representativo que tenha um anexo enviado ou outro arquivo vinculado.
• Identifique onde são armazenados o registro, o arquivo e o vínculo entre eles.
• Trate os diferentes cronogramas de backup como uma questão a investigar, não como prova de inconsistência ou coordenação.

Mapeie o que a aplicação precisa

Consulte a documentação e as configurações de implantação da aplicação para identificar o que precisa estar disponível durante uma restauração. Não presuma que o banco de dados representa todo o serviço ou que os arquivos ficam armazenados junto dele. Se não conseguir inspecionar um componente, peça ao provedor de hospedagem que esclareça o que está incluído.

As instruções da aplicação podem definir os backups como compostos por várias partes. Por exemplo, o guia de backup auto-hospedado do Hudu descreve um backup completo como composto por duas partes distintas e identifica um banco de dados PostgreSQL como uma delas. Consulte as instruções da sua própria aplicação para determinar quais componentes são necessários: [Suporte do Hudu: backups e restaurações auto-hospedados](https://support.hudu.com/hc/en-us/articles/11653994397079-Self-Hosted-Backups-and-Restores).

• Banco de dados e arquivos persistentes, incluindo anexos ou outros conteúdos enviados.
• Configurações e quaisquer credenciais, chaves de criptografia ou tokens necessários durante a recuperação.
• Armazenamento externo ou serviços dos quais a aplicação depende.
• Versões da aplicação e do banco de dados ou detalhes de implantação exigidos pelo procedimento de restauração documentado.

Verifique como — e quando — cada componente é capturado

Pergunte se os componentes relacionados são capturados em conjunto ou segundo cronogramas independentes. Considere o que acontece se usuários estiverem editando registros ou enviando arquivos, ou se tarefas em segundo plano estiverem alterando dados durante um backup.

Um artigo técnico alerta especificamente que copiar os arquivos de dados de um banco de dados em execução não é uma forma confiável de fazer backup: [Stackademic, “Hospedagem própria sem pânico (10/12): backups que restauram”](https://blog.stackademic.com/self-hosting-without-panic-10-12-backups-that-restore-the-only-kind-that-counts-e11c1d08c7d8). Esse alerta se refere à cópia de arquivos de dados ativos; não significa que todos os bancos de dados exijam o mesmo procedimento de backup. Siga o procedimento documentado para o seu banco de dados e aplicação.

• Os backups do banco de dados e dos arquivos são feitos em conjunto ou seguem cronogramas separados?
• Se forem separados, como o processo garante que representem um estado compatível da aplicação?
• Como as edições ativas, os envios de arquivos, as tarefas agendadas e o processamento em segundo plano são tratados durante a captura?
• A aplicação documenta algum procedimento de backup ou manutenção que deve ser seguido?

Confirme o que o provedor de hospedagem gerencia

A palavra “backup” não especifica o que está incluído no serviço de um provedor de hospedagem. Confirme se o processo abrange o banco de dados, o armazenamento persistente de arquivos e outros dados necessários à aplicação, e se os componentes relacionados são coordenados.

A Airbip executa instâncias de aplicações como cargas de trabalho Docker em servidores na nuvem da Airbip e oferece backups diários, semanais e mensais configuráveis. Essas funcionalidades, por si só, não determinam o que está incluído em um backup específico, como os componentes são coordenados ou o que será recuperado em uma restauração. Confirme o escopo e o processo de restauração da sua instância, em vez de deduzi-los a partir do cronograma.

Registre as respostas do provedor e as tarefas de recuperação que cabem a você, incluindo quem solicita uma restauração e quem a valida.

• Quais dados e locais de armazenamento estão incluídos? O que é excluído ou tratado separadamente?
• O provedor coordena a captura do banco de dados e dos arquivos? Que nível de consistência pode confirmar?
• Quem inicia uma restauração, fornece as informações necessárias sobre a aplicação e verifica o serviço restaurado?
• Onde é possível consultar o cronograma de backup atual e os termos de serviço aplicáveis?

Restaure seguindo as instruções da aplicação

Não existe uma ordem de restauração universal para todas as aplicações auto-hospedadas. Siga as instruções oficiais de restauração da aplicação e o procedimento do provedor. Confirme as dependências antes de começar, restaure os componentes relacionados como um conjunto compatível e verifique quando é seguro iniciar a aplicação ou reconectar usuários e tarefas em segundo plano.

Use um ambiente de teste isolado, a menos que seu plano determine explicitamente outra abordagem. Durante o teste, mantenha os dados restaurados separados do ambiente de produção.

• Confirme o ambiente de destino e o acesso necessário para restaurar nele.
• Recupere as configurações e os segredos necessários pelo processo seguro adequado.
• Restaure o banco de dados e os arquivos seguindo o procedimento documentado e preserve a relação prevista entre eles.
• Registre os componentes que precisam ser recriados ou reconectados, em vez de restaurados a partir do backup.

Teste registros vinculados e o comportamento normal da aplicação

Um teste de restauração fornece evidências práticas de que os backups podem ser usados. Escolha um conjunto representativo de backups e teste-o em um ambiente isolado. Verifique registros comuns e registros com anexos, não apenas se o banco de dados ou a aplicação inicia.

Compare os dados restaurados com exemplos conhecidos do ambiente de origem, incluindo alterações recentes que deveriam estar presentes no backup selecionado. Se algo estiver faltando, registre o problema e investigue se ele está relacionado ao escopo, ao momento da captura, ao procedimento de restauração ou a uma dependência externa.

• Abra registros representativos e verifique se os anexos ou arquivos vinculados estão acessíveis.
• Confira registros e edições recentes que deveriam estar presentes no backup selecionado.
• Quando for possível verificar isso na aplicação, procure arquivos órfãos ou registros que apontem para arquivos ausentes.
• Teste um fluxo de trabalho normal da aplicação, não apenas se o login funciona.
• Registre o que foi restaurado, os erros ou dados ausentes e quaisquer etapas manuais de recuperação.

Documente e revise o plano de recuperação

Mantenha um registro breve dos backups em um local acessível à equipe responsável pela recuperação. Diferencie os detalhes confirmados das suposições e das perguntas sem resposta. Um cronograma de backup descreve a frequência com que os backups podem ser feitos; por si só, não determina a retenção, a cobertura ou a consistência.

Revise o registro quando houver mudanças na aplicação, no armazenamento, nas configurações ou na hospedagem, e periodicamente conforme as necessidades operacionais. Se algum detalhe importante continuar sem confirmação, marque-o como não verificado e decida se deve obter uma resposta documentada ou testá-lo.

• Registre a cobertura confirmada, as exclusões, o cronograma, a retenção e o processo para acessar os dados de backup.
• Defina quem contata o provedor, fornece as informações necessárias sobre a aplicação e valida uma restauração.
• Mantenha os resultados datados dos testes de restauração, incluindo verificações malsucedidas e ações de acompanhamento.
• Após mudanças, verifique novamente as dependências e repita os testes de restauração relevantes.