Opções de Destino de Recuperação

Os destinos de recuperação informam ao PostgreSQL quando parar a repetição de WAL durante o PITR. Escolha tempo, ID de transação (XID), LSN ou um ponto de restauração nomeado criado antes de um trabalho arriscado.

Receita

Recuperar para um segundo antes de um DROP acidental usando timestamp.

# postgresql.auto.conf na instância de restauração
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-07-09 14:31:58+00'
recovery_target_action = 'promote'

-- Antes da migração arriscada no primário
SELECT pg_create_restore_point('before_migration_20260709');

Quando usar isso: Recuperação de precisão quando você sabe aproximadamente quando o erro aconteceu ou marcou o momento com antecedência.

Exemplo de Trabalho

Compare os tipos de destino e os limites inclusivos/exclusivos:

-- Ponto de restauração nomeado (primário, antes da mudança)
SELECT pg_create_restore_point('pre_deploy_v42');

# Opção A: destino nomeado
recovery_target_name = 'pre_deploy_v42'
recovery_target_action = 'promote'
 
# Opção B: timestamp (inclusivo por padrão no PG 18)
recovery_target_time = '2026-07-09 14:31:58+00'
recovery_target_inclusive = on
 
# Opção C: ID de transação (avançado)
# recovery_target_xid = '1234567'

-- Após a recuperação ser concluída
SELECT pg_is_in_recovery();  -- false após promote
-- Verificar se a alteração incorreta está ausente
SELECT to_regclass('public.dropped_table');

O que isso demonstra:

pg_create_restore_point registra um rótulo no WAL para momentos exatos conhecidos pela equipe.
recovery_target_time precisa de um literal ciente do fuso horário.
recovery_target_action = 'promote' abre o banco de dados para conexões após o destino ser alcançado.

Mergulho Profundo

Parâmetros de Destino

Parâmetro	Para em
`recovery_target_time`	Timestamp (use string `timestamptz`)
`recovery_target_xid`	ID de Transação
`recovery_target_lsn`	Número de sequência de log
`recovery_target_name`	Rótulo de `pg_create_restore_point`
`recovery_target`	Alias; define uma string de destino genérica
`recovery_target_inclusive`	Incluir (`on`) ou excluir (`off`) o registro correspondente

recovery_target_action

Valor	Comportamento
`pause`	Pausa a recuperação no destino; aguarda `pg_wal_replay_resume()`
`promote`	Termina a recuperação e aceita conexões
`shutdown`	Para a instância no destino (inspecionar antes de promover)

Encontrando o Tempo Certo

-- No primário (se ainda estiver ativo): log de auditoria ou timestamps da aplicação
SELECT now();
 
-- pg_audit ou logs da aplicação estreitam o segundo do DROP

Use recovery_target_action = 'pause' primeiro se não tiver certeza; inspecione os dados, depois promova.

Armadilhas

Hora local sem offset - Bugs de horário de verão movem o ponto de recuperação. Correção: Sempre use +00 ou zona explícita.
Destino após o último WAL arquivado - A recuperação para no final do WAL disponível, não no destino. Correção: Garanta que a cadeia de arquivamento esteja completa até o momento desejado.
Inclusivo com um de diferença na transação - Linha incorreta ainda visível. Correção: Restaure em teste em um ambiente limpo; ajuste recovery_target_inclusive.
Sem ponto de restauração antes da implantação - Apenas recuperação de tempo imprecisa. Correção: pg_create_restore_point obrigatório na lista de verificação de alterações.
Promover antes da validação - Produção aberta com dados incorretos. Correção: pause + verifique primeiro na instância de recuperação.

Alternativas

Alternativa	Use Quando	Não Use Quando
`recovery_target_lsn`	Você tem o LSN exato das ferramentas `pg_walfile_name`	Operadores humanos escolhem o tempo
pgBackRest `--target`	Ferramenta de backup unificada	Apenas diretórios de arquivamento manuais
Flashback de tabela (desfazer lógico)	Tabela pequena, dump recente	Erro em todo o cluster

FAQs

Destino nomeado vs. por tempo?

Nomeado é exato para o marcador da equipe; tempo requer correlação de logs, mas não precisa de chamada de API de previsão.

Posso recuperar para o mais recente?

Omita o destino de recuperação; a recuperação repete todo o WAL disponível e depois promove com recovery.signal removido ou gatilho promote.

recovery_target_xid quando?

Quando os logs mostram o txid exato do snapshot pg_current_xact_id() antes do bug.

Múltiplos destinos definidos?

O PostgreSQL usa um; configurações conflitantes geram erro ou priorizam conforme a documentação. Defina apenas um tipo de destino.

Patroni PITR?

O Patroni pode inicializar um novo cluster a partir de um backup com parâmetros de recuperação; não no local em um líder em execução.

Relacionados

Noções Básicas de PITR - fluxo geral
archive_mode & archive_command - fornecimento de WAL
Manual de Exercícios de PITR - prática de destinos
Noções Básicas de Gerenciamento de Mudanças - pontos de restauração em alterações

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.

