Backup PostgreSQL de 25 horas para menos de 3 — sem trocar nada
Aqui na nossa empresa de TI o backup em nuvem do PostgreSQL em um de nossos clientes estava levando 25 horas. Todo dia. Numa base de 600 GB.
Não era um problema novo — era uma rotina com pg_dump que funcionou por anos e nunca foi revisada enquanto a base dobrava de tamanho.
A solução não veio de hardware novo. Veio de trocar a estratégia.
O que mudamos
Saímos do pg_dump (backup lógico) e fomos pro pg_basebackup (backup físico do cluster). A diferença prática: em vez de serializar objeto por objeto, ele lê os arquivos físicos do disco de forma sequencial — muito mais eficiente em bases grandes.
Testamos algumas combinações:
| Método | Tempo | Tamanho |
|---|---|---|
pg_dump original | 25h24min | — |
pg_basebackup + LZ4 | 1h21min | 426 GB |
pg_basebackup + ZSTD nível 3 | 2h50min | 359 GB |
pg_basebackup + LZ4 + AES-256 + split | 2h28min | 426 GB |
LZ4 ganhou do ZSTD aqui — mas tem um porém
O ZSTD gerou arquivos 16% menores, mas levou o dobro do tempo. Em servidor com HDD (~150 MB/s de leitura), o gargalo é o disco, não a CPU — então velocidade de compressão importa mais que taxa de compressão.
Em SSD ou NVMe a conta muda. O ZSTD passaria a fazer mais sentido.
Resultado
De 25h24min para 2h28min, com compressão, criptografia AES-256 e envio offsite pra nuvem.
Alguém aqui já otimizou backup de Postgres em produção? Curioso pra saber se chegaram a testar outros algoritmos ou abordagens diferentes.