Como você faz backup e recuperação do PostgreSQL?

Question

Accepted Answer

PostgreSQL oferece vários métodos de **backup** — backups lógicos (`pg_dump`) e backups físicos (base backup + WAL para **recuperação pontual no tempo**). Uma estratégia sólida de backup e recuperação é essencial para proteger contra perda de dados, e crucialmente, **backups devem ser testados**.

## Backups lógicos — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` cria um backup lógico (SQL ou arquivo) de um banco de dados — portável (restaurável para diferentes versões/servidores), bom para bancos de dados menores, migrações e backups seletivos. Mas é um snapshot pontual no tempo (sem recuperação contínua).

## Backups físicos + Recuperação Pontual no Tempo (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

**PITR** é poderoso: ao arquivar WAL continuamente, você pode recuperar para qualquer momento — não apenas o último backup — o que é essencial para minimizar a perda de dados em desastres.

## Essenciais da estratégia de backup

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## A regra mais importante: TESTE seus backups

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## Por que isso importa

Backup e recuperação é conhecimento **crítico** para operar PostgreSQL responsavelmente — proteger contra perda de dados (falha de hardware, corrupção, exclusão acidental, desastres) é uma das responsabilidades mais importantes para qualquer banco de dados em produção, então entender estratégias de backup é conhecimento essencial de nível sênior.

Entender os métodos é necessário: **`pg_dump`** (backups lógicos — dumps SQL/arquivo portáveis, bons para bancos de dados menores, migrações e backups seletivos/entre versões, mas apenas snapshots pontuais) e **backups físicos com Recuperação Pontual no Tempo (PITR)** (base backup + arquivamento contínuo de WAL, permitindo recuperação para *qualquer* momento — o que é poderoso para minimizar perda de dados, como recuperar logo antes de um `DROP TABLE` acidental, essencial para dados críticos).

Conhecer os **essenciais da estratégia** (backups automatizados regulares, armazenamento fora do servidor e offshore, políticas de retenção, combinação de backups base com WAL para PITR em dados críticos, backup a partir de réplicas) é conhecimento operacional importante.

Mais criticamente, entender que **backups devem ser testados** — um backup não testado é não confiável e frequentemente falha exatamente quando necessário (corrupção, dados incompletos, processo de restauração desconhecido) — é um princípio vital, frequentemente negligenciado: testar restaurações regularmente é o que torna uma estratégia de backup realmente confiável.

Como a perda de dados pode ser catastrófica (e a recuperação só é possível com backups funcionando), e como uma estratégia apropriada (métodos de backup apropriados, PITR para perda mínima, armazenamento offshore, e crucialmente restaurações *testadas*) é o que protege os dados de uma organização, entender backup e recuperação do PostgreSQL é conhecimento crítico de nível sênior para operações responsáveis de banco de dados — uma responsabilidade de alto risco onde a diferença entre uma estratégia testada e uma não testada pode ser a diferença entre recuperar de um desastre e perder dados permanentemente, tornando-a um tópico essencial e frequentemente relevante para qualquer pessoa operando bancos de dados em produção.