Turning off archive_mode before failover can cost you your PostgreSQL backup

In a post published on September 23, 2026 on Planet PostgreSQL, Stefan Fercot, a maintainer involved in the pgBackRest ecosystem, describes a question that came up in community channels, one that any team running PostgreSQL in production should take seriously: a standby had been promoted to primary with archive_mode=off, and the team wanted to avoid restarting the new primary just to turn archiving back on. The question was direct: could archiving be enabled on a standby further down the replication chain and pgBackRest's backup taken from there, bypassing the restart?

The attempt immediately ran into the archive_mode must be enabled error, even when using --no-archive-mode-check. Only after removing the checks directly from pgBackRest's source code did the team manage to get a "working" proof of concept. Fercot was categorical in his recommendation: go back to a supported configuration, whether via restart or via a controlled switchover. The post exists to explain why that recommendation isn't gratuitous conservatism, and exactly what is lost when archive_mode is turned off at the wrong moment.

archive_mode and archive_command are not the same thing

The operational detail that separates a controllable incident from one with no way back is simple to state and easy to forget under pressure: changing archive_mode requires a PostgreSQL restart, while changing archive_command only requires a reload. This means that if a cluster is born with archive_mode=on and archive_command pointing to something harmless like /bin/true, enabling real archiving later is a reload operation, with no downtime. If the cluster is born with archive_mode=off, any decision to enable archiving later, including in the middle of a failover, requires exactly the restart the team in the case reported by Fercot was trying to avoid.

That's the recommendation that opens the post: think of archive_mode as part of the cluster's initial design, not as a switch you flip once the crisis has already begun.

Reproducing the scenario: three nodes, one promotion, one error

To isolate the problem, Fercot set up an environment with three AlmaLinux 10 VMs running PostgreSQL 18 (pg1, pg2, pg3) in cascading replication (pg1 → pg2 → pg3), with pgBackRest configured on the primary and full backups working normally. Both standbys were deliberately configured with archive_mode=off, reproducing the problematic scenario.

After inserting load with pgbench, the primary (pg1) was taken down and pg2 promoted via pg_promote() followed by pg_switch_wal(). At that point, a backup attempt on the new primary failed with the error [087]: archive_mode must be enabled, exactly as in the original community report.

The team then tried the alternative path: turning on archive_mode=always (which makes standbys archive WAL as well), configuring backup-standby=y and SSH access between hosts to take the backup from pg3, a standby of pg2. Even so, the backup failed with --no-archive-mode-check disabled. The reason, according to the post, is that this check doesn't exist just to block bureaucracy: it protects against the scenario where multiple archivers (primary and standby, under archive_mode=always) write WAL segments that are logically identical but have different checksums in the same repository, which would silently corrupt the recovery chain. pgBackRest's code checks both that archive_mode is active on the primary and that archive_command actually invokes a pgBackRest subcommand itself, precisely to prevent this kind of logically inconsistent backup.

The supported fix, shown in the post, was to turn archive_mode back on (not always, just on) and configure archive_command correctly on both pg2 and pg3, requiring the restart the original team wanted to avoid. Only after that did the backup from the standby work without hacks.

The gap a successful backup doesn't reveal

The most important part of the post isn't the error that blocks the backup, but what would happen if someone insisted on bypassing the check. Inspecting the pgBackRest repository with pgbackrest repo-ls, Fercot shows that the WAL segments from the old timeline (0000000100000000) end at one point, and those from the new timeline (0000000200000000) begin further ahead, with no segment covering the gap between the two. The .history file that would record exactly where and when the timeline switch occurred is also missing (00000002.history, in the example, contains the line 1 0/920000A0 no recovery target specified).

Without this file and without the intermediate segments, there's no way for pgBackRest to reconstruct, from the repository itself, the recovery path that links the original timeline to the new one. A backup that "worked" technically may therefore not correspond to a real, consistent recovery point, something that only becomes evident when someone actually needs to restore, at which point it's already too late to fix the configuration.

What changes for those who design failover and maintain runbooks

For engineering teams responsible for PostgreSQL high-availability runbooks, the case brings three concrete implications:

• Configure archive_mode=on from the moment the cluster is created, even before the archiving pipeline is ready, using archive_command = /bin/true as a placeholder. This turns the future activation of real archiving into a reload change, not a restart, and removes the temptation to bypass checks under incident pressure.
• Treat standby promotion and archiving as part of the same runbook, not as independent steps. If the standby that will become primary has archive_mode=off, the runbook needs to account for the restart or, preferably, a controlled switchover (which lets the old primary demote itself in an orderly way, preserving WAL continuity) instead of a promotion followed by an attempt to fix things afterward.
• Don't treat "the backup ran without error" as proof of an intact recovery. Fercot himself demonstrates, in the post's final section, that it's possible to remove the checks from pgBackRest's source code (in a development version, 2.60.0dev) and get a backup that only issues a warning (WARN: archive_mode is off) instead of failing. This proves the software can be forced to accept the operation, not that the resulting recovery chain is trustworthy. The checks exist because the relevant error surface, timeline gaps, divergent WAL checksums under archive_mode=always, doesn't show up at backup time, but at restore time, when there's no longer any room to reconfigure anything.

The practical angle for anyone maintaining database infrastructure is that the decision about archive_mode should be made on the day the cluster is born, documented in the failover runbook, and tested with a real switchover in a staging environment, not discovered during an emergency promotion, when the only available way out is editing a backup tool's source code and hoping for the best.