Backup de banco de dados: como recuperar até o ponto certo sem perder consistência

Um backup de banco de dados só é útil quando pode ser restaurado em um estado coerente e dentro do intervalo que a operação aceita perder. Para muitas empresas, uma cópia diária resolve falhas comuns; para sistemas com transações frequentes, pode deixar uma lacuna grande entre a última cópia e o incidente.

O caminho não é simplesmente “copiar os arquivos”. É combinar uma cópia-base, registros das alterações quando a tecnologia permite, proteção contra acesso indevido e testes de restauração. Este guia explica como avaliar essa estratégia e quais limites esclarecer antes de depender dela.

O que significa recuperar para um ponto no tempo?

Na recuperação pontual (PITR), a equipe restaura uma cópia-base e reaplica registros de alterações até um instante escolhido. No PostgreSQL, esses registros são chamados WAL (Write-Ahead Log). A documentação oficial explica que uma sequência contínua de WAL arquivada permite parar a reprodução em um instante anterior e obter uma visão consistente do banco naquele momento.

Isso pode ajudar, por exemplo, quando uma rotina apaga registros às 14h20: em vez de voltar à cópia da madrugada, a equipe pode tentar recuperar o banco para pouco antes da exclusão — desde que a cópia-base e a sequência necessária de WAL estejam disponíveis, íntegros e configurados corretamente.

Uma cópia não equivale a uma recuperação testada

O PostgreSQL ressalta que o arquivamento de WAL deve estar funcionando antes da primeira cópia-base e que, para recuperar, é necessária uma sequência contínua desde o início do backup. Uma lacuna nos arquivos pode inviabilizar o alvo pretendido. Já um dump lógico, como os gerados por pg_dump, é uma forma diferente de backup e não substitui a cadeia de WAL para esse método de PITR.

Na prática, separe três perguntas:

• O que está protegido? Banco, arquivos da aplicação, configurações, certificados e dependências podem exigir cópias e procedimentos distintos.
• Até quando consigo voltar? Defina o RPO (perda máxima de dados aceitável, em tempo) e confirme que a frequência das cópias e o arquivamento cobrem essa meta.
• Quanto tempo levo para voltar? O RTO (tempo-alvo para retomar o serviço) depende também de infraestrutura disponível, equipe, validação e ordem de recuperação.

Checklist para tornar a recuperação executável

1. Mapeie dependências: identifique banco, aplicação, arquivos enviados, DNS, credenciais e configurações necessárias para iniciar o serviço.
2. Documente a cadeia: registre onde está a cópia-base, como obter os registros incrementais, a retenção e quem tem autorização para recuperar.
3. Proteja as cópias: use criptografia e controles de acesso separados da administração cotidiana; mantenha uma cópia offline ou isolada quando viável. A CISA recomenda cópias críticas offline e criptografadas e testes regulares de disponibilidade e integridade contra ransomware.
4. Alarme para falhas: monitore tarefas malsucedidas, atraso do arquivamento, espaço disponível e lacunas de sequência — não apenas a existência de arquivos.
5. Restaure em ambiente isolado: faça um ensaio sem sobrescrever produção. Valide consistência, aplicação, permissões e uma amostra de dados relevantes.
6. Meça o resultado: anote o ponto efetivamente recuperado e o tempo total. Compare com RPO/RTO; ajuste frequência, retenção ou procedimento se a meta não for atingida.

Como testar sem colocar produção em risco

Escolha um cenário plausível — exclusão acidental, corrupção ou indisponibilidade — e defina previamente o instante de recuperação desejado. Em ambiente separado, restaure a cópia-base, reproduza a sequência de logs até o alvo e confira os dados com a aplicação ou consultas de validação. Registre duração, etapas manuais, erros e dependências ausentes.

O teste precisa verificar mais que “o job terminou”: confirme que a aplicação consegue usar os dados, que as gravações esperadas estão presentes e que as posteriores ao ponto escolhido realmente não aparecem. Faça exercícios periódicos e após mudanças relevantes no banco, na infraestrutura ou no processo de backup.

Limites importantes

PITR não elimina a necessidade de cópias independentes nem resolve por si só comprometimento de credenciais, exfiltração ou contaminação anterior ao ponto de recuperação escolhido. A restauração também pode exigir espaço, capacidade computacional, versões compatíveis e conhecimento operacional. Recursos específicos variam conforme o banco, a versão e a forma como a equipe implementou o arquivamento; valide a documentação da versão usada.

Para empresas que executam bancos em VPS ou cloud, vale incluir banco, aplicação e arquivos no mesmo plano de continuidade, mas testar cada camada e suas dependências. A HAD Cloud oferece infraestrutura de hospedagem e cloud; consulte a equipe para entender opções adequadas ao seu cenário, sem presumir que uma infraestrutura específica substitua uma política de backup e recuperação.

Perguntas frequentes

PITR substitui backups completos?

Não. A estratégia descrita pelo PostgreSQL combina uma cópia-base com uma sequência contínua de WAL. Sem uma base recuperável ou sem os registros necessários, o ponto desejado pode não ser alcançável.

Com que frequência devo testar a restauração?

Não existe intervalo universal. Defina uma cadência compatível com o impacto de uma falha e repita após mudanças importantes. O critério é demonstrar que a meta de recuperação continua viável.

RPO e RTO são a mesma coisa?

Não. RPO trata do quanto de dados, medido em tempo, a empresa aceita perder; RTO trata do tempo que aceita levar para retomar o serviço. O teste real ajuda a verificar se ambos são plausíveis.

Fontes

• PostgreSQL 18 — Continuous Archiving and Point-in-Time Recovery.
• PostgreSQL — SQL Dump (pg_dump e pg_dumpall).
• CISA — #StopRansomware Guide.

Este conteúdo é informativo e deve ser adaptado às tecnologias, requisitos regulatórios e objetivos de continuidade da sua organização.