archive_mode

Definition PG 18 manual

When archive_mode is enabled, completed WAL segments are sent to archive storage by setting archive_command or archive_library. In addition to off, to disable, there are two modes: on, and always. During normal operation, there is no difference between the two modes, but when set to always the WAL archiver is enabled also during archive recovery or standby mode. In always mode, all files restored from the archive or streamed with streaming replication will be archived (again). See Section 26.2.9 for details.

archive_mode is a separate setting from archive_command and archive_library so that archive_command and archive_library can be changed without leaving archiving mode. This parameter can only be set at server start. archive_mode cannot be enabled when wal_level is set to minimal.

How it works

When enabled, PostgreSQL runs the WAL archiver and submits each completed segment to archive_command or, in versions that provide it, archive_library before that segment can be recycled. The mode is separate from the command or library, so the archive destination logic can be reloaded while archiving remains enabled.

The on and always modes behave the same during normal primary operation. In recovery or standby mode, on does not archive received WAL, while always also archives segments restored from an archive or received through streaming replication.

Enabling the mode does not prove that an archive is healthy or recoverable. A command that fails causes WAL to accumulate in pg_wal; a command that falsely reports success can create an unrecoverable archive chain. Point-in-time recovery also requires a suitable base backup and tested restore procedure.

Operational considerations

Enabling archive_mode with an empty or failing command and letting pg_wal fill.

Using a command such as /bin/true, which reports success while breaking the recoverable WAL chain.

Assuming archive_mode is reloadable even though changing it requires a server restart.

Treating WAL archiving as a substitute for a base backup and restore test.

Using always with a shared archive without duplicate-safe, race-free handling.

Workload guidance

OLAP: Provision archive bandwidth and destination capacity for bulk-load WAL bursts. If the archive cannot keep up, throttling or scheduling the batch is safer than allowing pg_wal to fill.

OLTP: Enable it for a defined PITR or log-shipping requirement, pair it with a reliable idempotent archive implementation, and alert on pg_stat_archiver failures, archive age, and pg_wal growth. Test restores rather than treating successful command exits as sufficient evidence.

SMALL: Use a simple managed tool such as pgBackRest only when retention and restore procedures are understood. Keep the archive off for disposable databases rather than enabling it with a placeholder command.