APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um backup lógico descreve objetos e dados para recriação; um backup físico preserva a estrutura necessária à recuperação do cluster com WAL. pg_dump de uma base não é um base backup para PITR e não inclui a criação de todas as roles globais. Planeia esses objetos separadamente, por exemplo com pg_dumpall --globals-only, protegendo material sensível. Um plano físico exige base backup adequado e a sequência WAL necessária, com retenção e timeline coerentes. Incrementais acrescentam dependências sobre backups anteriores e precisam de combinação apropriada antes da recuperação. Guarda o inventário destas dependências para não remover uma base ainda necessária a cópias posteriores.
Aplicação guiada
Num erro fictício de atualização de posições, define o ponto pretendido, isola o destino e preserva a origem para reconciliar movimentos válidos posteriores. pg_verifybackup deteta problemas de integridade dentro do seu âmbito, mas não substitui arrancar o servidor, validar dados e medir o serviço. Configuração, certificados e regras editadas manualmente não são recuperados por replay de WAL. Um archive_command que falha deve continuar a reportar falha até guardar corretamente os registos; sucesso falso destrói a confiança na cadeia. O relatório do ensaio separa tempo de restauro de dados, tempo até aplicação utilizável e perda observada, com ações sobre acessos e outras dependências.
Dados restaurados em 18 minutos e aplicação pronta aos 52: o resultado de serviço observado é 52 minutos.
Armadilhas comuns
Dump como base física; checksum como DR; zero exit sem cópia; configuração fora do plano.
Tópicos relacionados: Ligações, identidades e privilégios · Transações, bloqueios e retoma · Planos, índices e memória
Recuperabilidade exige artefactos, dependências e ensaio completo.
Referência: Base backups and WAL recovery · PostgreSQL 18 reference semantics;18.6 current stable at review