Backup e recuperação
RPO, RTO e por que um backup que nunca foi restaurado não conta.
As decisões de backup são cinco: qual técnica, onde guardar, por quanto tempo, como testar e como recuperar.
Qual técnica
| Técnica | RPO | RTO | Bom para |
|---|---|---|---|
Dump lógico diário (pg_dump) | Até 24 h | Lento em bancos grandes (o dobro do dump, no teste) | Bancos pequenos, migrar entre versões, restaurar uma tabela |
| Cópia física e arquivamento contínuo do log (PITR) | Minutos ou segundos | Cópia física mais o log reaplicado | A maioria dos bancos de produção |
| Snapshot do disco (nuvem, sistema de arquivos) | O intervalo entre snapshots | Rápido | Complemento; exige que o banco esteja consistente no snapshot |
| Banco gerenciado (RDS, Cloud SQL, Azure) | Minutos, com PITR embutido | Criar uma instância nova a partir do ponto escolhido | Quem não quer operar o backup |
| Réplica com atraso proposital | — | Rápido | Desfazer um erro descoberto em poucas horas; não substitui backup |
Para o PostgreSQL, ferramentas como pgBackRest, Barman e WAL-G cuidam da cópia física, do arquivamento, da compressão, da criptografia, da retenção e da restauração. Montar isso à mão com archive_command, como no teste, serve para entender; em produção, use uma delas ou o serviço gerenciado.
Muitos sistemas combinam: PITR para o RPO curto e um dump lógico semanal, mais portátil, como segunda linha.
Onde guardar: a regra 3-2-1
| Regra | Significado |
|---|---|
| 3 cópias | Os dados em produção e mais duas cópias |
| 2 meios diferentes | Por exemplo, disco local e armazenamento de objetos |
| 1 fora do local | Outra região, e de preferência outra conta |
Contra ransomware e contas comprometidas, acrescente uma cópia imutável: armazenamento de objetos com bloqueio contra exclusão (object lock), como mostra o tópico de armazenamento de objetos, numa conta que as credenciais de produção não alcançam. Se quem invade a produção consegue apagar o backup, ele não protege contra esse ataque.
E criptografe os backups, guardando a chave em outro lugar, que também tem backup.
Por quanto tempo
| Camada | Retenção típica |
|---|---|
| Log arquivado para PITR | 7 a 35 dias |
| Cópias físicas | Diárias por uma semana, semanais por um mês |
| Cópias de longo prazo | Mensais ou anuais, conforme exigências legais e contratuais |
A retenção tem dois limites: guardar o suficiente para descobrir um erro antigo (uma corrupção silenciosa pode levar semanas para ser notada) e não guardar além do permitido. A LGPD exige que dados pessoais apagados a pedido do titular não voltem com uma restauração; o processo de restauração precisa reaplicar essas exclusões.
Como testar
| Teste | Frequência | O que prova |
|---|---|---|
Conferir a integridade (pg_verifybackup, sumários das ferramentas) | A cada backup | Os arquivos estão completos |
| Restauração automática num servidor separado, com verificação por consultas | Diária ou semanal | O backup restaura, e o RTO medido |
| Recuperação num ponto do tempo para um horário escolhido | Mensal | O log arquivado está completo |
| Ensaio de desastre com o time | Semestral | O processo, as pessoas e os acessos funcionam |
A restauração automática fecha o ciclo: um job restaura o backup mais recente num servidor descartável e roda um verificador (tabelas esperadas, contagens mínimas, último registro dentro do RPO), que alerta se algo falhar. No teste, foi exatamente a restauração num servidor novo que revelou a falta dos usuários e das permissões, num dump que tinha sido gerado sem erro.
Como recuperar
Escreva o roteiro antes de precisar dele:
- Pare as gravações no banco danificado, para não piorar a situação.
- Decida o ponto de recuperação: o último momento bom, pelos logs da aplicação ou pelo horário do erro.
- Restaure num servidor novo, sem sobrescrever o atual: ele ainda pode ter dados úteis gravados depois do ponto escolhido.
- Verifique com o mesmo verificador da restauração automática.
- Recupere o que ficou depois do ponto, se der, a partir do banco danificado.
- Troque a aplicação para o banco restaurado.
- Registre o que aconteceu, o RPO e o RTO reais.
Resumo da decisão
- RPO e RTO definidos pelo negócio, por escrito.
- Cópia física e log arquivado (PITR) para produção, com uma ferramenta pronta ou o serviço gerenciado; dump lógico como segunda linha.
- Regra 3-2-1, com uma cópia imutável em outra conta, e as chaves de criptografia guardadas à parte.
- Usuários, permissões, configurações e extensões dentro do backup.
- Restauração automática e verificada com regularidade, medindo o RTO.
- Roteiro de recuperação escrito e ensaiado.
O próximo nível mostra o verificador de restauração nas cinco linguagens e os comandos usados no teste.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Planejar o backup do meu banco
Quero planejar o backup do banco do meu sistema. Pergunte qual banco e versão eu uso, onde ele roda, o tamanho, quanto de dado eu aceito perder, quanto tempo o sistema pode ficar fora e se há exigências legais de retenção. Proponha: 1. A técnica (PITR, dump, snapshots ou serviço gerenciado) e a ferramenta. 2. Onde guardar, com a regra 3-2-1 e uma cópia imutável. 3. A retenção de cada camada. 4. A criptografia e onde fica a chave. 5. Os testes de restauração e a frequência.
Proteger os backups contra ransomware
Quero proteger os backups do meu sistema contra ransomware e contas comprometidas. Pergunte qual nuvem e ferramentas de backup eu uso e como as credenciais de produção estão organizadas. Me ajude a montar: a conta separada para backups, o bloqueio contra exclusão (object lock), as permissões mínimas para gravar sem poder apagar, a criptografia com chave fora do alcance da produção, e um teste que prove que as credenciais de produção não conseguem apagar os backups.
Roteiro de recuperação de desastre
Quero escrever o roteiro de recuperação do meu sistema para quando os dados se perderem. Pergunte como são os backups hoje, quem tem acesso a quê e como a aplicação se conecta ao banco. Monte comigo o roteiro, passo a passo: parar as gravações, decidir o ponto de recuperação, restaurar num servidor novo, verificar, recuperar o que ficou depois do ponto, trocar a aplicação e registrar o incidente. Inclua quem faz cada passo e os comandos.