Recuperação para um Ponto no Tempo Detalhada

Recuperação para um ponto no tempo, ou PITR, é a capacidade que transforma um único backup em um histórico contínuo e rebobinável de seu cluster, em vez de um único snapshot fixo.

Esta página explica o mecanismo por trás dessa capacidade: como funciona a reprodução de WAL, por que cada alvo de recuperação é realmente apenas uma condição de parada e o que acontece com a identidade do cluster depois que você o rebobina e o retoma.

Resumo

• PITR reproduz o write-ahead log (WAL) a partir de um backup base até atingir um ponto de parada escolhido, reconstruindo o cluster exatamente como ele existia naquele momento.
• Por que Importa: É o único método de recuperação preciso o suficiente para desfazer uma única transação incorreta sem descartar todas as alterações que ocorreram em torno dela.
• Conceitos Chave: backup base, reprodução de WAL, alvo de recuperação, linha do tempo (timeline), objetivo de ponto de recuperação (RPO), promoção.
• Quando Usar: Utilize PITR quando você souber aproximadamente quando algo deu errado e precisar de precisão cirúrgica em vez de uma restauração completa para o último backup completo.
• Limitações / Compensações: PITR só pode rebobinar até onde seu WAL arquivado alcança, e reproduzir um histórico extenso de WAL para um ponto antigo pode levar mais tempo do que uma restauração nova.
• Tópicos Relacionados: Fundamentos de backup e restauração, RTO e RPO de recuperação de desastres, replicação de streaming, arquivamento de WAL.

Fundamentos

Um backup base por si só fornece apenas um momento no tempo, o instante em que terminou, e nada antes ou depois dele.

O arquivamento de WAL estende esse único momento para um histórico contínuo, pois cada alteração que o PostgreSQL faz é primeiro escrita no write-ahead log antes de tocar em um arquivo de dados.

A recuperação funciona reproduzindo esse log contra o backup base, aplicando cada alteração registrada na ordem exata em que ocorreu originalmente.

Como a reprodução é determinística, o cluster passa por todos os estados intermediários que o original passou, não apenas o final, o que permite que você pare a reprodução em qualquer ponto desse caminho.

Um alvo de recuperação é simplesmente a instrução que diz à reprodução quando parar, e o PostgreSQL aceita vários tipos: um tempo de relógio, um ID de transação, um número de sequência de log (LSN) ou um ponto de restauração nomeado criado com antecedência.

Nenhum desses alvos são mecanismos fundamentalmente diferentes, são apenas sistemas de coordenadas diferentes para apontar para o mesmo fluxo de WAL subjacente.

A forma textual do processo se parece com isto:

[Backup base] --reproduz segmento WAL 1--> --reproduz segmento WAL 2--> ... --PARA no alvo-->
     T0                                                                    T1 (ponto escolhido)

Tudo entre o backup base e o alvo é reproduzido; tudo após o alvo é descartado da perspectiva da instância recuperada, mesmo que ainda exista no arquivo.

Mecânicas e Interações

O objetivo de ponto de recuperação que o PITR pode entregar é limitado por um fato simples: você nunca pode recuperar além do último segmento de WAL que foi arquivado com sucesso.

-- O número que realmente define seu limite de PITR
SELECT archived_count, last_archived_wal, last_archived_time, failed_count
FROM pg_stat_archiver;

Se failed_count estiver aumentando, a cadeia de arquivo tem uma lacuna, e qualquer alvo de recuperação além dessa lacuna se torna inatingível, não importa quão recente seja seu backup base.

A promoção é o momento em que a recuperação termina e o cluster começa a aceitar gravações novamente, e tem uma consequência que surpreende muitos operadores: ela cria uma nova linha do tempo (timeline).

O PostgreSQL numera as linhas do tempo começando em 1, e cada promoção após uma recuperação incrementa esse número, escrevendo um arquivo .history que registra exatamente onde ocorreu a ramificação e de qual linha do tempo ela se originou.

Isso existe porque o WAL que a instância recuperada gera após a promoção é diferente do WAL que a instância original teria gerado após esse mesmo ponto, então o PostgreSQL precisa de uma maneira de distinguir esses dois futuros.

