Desligar archive_mode antes do failover pode custar seu backup no PostgreSQL

Em post publicado em 23 de setembro de 2026 no Planet PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, Stefan Fercot, mantenedor envolvido no ecossistema pgBackRest, descreve uma pergunta que surgiu nos canais da comunidade e que qualquer time que opera PostgreSQL em produção deveria levar a sério: um standby havia sido promovido a primário com archive_mode=off, e a equipe queria evitar reiniciar o novo primário para religar o archiving. A pergunta era direta: dava para ativar o archiving num standby mais abaixo na cadeia de replicação e tirar o backup do pgBackRest a partir dali, contornando o restart?

A tentativa esbarrou logo de cara no erro archive_mode must be enabled, mesmo usando --no-archive-mode-check. Só depois de remover as checagens direto do código-fonte do pgBackRest a equipe conseguiu uma prova de conceito "funcionando". Fercot foi taxativo na recomendação: voltar para uma configuração suportada, seja via restart, seja via um switchover controlado. O post existe para explicar por que essa recomendação não é conservadorismo gratuito, e o que exatamente se perde quando archive_mode fica desligado no momento errado.

archive_mode e archive_command não são a mesma coisa

O detalhe operacional que separa um incidente controlável de um incidente sem volta é simples de enunciar e fácil de esquecer sob pressão: mudar archive_mode exige reinício do PostgreSQL, enquanto mudar archive_command exige apenas um reload. Isso significa que, se um cluster nasce com archive_mode=on e archive_command apontando para algo inofensivo como /bin/true, ativar o archiving de verdade mais tarde é uma operação de reload, sem downtime. Se o cluster nasce com archive_mode=off, qualquer decisão de ativar archiving depois, inclusive no meio de um failover, exige exatamente o restart que a equipe do caso relatado por Fercot estava tentando evitar.

Essa é a recomendação que abre o post: pensar no archive_mode como parte do desenho inicial do cluster, não como um interruptor que se liga quando a crise já começou.

Reproduzindo o cenário: três nós, uma promoção, um erro

Para isolar o problema, Fercot montou um ambiente com três VMs AlmaLinux 10 rodando PostgreSQL 18 (pg1, pg2, pg3) em replicação em cascata (pg1 → pg2 → pg3), com pgBackRest configurado no primário e backups completos funcionando normalmente. Os dois standbys foram deliberadamente configurados com archive_mode=off, reproduzindo o cenário problemático.

Após inserir carga com pgbench, o primário (pg1) foi derrubado e pg2 promovido via pg_promote() seguido de pg_switch_wal(). Nesse ponto, uma tentativa de backup no novo primário falhou com o erro [087]: archive_mode must be enabled, exatamente como no relato original da comunidade.

A equipe tentou então o caminho alternativo: ligar archive_mode=always (que faz standbys arquivarem WAL também), configurar backup-standby=y e acesso SSH entre os hosts para tirar o backup a partir de pg3, standby de pg2. Mesmo assim, o backup falhou com --no-archive-mode-check desabilitado. O motivo, segundo o post, é que essa checagem não existe apenas para bloquear burocracia: ela protege contra o cenário em que múltiplos arquivadores (primário e standby, sob archive_mode=always) escrevem segmentos de WAL logicamente iguais mas com checksums diferentes no mesmo repositório, o que corromperia silenciosamente a cadeia de recuperação. O código do pgBackRest verifica tanto que archive_mode está ativo no primário quanto que o archive_command de fato invoca um subcomando do próprio pgBackRest, justamente para impedir esse tipo de backup logicamente inconsistente.

A correção suportada, mostrada no post, foi religar archive_mode (não always, apenas on) e configurar archive_command corretamente tanto em pg2 quanto em pg3 -- exigindo o restart que a equipe original queria evitar. Só depois disso o backup a partir do standby funcionou sem hacks.

O gap que o backup bem-sucedido não revela

A parte mais importante do post não é o erro que trava o backup, e sim o que aconteceria se alguém insistisse em burlar a checagem. Inspecionando o repositório do pgBackRest com pgbackrest repo-ls, Fercot mostra que os segmentos de WAL da timeline antiga (0000000100000000) terminam num ponto, e os da nova timeline (0000000200000000) começam adiante, sem nenhum segmento cobrindo o intervalo entre os dois. Falta também o arquivo .history que registraria exatamente onde e quando ocorreu a troca de timeline (00000002.history, no exemplo, contém a linha 1 0/920000A0 no recovery target specified).

Sem esse arquivo e sem os segmentos intermediários, não há como o pgBackRest reconstruir, a partir do próprio repositório, o caminho de recuperação que liga a timeline original à nova. Um backup que "funcionou" tecnicamente pode, portanto, não corresponder a um ponto de recuperação real e consistente -- o que só fica evidente quando alguém de fato precisa restaurar, momento em que já é tarde para consertar a configuração.

O que muda para quem projeta failover e mantém runbooks

Para equipes de engenharia responsáveis por runbooks de alta disponibilidade em PostgreSQL, o caso traz três implicações concretas:

• Configurar archive_mode=on desde a criação do cluster, mesmo antes de o pipeline de archiving estar pronto, usando archive_command = /bin/true como placeholder. Isso transforma a futura ativação do archiving real numa mudança de reload, não de restart -- e elimina a tentação de burlar checagens sob pressão de incidente.
• Tratar promoção de standby e archiving como parte do mesmo runbook, não como etapas independentes. Se o standby que vai virar primário está com archive_mode=off, o runbook precisa prever o restart ou, preferencialmente, um switchover controlado (que permite ao antigo primário se rebaixar de forma ordenada, preservando a continuidade de WAL) em vez de uma promoção seguida de tentativa de correção a posteriori.
• Não tratar "o backup rodou sem erro" como prova de recuperação íntegra. O próprio Fercot demonstra, na seção final do post, que é possível remover as checagens do código-fonte do pgBackRest (numa versão de desenvolvimento, 2.60.0dev) e obter um backup que emite apenas um aviso (WARN: archive_mode is off) em vez de falhar. Isso prova que o software pode ser forçado a aceitar a operação, não que a cadeia de recuperação resultante seja confiável. As checagens existem porque a superfície de erro relevante -- gaps de timeline, checksums divergentes de WAL sob archive_mode=always -- não aparece no momento do backup, e sim no momento da restauração, quando não há mais margem para reconfigurar nada.

O ângulo prático para quem mantém infraestrutura de banco é que a decisão sobre archive_mode deveria ser tomada no dia em que o cluster nasce, documentada no runbook de failover, e testada com um switchover de verdade em ambiente de homologação -- não descoberta durante uma promoção de emergência, quando a única saída disponível é editar o código-fonte de uma ferramenta de backup e torcer.

Fonte: Planet PostgreSQL