Backup PostgreSQL Grande Porte

Backups de Bancos PostgreSQL (Grande Porte)

Este documento descreve estratégias comuns para realizar **backup de bancos de dados PostgreSQL de grande porte**, abordando vantagens, desvantagens e boas práticas. O foco é minimizar impacto em produção, garantir consistência dos dados e facilitar a recuperação em caso de desastre.

Objetivos de um bom backup

• Garantir **recuperação de dados** em caso de falha, erro humano ou ataque
• Minimizar **impacto no banco principal (produção)**
• Possibilitar **restauração parcial ou total**
• Manter cópias **fora do servidor de origem**

1. Backup lógico via replicação (pg_dump em réplica)

Nesta abordagem, utiliza-se uma **réplica de leitura** (streaming replication) para executar o backup lógico com `pg_dump`, evitando carga adicional no banco principal.

Funcionamento

• Banco primário replica dados continuamente para um ou mais nós secundários
• O `pg_dump` é executado **no banco replicado**
• O backup é gerado em formato lógico (custom format)

Vantagens

• Não impacta significativamente o banco de produção
• Permite backup por banco
• Não exige parada do banco

Desvantagens

• Processo pode ser lento para bancos muito grandes
• Consome CPU, memória e I/O do servidor réplica
• Não preserva estatísticas internas e configurações físicas
• Restauração pode ser demorada

Boas práticas

• Utilizar formato `custom` (`pg_dump -Fc`) para permitir paralelismo na restauração
• Garantir que a réplica esteja sincronizada
• Automatizar via cron ou ferramentas de orquestração

2. Backup físico da pasta de dados (data directory)

O backup físico consiste em copiar diretamente o **diretório de dados do PostgreSQL** (`PGDATA`).

Abordagem tradicional

• Parar o serviço PostgreSQL
• Copiar o diretório de dados via script (`rsync`, `tar`, etc.)
• Reiniciar o serviço

Vantagens

• Backup rápido, especialmente para bancos muito grandes
• Preserva estrutura física, índices e estatísticas
• Restauração geralmente mais rápida

Desvantagens

• Necessita **parada do banco** (downtime)
• Risco operacional se scripts não forem bem controlados
• Pouca flexibilidade para restaurações parciais

Alternativas mais seguras

• `pg_basebackup`: permite backup físico **sem parar o banco**
• Uso de WALs para **PITR (Point-In-Time Recovery)**

Boas práticas

• Sempre validar consistência após restore
• Testar restauração regularmente

3. Soluções de backup de mercado (ex: Veeam Backup)

Ferramentas comerciais oferecem integração com PostgreSQL e infraestrutura.

Características

• Interface gráfica e gerenciamento centralizado
• Automação de políticas de retenção
• Integração com snapshots de storage e virtualização

Vantagens

• Reduz complexidade operacional
• Suporte técnico através do fornecedor da ferramenta
• Integração com ambientes VMware, Hyper-V e cloud

Desvantagens

• Custo de licenciamento
• Dependência de fornecedor
• Menor controle sobre detalhes internos do backup

Observações

• Verificar se a solução é **application-aware** para PostgreSQL
• Garantir suporte a WAL e restauração consistente

4. RAID

RAID **não é backup**, mas pode fazer parte da estratégia de disponibilidade.

O que o RAID oferece

• Redundância de discos
• Proteção contra falha física de hardware
• Melhor desempenho de leitura/escrita (dependendo do nível)

Limitações

• Não protege contra:

 * Exclusão acidental de dados
 * Corrupção lógica
 * Ataques (ex: ransomware)

• Erros são replicados imediatamente

Conclusão

RAID deve ser visto apenas como **camada de alta disponibilidade**, nunca como substituto de backup.

Observação importante: backups fora da máquina

Mesmo com backups configurados, é fundamental:

• Manter cópias **fora do servidor de origem**
• Utilizar outro datacenter, storage remoto ou cloud (VRBackup)
• Implementar política de retenção (diário, semanal, mensal)

Informações adicionais e boas práticas gerais

• Documentar claramente o processo de backup e restore
• Monitorar falhas de backup
• Testar restores periodicamente (disaster recovery test)
• Utilizar compressão e paralelismo quando possível

Estratégia recomendada

Uma estratégia robusta geralmente combina:

• Replicação + `pg_dump` para restores lógicos
• Backup físico (`pg_basebackup` + WAL) para recuperação rápida
• Cópia externa (offsite)
• RAID para resiliência de hardware

Backups só são confiáveis quando a restauração foi testada com sucesso.