Backup e PITR com pg_basebackup + arquivo de WAL (sem pgBackRest)

Backup físico com as ferramentas do próprio PostgreSQL, sem software adicional: arquivamento contínuo de WAL com archive_command, base backup noturno com pg_basebackup, retenção com pg_archivecleanup. Recuperação para um ponto no tempo / transação / restore point (recovery.signal, restore_command, recovery_target_*), timelines e um teste de restore periódico; no final você tem o WAL arquivado, um backup noturno e um caminho de volta já testado. Alternativas: se precisar de backup incremental/paralelo/criptografado, S3 e gestão de retenção pronta, use o guia do pgBackRest; para mover uma tabela/banco de dados ou recuperar uma única tabela, use backup lógico (pg_dump, sem PITR).

Topologia: 1 servidor; com streaming ou Patroni o diretório de arquivo é compartilhado por todos os nodes (NFS)

Cenários

• Configurar o arquivamento de WAL e o base backup noturno — Configuração inicial: arquivamento contínuo de WAL com archive_command, script do pg_basebackup, agendamento em /etc/cron.d, retenção e limpeza de WAL. archive_mode exige um reinício rápido, uma única vez.
• Recuperar até um ponto específico (PITR: tempo, xid, LSN, restore point) — Dados foram apagados/alterados por engano (DROP, DELETE, TRUNCATE) ou o servidor/disco foi perdido: o base backup é restaurado e o WAL arquivado é aplicado até o alvo. O cluster inteiro é parado e volta ao alvo; tudo o que veio depois do alvo é perdido.
• Teste de restore (em diretório separado, sem tocar em produção) — Para comprovar que o backup realmente restaura (recomendado uma vez por mês): o último base backup é verificado (pg_verifybackup), extraído em um diretório separado e iniciado em outra porta com o arquivo de WAL; o tempo (RTO) é medido. A produção não é tocada.
• Limpar base backups antigos e o arquivo de WAL — O disco do arquivo ou do backup está enchendo, ou a retenção mudou: os base backups antigos são apagados e o pg_archivecleanup remove o WAL anterior ao backup mais antigo (primeiro em dry-run). O banco de dados continua aberto.

Antes de começar

• PostgreSQL … instalado e em execução (pg-install); diretório de dados ….
• … e … estão em um disco/compartilhamento NFS separado do disco de dados, montado de forma persistente (fstab)… e no mesmo caminho em todos os servidores PostgreSQL (após um failover o novo primary deve gravar no mesmo arquivo)…. Espaço: (número de backups mantidos + 1) × tamanho dos dados compactados + volume diário de WAL × dias de retenção.
• Nenhuma outra ferramenta de arquivamento/backup (pgBackRest, Barman, WAL-G) está configurada; se duas ferramentas enviarem o mesmo WAL para lugares diferentes, as duas ficam incompletas.
• Relógios sincronizados por NTP (o horário alvo do PITR é interpretado pelo relógio do servidor).
• Há uma janela curta de reinício para a mudança de archive_mode.
• As aplicações estão paradas; está aceito que todas as alterações posteriores ao alvo serão perdidas.… Os standbys/replicas serão recriados após o restore.…

Fases do guia

• Configuração do arquivo de WAL e do base backup — Preparar os diretórios de arquivo e de backup · Escrever o script de arquivamento de WAL · Tornar o script executável e testá-lo · Gravar a configuração de arquivamento do PostgreSQL · Reiniciar o PostgreSQL · Gravar a configuração de arquivamento no Patroni (edit-config) …
• Teste de restore — Preparar o diretório do teste e escolher o último backup · Extrair e verificar o backup (pg_verifybackup) · Iniciar a instância de teste com o arquivo · Verificar os dados · Encerrar e limpar a instância de teste
• Retenção e limpeza de WAL — Backups, tamanho do arquivo e o WAL mais antigo necessário · Apagar os base backups fora da retenção · Mostrar primeiro a limpeza de WAL em dry-run · Limpar o arquivo de WAL · Verificar se o arquivamento continua funcionando