Você já acompanhou um backup de banco de dados rodar por mais de um dia inteiro?
Foi o cenário que encontramos em um ambiente PostgreSQL com base acima de 600 GB. O processo usava pg_dump com compressão e criptografia — funcional quando foi criado, mas completamente fora de controle depois que a base dobrou de tamanho.
Este artigo documenta como resolvemos isso usando pg_basebackup, compressão nativa e envio offsite para nuvem, reduzindo a janela de backup de 25h24min para 2h28min — sem substituir nenhum equipamento.
O problema: pg_dump não escala bem em bases grandes
O pg_dump é uma excelente ferramenta para backups lógicos. Ele exporta objetos do banco (tabelas, índices, funções) em um formato portável e legível.
O problema é que ele serializa o processo: lê dado a dado, comprime, criptografa e grava. Em bases pequenas, isso é rápido. Em uma base de 600 GB rodando em HDD, isso se tornou um gargalo de 25 horas de execução contínua — mantendo carga sobre o servidor e impactando as aplicações dependentes.
A alternativa: pg_basebackup para backup físico
O pg_basebackup é a ferramenta nativa do PostgreSQL para backup físico do cluster. Em vez de exportar objetos lógicos, ele copia os arquivos físicos do data directory.
Vantagens relevantes para o nosso cenário:
- Leitura sequencial dos arquivos físicos (mais eficiente em HDD)
- Suporte nativo a compressão (LZ4 e ZSTD desde o PostgreSQL 15)
- Suporte a criptografia integrada
- Restauração mais simples: basta apontar o data directory
Testes realizados
Realizamos uma série de testes variando algoritmo de compressão, criptografia e fragmentação de arquivos:
| Método | Tempo Total | Tamanho Final |
|---|---|---|
pg_dump (baseline) |
25h24min | — |
pg_basebackup sem compressão |
2h45min | 684 GB |
pg_basebackup com LZ4 |
1h21min | 426 GB |
pg_basebackup com ZSTD nível 3 |
2h50min | 359 GB |
pg_basebackup LZ4 + criptografia + fragmentação |
2h28min | 426 GB |
pg_basebackup ZSTD + criptografia + fragmentação |
4h30min | 359 GB |
Por que LZ4 e não ZSTD?
O ZSTD nível 3 gerou arquivos 16% menores que o LZ4. Parece vantajoso à primeira vista — mas o tempo foi mais que o dobro (2h50min vs 1h21min).
O motivo é o hardware: o servidor usa HDD com leitura sequencial de ~150–200 MB/s. Nesse cenário, o gargalo é o disco, não o tamanho do arquivo. O LZ4 é otimizado para velocidade de CPU e se encaixou melhor nesse perfil.
Em SSD ou NVMe, o gargalo deixa de ser o disco e passa a ser a CPU. Nesse caso, o ZSTD se torna mais atrativo — arquivos menores significam menos custo de armazenamento em nuvem, e a diferença de tempo diminui bastante.
A escolha do algoritmo de compressão depende do hardware disponível, não existe resposta universal.
Sobre a criptografia: overhead justificado
Adicionamos criptografia AES-256 ao processo. O pg_basebackup com LZ4 puro foi concluído em 1h21min. Com criptografia e fragmentação, subiu para 2h28min — aproximadamente 1 hora de overhead.
Vale? Sim.
Dados de backup trafegando para a nuvem sem criptografia representam um risco real de exposição — especialmente em ambientes sujeitos à LGPD. O custo de uma hora a mais de processamento não se compara ao risco de um vazamento de dados de produção.
Por que fragmentar os arquivos?
Arquivos únicos de centenas de gigabytes causam problemas práticos:
- Falha na transferência = reiniciar o envio completo
- Alguns provedores de nuvem impõem limites de tamanho por arquivo
- Verificação de integridade fica mais difícil
Fragmentar em partes menores torna o processo mais resiliente, facilita reenvios parciais e simplifica a gestão no destino.
Resultado final
pg_dump original: 25h24min
pg_basebackup + LZ4 + AES-256 + split: 2h28min
Redução de ~90% na janela de backup, mantendo compressão, criptografia e envio offsite — sem substituir nenhum equipamento.
O que isso mostra na prática
Estratégias de backup precisam ser revisadas periodicamente. Uma solução adequada para 200 GB pode se tornar inviável operacionalmente após alguns anos de crescimento — e esse problema costuma aparecer na pior hora possível.
Algumas perguntas que vale fazer sobre o seu ambiente hoje:
- Quando foi a última vez que você testou uma restauração completa?
- Sua janela de backup cabe dentro do horário de menor impacto?
- Seus backups estão criptografados antes de sair do servidor?
- Você conhece o RTO e o RPO real do seu ambiente?
Se alguma dessas perguntas ficou sem resposta rápida, pode ser o momento de revisar a estratégia.
Artigo original publicado no blog da Proactus Tecnologia — empresa especializada em infraestrutura de TI e banco de dados corporativo em Curitiba, PR.
Top comments (0)