Esse mecanismo de linha do tempo é também o motivo pelo qual você não pode simplesmente continuar reproduzindo um arquivo antigo além do ponto de ramificação de uma instância promovida, porque o arquivo na nova linha do tempo diverge daquele que o primário antigo ainda estava escrevendo.

Um alvo de recuperação é avaliado contra a linha do tempo que a instância em recuperação está seguindo, então recuperar uma segunda vez do mesmo backup base para um alvo diferente e posterior ainda funciona, mas recuperar para frente após uma promoção anterior requer seguir o arquivo de histórico de linha do tempo correto.

A reprodução de WAL também é o que torna o PITR fundamentalmente diferente de restaurar uma réplica ou um snapshot: a promoção de réplica move você para frente para o estado atual da réplica, enquanto o PITR pode movê-lo para qualquer estado que o arquivo de WAL ainda se lembre, incluindo estados anteriores ao que qualquer réplica ativa atualmente possui.

Considerações Avançadas e Aplicações

Escolher como se recuperar de um determinado incidente significa escolher a ferramenta cuja precisão corresponde ao problema, e o PITR nem sempre é a ferramenta certa, mesmo quando está disponível.

Serviços gerenciados na nuvem expõem o PITR através de uma interface diferente, mas não um mecanismo diferente: RDS, Aurora e Neon ainda combinam uma imagem base com um log contínuo de alterações, eles simplesmente ocultam o archive_command e a configuração manual do alvo de recuperação por trás de uma ação no console que restaura para um novo endpoint.

Clusters grandes tornam a velocidade de reprodução de WAL uma preocupação de capacidade de primeira classe, porque reproduzir dias de WAL contra um backup base de vários terabytes pode transformar um "desfazer rápido" em uma operação de horas, a menos que a reprodução seja paralelizada ou o backup base seja mantido atualizado o suficiente para encurtar a janela de reprodução.

A política de retenção para o arquivo de WAL é efetivamente a política de retenção para toda a sua capacidade de PITR, portanto, um requisito de conformidade para recuperar de erros descobertos semanas depois se traduz diretamente em um requisito de retenção de WAL medido em semanas, não em dias.

A precisão do PITR também tem uma dimensão de segurança que vale a pena mencionar, porque a capacidade de rebobinar para qualquer ponto em uma janela retida é exatamente a capacidade que um respondedor de incidentes precisa após uma conta comprometida ter feito alterações não autorizadas, desde que o próprio arquivo não tenha sido comprometido.

Concepções Errôneas Comuns

• "PITR restaura o banco de dados no local." A recuperação sempre opera em uma cópia separada do diretório de dados ou em uma nova instância, nunca nos arquivos ativos de um cluster de produção em execução.
• "Qualquer alvo de recuperação funciona, desde que o WAL exista em algum lugar." Um alvo além do último segmento arquivado com sucesso é inatingível, então um arquivo com falha ou com lacunas encolhe silenciosamente sua janela de recuperação real.
• "Promover após PITR apenas retoma a operação normal." A promoção cria uma nova linha do tempo, e entender essa ramificação é importante para quem mais tarde precisar recuperar novamente ou reconciliar dados entre linhas do tempo.
• "PITR pode ser construído a partir de um dump lógico se você também mantiver o WAL por perto." A reprodução de WAL só faz sentido contra um backup base físico, porque os registros de WAL gravam alterações físicas ou lógicas em relação a um estado de arquivo inicial conhecido, não contra uma exportação SQL arbitrária sem uma posição de WAL correspondente.
• "Um tempo menor para o alvo sempre significa uma recuperação mais rápida." O tempo de recuperação depende de quanto WAL precisa ser reproduzido para atingir esse alvo, não de quão perto o alvo está de "agora", então um alvo antigo logo após um backup base novo pode ser mais rápido do que um alvo recente após um antigo.

FAQs

Relacionados

• Noções Básicas de PITR - a receita concreta de ativação e restauração que o modelo mental desta página suporta
• archive_mode & archive_command - como o WAL realmente chega ao armazenamento durável
• Opções de Alvo de Recuperação - os parâmetros que expressam uma condição de parada
• Runbook de Simulação de PITR - medindo o tempo real de recuperação contra este modelo
• Fundamentos de Backup e Restauração - a camada de backup base sobre a qual o PITR é construído
• RTO & RPO Desmistificados - como a precisão do PITR se encaixa no quadro geral de recuperação

Versões do Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17).