No post anterior da nossa série Guia de Sobrevivência: Backup e Manutenção no Postgres, nós desvendamos a diferença entre o pg_dump e o pg_dumpall e vimos a importância de salvar as roles globais. Agora que você já sabe o que extrair, precisamos falar sobre como extrair.

Se você simplesmente roda pg_dump meu_banco > backup.sql, você está usando o formato padrão em texto puro. Para um banco de dados de estudos ou com poucos megabytes, isso funciona bem. Mas se a sua aplicação cresceu e o banco já bateu a casa dos gigabytes (ou terabytes), continuar usando esse formato é uma receita certa para backups lentos e janelas de manutenção estouradas.

Hoje, vamos destrinchar a flag -F (--format) do pg_dump, entender os 4 formatos disponíveis e aprender o “pulo do gato” para reduzir o tempo de backup drasticamente usando múltiplos jobs em paralelo.

Os 4 Formatos do pg_dump

O PostgreSQL oferece quatro formas de empacotar o seu backup. A escolha do formato muda completamente o tamanho do arquivo final, a velocidade de geração e o nível de flexibilidade que você terá na hora do restore.

1. Plain Text (-F p) — O Tradicional (e perigoso)

É o formato padrão se você não passar a flag -F. Ele gera um arquivo .sql de texto puro contendo todos os comandos necessários (CREATE TABLE, INSERT, etc.) para reconstruir o banco.

• Vantagem: Pode ser lido e editado em qualquer editor de texto. Pode ser restaurado com um simples psql banco < backup.sql.
• Desvantagem: Não aceita compressão nativa avançada, os arquivos ficam gigantescos e você não consegue escolher restaurar apenas uma tabela específica a partir dele de forma nativa. O restore é obrigatoriamente sequencial e lento.

2. Tar (-F t) — O Legado

Gera um arquivo .tar pré-formatado.

• Vantagem: Permite que você use o pg_restore para selecionar quais objetos quer trazer de volta.
• Desvantagem: Não suporta paralelismo, é limitado em tamanho de arquivo por limitações históricas do formato tar e, honestamente, caiu em desuso após o surgimento dos próximos dois formatos.

3. Custom (-F c) — O Canivete Suíço

Este é o queridinho dos DBAs para bancos de pequeno e médio porte. Ele gera um arquivo binário proprietário do Postgres.

• Vantagem: É compactado por padrão (reduzindo muito o espaço em disco). Dá total flexibilidade ao pg_restore para reordenar itens, selecionar apenas esquemas específicos ou ignorar erros.
• Desvantagem: O backup em si roda em uma única thread (sequencial). Para bancos massivos, o tempo de geração pode se tornar um problema.

4. Directory (-F d) — O Rei da Performance

Em vez de um único arquivo, o formato de diretório cria uma pasta no seu servidor. Dentro dela, ele quebra os dados em múltiplos arquivos compactados, separando tabelas e metadados.

• Vantagem: É o único formato que permite compressão nativa paralela e a gravação simultânea de arquivos. Ele é a chave para lidar com bancos gigantes.
• Desvantagem: O resultado é uma pasta cheia de arquivos, o que exige um pouco mais de cuidado na hora de mover ou compactar para enviar para o S3, por exemplo.

O Gancho: Economizando tempo com múltiplos Jobs (-j)

Aqui está o segredo que separa os juniores dos seniores na administração de bancos de dados.

Quando você faz um backup tradicional, o Postgres usa apenas um núcleo (CPU) do seu servidor para ler os dados, compactar e salvar no disco. Se o seu servidor tem 16 núcleos de CPU e você está usando apenas um, você está desperdiçando precioso poder de processamento enquanto a janela de backup da madrugada vai ficando cada vez menor.

Combinando o formato Directory (-F d) com a flag Jobs (-j), você diz ao pg_dump para abrir conexões paralelas com o banco e despejar os dados simultaneamente.

O Comando de Alta Performance

Se você tem um banco de 50GB ou 100GB e quer fazer o backup na velocidade máxima que o seu disco e CPU aguentam, o comando é este:

Bash

pg_dump -U postgres -h localhost -F d -j 4 -v -f /caminho/do/backup_diretorio meu_banco_gigante

• -F d: Ativa o formato de diretório (obrigatório para usar o -j).
• -j 4: Cria 4 workers paralelos. O pg_dump vai despejar até 4 tabelas ao mesmo tempo.
• -f /caminho/do/...: Aponta para a pasta vazia onde o backup será gerado.

💡 Regra de Ouro para a flag -j: Não aloque mais jobs do que o número de núcleos de CPU disponíveis no seu servidor de banco de dados. Uma boa prática é usar cerca de 75% das CPUs disponíveis em horários de baixo movimento (ex: se o servidor tem 8 cores, use -j 6), garantindo que o Postgres ainda tenha fôlego para responder a eventuais queries da aplicação.

Resumo Comparativo: Qual formato escolher?

Formato	Flag	Compactado?	Suporta -j (Paralelo)?	Ferramenta de Restore	Indicado para
Plain	-F p	Não	Não	psql	Bancos pequenos (< 1GB), scripts de migração rápida.
Tar	-F t	Não	Não	pg_restore	Casos legados específicos (evite se puder).
Custom	-F c	Sim	Não	pg_restore	Padrão ouro para bancos de até ~30GB a 50GB.
Directory	-F d	Sim	Sim	pg_restore	Bancos gigantes, ambientes de produção críticos.

Conclusão

Parar de usar o formato padrão .sql e adotar o formato Directory com múltiplos jobs pode reduzir o tempo de backup de horas para minutos. Além disso, os arquivos gerados ficam prontos para uma restauração também ultraveloz usando o pg_restore (assunto que veremos mais à frente na série).

No próximo post, vamos refinar ainda mais nossa estratégia e aprender como fazer backups cirúrgicos: extrair apenas tabelas específicas, ignorar dados históricos pesados ou extrair puramente a estrutura do banco. Até lá!

E na sua empresa, qual formato vocês utilizam hoje? O backup da madrugada está demorando mais do que deveria? Deixe seu relato nos comentários!