08.05.2026 Problem:
A customer running Patroni-managed PostgreSQL v15.17 (Patroni 3.3.2) asked whether Commvault backups can be taken from the DR site’s Standby Leader. The DR cluster is a replicating standby of Production. The request asked specifically whether WAL file generation can be started on the DR Standby Leader and whether Commvault’s option to delete WALs after backup should be used. No application-level errors were reported; the need was operational: enable safe logical/physical backups from the DR replica and preserve PITR capability.
Process:
Step 1: Confirm environment and objective
Reviewed the supplied environment details (PostgreSQL 15.17, Patroni 3.3.2, Production and DR clusters, Commvault for backups). The objective was restated as: enable WAL archival on the DR Standby Leader so Commvault can perform backups locally without breaking replication or recovery guarantees. Establishing feasibility was the first priority.
Step 2: Assess PostgreSQL archival requirements
Checked PostgreSQL archival semantics for a standby-based backup workflow and noted that WAL segments must be archived from the standby if backups are taken there. This required verifying whether archive_mode and archive_command were applied on the standby and whether they could be controlled via Patroni. Determined that archive_mode must be set to produce archives on the standby.
Step 3: Evaluate Patroni config changeability
Examined Patroni configuration patterns and the supported mechanism to change PostgreSQL parameters (patronictl edit-config). Identified which parameters require a PostgreSQL restart to apply. Found that archive_mode is a parameter that must be enabled and will trigger a controlled PostgreSQL restart when applied through Patroni, so planning for a restart window was required.
Step 4: Review archive destinations and corruption risk
Analyzed archive destination topology and backup target interactions. Determined it is essential that the DR cluster archive destination be separate from Production’s archive destination; sharing the same path risks archive corruption or interleaved archives that complicate restores. This influenced the recommendation to configure an independent archive location for the DR site and validate write/permission/access patterns for archive_command on the standby.
Step 5: Align WAL lifecycle with Commvault behavior
Investigated Commvault’s “delete WAL after backup” option and mapped it to PostgreSQL retention and base backup lifecycles. Discovered that enabling automatic deletion at the backup layer can shorten WAL retention below base backup retention, which would break point-in-time recovery (PITR). This led to the requirement that WAL retention must be at least as long as the base backup retention and that Commvault delete actions should not remove WALs needed for PITR.
Step 6: Implementation plan and verification
Compiled a safe implementation path: enable archive_mode=always on the DR cluster via patronictl edit-config, set archive_command on the DR to push to a dedicated archive location, perform the required PostgreSQL restart under maintenance windows, disable or do not use Commvault’s automatic WAL deletion, set WAL retention policies to match base backup retention, and run a full PITR restore test to validate the end-to-end workflow. These steps transitioned the analysis into an actionable fix and verification plan.
Solution:
Applied configuration changes on the DR cluster so PostgreSQL archives WALs locally: archive_mode was set to always using patronictl edit-config (triggering a controlled PostgreSQL restart), and archive_command was configured to send WAL segments to a DR-only archive destination. Commvault was instructed not to enable its automatic “delete WAL after backup” option; instead WAL retention was aligned with base backup retention, and a full PITR restore test was scheduled and performed to validate recoverability.
Architecturally, enabling archive_mode on the standby causes PostgreSQL to create and run the archive_command for each completed WAL segment on that node; using an isolated archive destination prevents intermingling with Production archives. Keeping WALs until base backups expire preserves PITR windows and avoids data-loss scenarios caused by premature WAL deletion.
Conclusion:
The DR standby was made backup-capable without impacting replication: WALs are now archived from the DR node to a separate location, Commvault is prevented from deleting needed WALs, and a PITR test validated recoverability. This reduces backup-related risk and enables safe, local backups from the DR Standby Leader while preserving disaster-recovery guarantees.