Opções de Destino de Recuperação

Receita

Recuperar para um segundo antes de um DROP acidental usando timestamp.

# postgresql.auto.conf na instância de restauração
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-07-09 14:31:58+00'
recovery_target_action = 'promote'

-- Antes da migração arriscada no primário
SELECT pg_create_restore_point('before_migration_20260709');

Quando usar isso: Recuperação de precisão quando você sabe aproximadamente quando o erro aconteceu ou marcou o momento com antecedência.

Exemplo de Trabalho

Compare os tipos de destino e os limites inclusivos/exclusivos:

-- Ponto de restauração nomeado (primário, antes da mudança)
SELECT pg_create_restore_point('pre_deploy_v42');

# Opção A: destino nomeado
recovery_target_name = 'pre_deploy_v42'
recovery_target_action = 'promote'
 
# Opção B: timestamp (inclusivo por padrão no PG 18)
recovery_target_time = '2026-07-09 14:31:58+00'
recovery_target_inclusive = on
 
# Opção C: ID de transação (avançado)
# recovery_target_xid = '1234567'

-- Após a recuperação ser concluída
SELECT pg_is_in_recovery();  -- false após promote
-- Verificar se a alteração incorreta está ausente
SELECT to_regclass('public.dropped_table');

O que isso demonstra:

pg_create_restore_point registra um rótulo no WAL para momentos exatos conhecidos pela equipe.
recovery_target_time precisa de um literal ciente do fuso horário.
recovery_target_action = 'promote' abre o banco de dados para conexões após o destino ser alcançado.

Mergulho Profundo

Parâmetros de Destino

Parâmetro	Para em
`recovery_target_time`	Timestamp (use string `timestamptz`)
`recovery_target_xid`	ID de Transação
`recovery_target_lsn`	Número de sequência de log
`recovery_target_name`	Rótulo de `pg_create_restore_point`
`recovery_target`	Alias; define uma string de destino genérica
`recovery_target_inclusive`	Incluir (`on`) ou excluir (`off`) o registro correspondente

recovery_target_action

Valor	Comportamento
`pause`	Pausa a recuperação no destino; aguarda `pg_wal_replay_resume()`
`promote`	Termina a recuperação e aceita conexões
`shutdown`	Para a instância no destino (inspecionar antes de promover)

Encontrando o Tempo Certo

-- No primário (se ainda estiver ativo): log de auditoria ou timestamps da aplicação
SELECT now();
 
-- pg_audit ou logs da aplicação estreitam o segundo do DROP

Use recovery_target_action = 'pause' primeiro se não tiver certeza; inspecione os dados, depois promova.

Armadilhas

Hora local sem offset - Bugs de horário de verão movem o ponto de recuperação. Correção: Sempre use +00 ou zona explícita.
Destino após o último WAL arquivado - A recuperação para no final do WAL disponível, não no destino. Correção: Garanta que a cadeia de arquivamento esteja completa até o momento desejado.
Inclusivo com um de diferença na transação - Linha incorreta ainda visível. Correção: Restaure em teste em um ambiente limpo; ajuste recovery_target_inclusive.
Sem ponto de restauração antes da implantação - Apenas recuperação de tempo imprecisa. Correção: pg_create_restore_point obrigatório na lista de verificação de alterações.
Promover antes da validação - Produção aberta com dados incorretos. Correção: pause + verifique primeiro na instância de recuperação.

Alternativas

Alternativa	Use Quando	Não Use Quando
`recovery_target_lsn`	Você tem o LSN exato das ferramentas `pg_walfile_name`	Operadores humanos escolhem o tempo
pgBackRest `--target`	Ferramenta de backup unificada	Apenas diretórios de arquivamento manuais
Flashback de tabela (desfazer lógico)	Tabela pequena, dump recente	Erro em todo o cluster

FAQs

Destino nomeado vs. por tempo?

Nomeado é exato para o marcador da equipe; tempo requer correlação de logs, mas não precisa de chamada de API de previsão.

Posso recuperar para o mais recente?

Omita o destino de recuperação; a recuperação repete todo o WAL disponível e depois promove com recovery.signal removido ou gatilho promote.

recovery_target_xid quando?

Quando os logs mostram o txid exato do snapshot pg_current_xact_id() antes do bug.

Múltiplos destinos definidos?

O PostgreSQL usa um; configurações conflitantes geram erro ou priorizam conforme a documentação. Defina apenas um tipo de destino.

Patroni PITR?

O Patroni pode inicializar um novo cluster a partir de um backup com parâmetros de recuperação; não no local em um líder em execução.

Relacionados

Noções Básicas de PITR - fluxo geral
archive_mode & archive_command - fornecimento de WAL
Manual de Exercícios de PITR - prática de destinos
Noções Básicas de Gerenciamento de Mudanças - pontos de restauração em alterações

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.

Opções de Destino de Recuperação

Buscar na documentação

Opções de Destino de Recuperação