Como reduzimos uma janela de backup PostgreSQL de 25 horas para menos de 3 horas
- Autor: Alex Hinckel
- Publicado:
- Atualizado: 11/06/2026
- 7 min
Introdução
O backup é um dos componentes mais críticos de qualquer ambiente PostgreSQL. Dentro de uma política de backup bem estruturada, manter cópias offsite — armazenadas fora do ambiente de produção, em nuvem — é uma camada essencial de proteção contra falhas graves, ransomware e desastres físicos.
Recentemente enfrentamos um cenário onde a base de dados havia ultrapassado 600 GB. O processo existente utilizava pg_dump com compressão e criptografia, mas a janela de execução já ultrapassava 25 horas — mantendo carga constante sobre o banco durante praticamente um dia inteiro e impactando as aplicações dependentes da plataforma.
Neste artigo compartilhamos como migramos essa rotina para um modelo de backup físico com envio direto para a nuvem, eliminando o gargalo operacional e mantendo a conformidade com nossa política de backup offsite.
O cenário inicial
O ambiente utilizava uma rotina baseada em:
- Backup com pg_dump
- Compressão dos dados
- Criptografia de dados
- Armazenamento em nuvem para retenção
Embora funcional, a solução foi criada quando a base possuía um volume significativamente menor de dados. Com o crescimento contínuo da operação, a base praticamente dobrou de tamanho desde a implantação inicial da rotina.
Como consequência, o tempo médio de execução ultrapassou 25 horas, tornando a estratégia cada vez menos adequada para o ambiente.
Avaliando alternativas
Após analisar a documentação oficial do PostgreSQL e revisar as opções disponíveis, optamos por realizar testes utilizando o pg_basebackup, ferramenta nativa destinada à realização de backups físicos do cluster PostgreSQL.
Diferentemente do pg_dump, que exporta objetos lógicos do banco de dados, o pg_basebackup realiza uma cópia física do cluster, permitindo uma restauração significativamente mais rápida e reduzindo a complexidade do processo.
Foram realizados diversos testes para avaliar desempenho, compressão e tamanho final dos arquivos gerados.
Resultados obtidos
| Método | Tempo Total | Tamanho Final |
|---|---|---|
| Backup lógico (pg_dump) | 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 com LZ4, criptografia e fragmentação | 2h28min | 426 GB |
| pg_basebackup com ZSTD nível 3, criptografia e fragmentação | 04h:30m | 359 GB |
Os resultados demonstraram uma redução extremamente significativa da janela de backup.
Mesmo considerando compressão, criptografia e divisão dos arquivos em múltiplas partes, a nova estratégia manteve o tempo total abaixo de três horas.
Compressão: LZ4 ou ZSTD?
Durante os testes, o algoritmo LZ4 apresentou o melhor equilíbrio entre desempenho e redução de espaço.
Embora o ZSTD tenha produzido arquivos menores, o ganho adicional de compressão não compensou o aumento do tempo de processamento para o cenário avaliado.
A escolha final foi pela utilização do LZ4, priorizando a redução da janela de backup sem abrir mão de uma boa taxa de compressão.
Benefícios obtidos
A adoção do backup físico trouxe diversas vantagens operacionais:
- Redução drástica da janela de backup.
- Menor carga prolongada sobre o ambiente PostgreSQL.
- Processo de restauração mais simples e rápido.
- Melhor aproveitamento da infraestrutura existente.
- Maior previsibilidade operacional.
Backup, desempenho, segurança e conformidade com a LGPD — a Proactus Tecnologia cuida do seu ambiente de banco de dados.
Conclusão
O crescimento da base de dados exige revisões periódicas das estratégias de backup adotadas. Uma solução adequada para alguns centenas de gigabytes pode se tornar inviável operacionalmente após alguns anos de expansão — e o impacto disso em produção costuma aparecer na pior hora possível.
Neste projeto, a substituição do backup lógico por uma estratégia baseada em backup fisico permitiu reduzir a janela de execução de mais de 25 horas para menos de 3 horas, mantendo compressão, criptografia e envio offsite para a nuvem. Um resultado expressivo sem substituição de infraestrutura — apenas com a revisão correta da estratégia.
Backup corporativo vai além de agendar um script. Envolve política de retenção, criptografia, testes periódicos de restauração, validação dos tempos de recuperação (RTO e RPO) e conformidade com regulamentações como a LGPD. Cada um desses pilares precisa estar alinhado com os objetivos do negócio.
Na Proactus Tecnologia, apoiamos empresas na estruturação e revisão de ambientes de backup corporativo — desde a análise do cenário atual até a implementação de rotinas seguras, automatizadas e auditáveis. Se o seu ambiente de banco de dados ainda depende de uma estratégia que nunca foi revisada, esse pode ser o momento certo para mudar isso.
Compartilhe
Dúvidas comuns sobre o assunto
Por que vocês escolheram LZ4 e não ZSTD, que gerou arquivos menores?
O ZSTD nível 3 produziu arquivos 16% menores que o LZ4, mas levou 2h50min contra 1h21min do LZ4 — mais que o dobro do tempo. Em um ambiente com disco HDD e rede com largura de banda limitada, o gargalo não é o tamanho do arquivo, mas o tempo de leitura do disco. O LZ4 é otimizado para velocidade e se mostrou a melhor relação entre compressão e desempenho no nosso hardware.
O hardware influencia tanto assim no tempo de backup?
Diretamente. Neste ambiente o servidor de backup utiliza HDD, que possui velocidade de leitura sequencial em torno de 150–200 MB/s. Em um servidor com SSD, essa velocidade sobe para 500–600 MB/s, e com NVMe pode ultrapassar 3.000 MB/s. O mesmo backup que levou 1h21min em HDD com LZ4 poderia ser concluído em minutos em hardware mais moderno. O disco é o principal gargalo nesse tipo de operação.
Se o disco fosse SSD ou NVMe, qual compressor seria mais indicado?
Em hardware mais rápido, o gargalo deixa de ser o disco e passa a ser a CPU. Nesse cenário o ZSTD se torna mais atrativo, pois a diferença de tempo entre os algoritmos diminui e o ganho em tamanho final — arquivos menores significam menos custo de armazenamento em nuvem — passa a compensar. A escolha do algoritmo de compressão deve sempre considerar o hardware disponível
A criptografia impactou muito o desempenho?
Sim, de forma mensurável. O pg_basebackup com LZ4 puro concluiu em 1h21min. Com a adição de criptografia AES-256 e fragmentação, o tempo subiu para 2h28min. Esse overhead é esperado — a criptografia exige processamento adicional de CPU para cada bloco de dados. Para ambientes corporativos, esse custo é justificado: dados de backup trafegando para a nuvem sem criptografia representam um risco real de exposição, especialmente em contextos regulados pela LGPD.
Por que fragmentar o backup?
Arquivos únicos de centenas de gigabytes apresentam problemas práticos: falhas de transferência exigem reiniciar o envio completo, alguns provedores de armazenamento em nuvem impõem limites de tamanho por arquivo, e a verificação de integridade fica mais difícil. A fragmentação em partes menores torna o processo mais resiliente, facilita reenvios parciais em caso de falha e simplifica a gestão dos arquivos no destino.
Alex Hinckel é fundador da Proactus Tecnologia, empresa de TI especialista em bancos de dados corporativos, com mais de 15 anos de experiência em infraestrutura e alta disponibilidade, garantindo a integridade e a performance de ambientes críticos.
Atua na implantação e gestão de PostgreSQL, MySQL e outras soluções Opensource, cuidando do monitoramento proativo e do ajuste fino (tuning) dos dados.
Você também pode gostar
