Backup do PostgreSQL

0:00 / 0:00

O pg_dump oferece quatro formatos de backup: Custom, Tar, Plain e Directory. Cada um organiza o arquivo de saída de um jeito diferente — e essa diferença importa muito se você quer compactar o backup depois pra versionar no Git ou no GitHub.

Os 4 formatos lado a lado

Formato	Flag	Comprimido internamente?	Restaura com
Custom	`-F c`	Sim (zlib)	`pg_restore`
Tar	`-F t`	Não	`pg_restore`
Plain	`-F p`	Não (texto puro)	`psql -f`
Directory	`-F d`	Sim (por arquivo)	`pg_restore -j N`

Plain — texto SQL puro

Arquivo de texto com comandos SQL (CREATE TABLE, INSERT, COPY). Se abrir no editor, dá pra ler.

Vantagens: legível, versionável com diff, comprime ~90% no 7zip.
Desvantagens: arquivo enorme no cru, sem restauração seletiva.
Restaura com: psql -f arquivo.sql

Custom — binário pré-comprimido

Formato binário do pgAdmin (default). Arquivo começa com o cabeçalho PGDMP e já é comprimido internamente com zlib.

Vantagens: sai pronto pequeno, permite restauração seletiva, suporta paralelismo no restore.
Desvantagens: não dá pra ler no editor, não comprime mais com 7zip (ver pegadinha abaixo).
Restaura com: pg_restore

A pegadinha do Custom — por que zipar não reduz

Compressão funciona procurando repetição. Quando um arquivo já foi comprimido, a repetição já foi consumida — não sobra o que explorar.

O Custom já passa pelo zlib quando é gerado. Pro 7zip que vier depois, o conteúdo parece ruído aleatório.

Exemplo real do teste:

Custom gerado: 45.8 MB
Custom dentro de 7zip: 45.5 MB — redução de 1%

É o mesmo motivo que zipar MP3, JPG, MP4 ou PDF não reduz nada. Todos já têm compressão interna.

Tar — container cru

Formato tar tradicional do Unix. Agrupa vários arquivos num só, sem comprimir. Por dentro tem um toc.dat (índice) + um arquivo por tabela.

Vantagens: como é cru, comprime muito bem depois. Suporta restauração seletiva.
Desvantagens: arquivo grande no cru.
Restaura com: pg_restore

Exemplo real do teste:

Tar gerado: 250 MB
Tar dentro de 7zip: 29 MB — redução de 88%

Directory — paralelismo pra banco grande

Gera uma pasta, não um arquivo. Cada tabela vira um arquivo próprio comprimido, mais um toc.dat de índice.

Vantagens: dump e restore em paralelo (-j N usa várias CPUs). Ideal pra banco grande.
Desvantagens: é pasta, precisa empacotar pra mover. Overkill pra banco pequeno.
Restaura com: pg_restore -j N

Experimento prático — o mesmo banco em cada formato

Caminho	Cru	Depois do 7zip	Redução
Custom + 7zip	45.8 MB	45.5 MB	1%
Tar + 7zip	250 MB	29 MB	88%

Surpreendente: o caminho mais eficiente pra ter um arquivo pequeno pra versionar é gerar em Tar ou Plain e comprimir depois — não o Custom, mesmo sendo o default do pgAdmin.

Qual usar na prática

Banco local, backup pra guardar: Custom. Default do pgAdmin, comprime razoável, um arquivo só, restaura seletivo.
Versionar no Git / GitHub: Tar + 7zip (combinação boa, 29 MB no teste) ou Plain + 7zip (ainda menor, mas perde restauração seletiva).
Banco grande, restore rápido: Directory com paralelismo (-j N).
Schema regenerável por scripts: não versionar o dump — coloca no .gitignore.

Limites do GitHub: arquivo acima de 50 MB gera warning; acima de 100 MB o push é bloqueado.

Lição geral sobre compressão

Compressão não funciona duas vezes. Se um formato já tem compressão interna, tentar zipar de novo é perda de tempo.

Vale pra MP3, MP4, JPG, PDF moderno, ZIP, DOCX, XLSX (todos ZIP por dentro) e dumps Custom do PostgreSQL.

Antes de compactar qualquer coisa, pergunte: "esse formato já é comprimido por dentro?" Se sim, não adianta.