10
AlexHinckel
2 min de leitura ·

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étodoTempoTamanho
pg_dump original25h24min—
pg_basebackup + LZ41h21min426 GB
pg_basebackup + ZSTD nível 32h50min359 GB
pg_basebackup + LZ4 + AES-256 + split2h28min426 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.

Carregando publicação patrocinada...
1

Ja experimentou backup usando o WAL-G? Ele faz um backup base, e vai replicando os WAL files no seu storage de backup. Assim você tem um backup super granular, até minutos de granularidade, sem um incremento gigantesco no espaço.

1
1
1

Meus 2 cents,

Parabens pelo post !

Minha estrategia para backups eh via filesystem: uso o ZFS com snapshots.

Eh instantaneo, nao degrada, permite rollback em segundos ou ativacao de clone: eh absurdamente bom.

No caso do postgresql faco um pg_start_backup (ou pg_backup_start) antes para garantir o sync da memoria para fisico:

SELECT pg_start_backup('backup-2026-06-12-23-30');
rodo o script de snapshot do ZFS: zfs snapshot dsdata/postgresql@2026-06-12-23-30
SELECT pg_stop_backup();

E para manter o backup em nuvem, uso um segundo site tambem com ZFS com o script sanoid/syncoid para copiar direto de ZFS para ZFS (vai somente as diferencas/snapshots do ultimo backup, tambem eh absurdamente rapido).

Obrigado por compartilhar !

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

1

Bom post!
Se tratando de backups físicos, vejo que uma ferramenta muito utilizada em escala é o pgbackrest. Ele também faz o armazenamento e gerenciamento do WAL, o que permite o PITR. Sugiro dar uma lida e experimentar!

2

Obrigado pela sugestão!

Hoje a rotina com o pg_basebackup já contempla compressão, criptografia e fragmentação dos arquivos através de pipeline (pg_basebackup | openssl | split), o que tem atendido bem aos requisitos atuais.

Neste caso específico, trata-se de um backup completo semanal, e um dos pontos que ainda pretendo evoluir é justamente a questão dos backups incrementais e da retenção mais inteligente dos WALs. Pelo que tenho lido, o pgBackRest parece atender muito bem esse cenário, além de agregar PITR e outras funcionalidades interessantes para ambientes maiores.

Com certeza vou estudar e realizar alguns testes em breve.

Obrigado pela indicação e pelo compartilhamento da experiência!

1

Esses caras aí usam criptografia simétrica, eu prefiro fazer um fluxo com criptografia assimétrica, assim se alguém acessar a chave do CI ele só vai encontrar a chave de encriptação, a chave que abre nunca foi no CI nem em lugar nenhum, só comigo offline.