Beyond SSH: Elevating Disaster Recovery Security with pgBackRest TLS Transport

In the high-stakes environment of enterprise database administration, disaster recovery (DR) is the ultimate insurance policy. For years, the gold standard for moving PostgreSQL backups across the wire has been SSH. It is ubiquitous, reliable, and well-understood. However, as infrastructure scales from a handful of nodes to complex, multi-region distributed systems, the limitations of SSH-based authentication—specifically key management and lateral movement risks—have become increasingly apparent.

The emergence of native TLS (Transport Layer Security) transport in pgBackRest represents a paradigm shift. By moving away from shell-based authentication toward a dedicated, certificate-authenticated daemon, organizations can achieve a more robust security posture that is inherently better suited for isolated or large-scale recovery environments.

The Evolution of Backup Transport: Why SSH Is Not Always Enough

The standard pgBackRest deployment typically involves two servers communicating via passwordless SSH. The backup node pulls or pushes data through an encrypted tunnel, with identity verified by shared public keys. For small teams or monolithic deployments, this is perfectly adequate.

However, the challenge emerges at scale. As the number of machines grows, the operational overhead of managing individual key pairs becomes a significant burden. Distributing these keys, rotating them on a schedule, and maintaining an audit trail of who holds access to which node is a recipe for human error. While SSH host-based authentication offers some relief, enforcing rigid key rotation across a large fleet remains a notoriously difficult engineering problem.

Furthermore, SSH is fundamentally designed for shell access. Unless an administrator goes to extreme lengths to restrict a user via a forced command, an SSH key often grants the bearer a foothold on the target machine. If a DR server is compromised, any SSH key stored on it could potentially be used for lateral movement toward the Backup Node and, by extension, the Primary Database Node. In a zero-trust architecture, this level of inherent trust is a liability.

Security Isolation and the Blast Radius

The most compelling argument for transitioning to pgBackRest TLS mode is the reduction of the "blast radius." By design, TLS mode removes the risk associated with shell access. The DR server does not hold a key that grants shell access; instead, it holds a certificate that authenticates to a dedicated TLS daemon (listening on port 8432 by default).

This daemon is application-aware. It understands the pgBackRest protocol and nothing else. It does not provide an interactive shell, nor does it allow an attacker to pivot into the underlying OS. Access is strictly governed by the tls-server-auth configuration on the Backup Node. Even if an attacker gains full root access to the DR server, they are limited to the permissions explicitly granted to that specific certificate. There is no host-level foothold to escalate privileges, making this a cleaner, safer choice for high-security environments.

The Mechanics of TLS Authentication

pgBackRest leverages X.509 public key infrastructure (PKI) to manage identities. Rather than pre-sharing keys—which are static and difficult to revoke—TLS uses certificates signed by a trusted Certificate Authority (CA).

The handshake is mutual: the DR server verifies the Backup Node’s identity, and the Backup Node verifies the DR server’s certificate. This mutual authentication ensures that both parties are exactly who they claim to be. Authorization is then handled at the application layer:
tls-server-auth=<cert-CN>=<stanza-name>.

If a client connects with a certificate featuring the Common Name (CN) "dr-server," the Backup Node checks its configuration, sees that "dr-server" is authorized for the "db" stanza, and grants access. If you need to revoke access, you simply remove that line from the configuration file and restart the daemon. While pgBackRest does not currently support Certificate Revocation Lists (CRLs), this application-level control provides a swift, effective alternative for managing access rights.

Chronology of Deployment: Implementing TLS Mode

Transitioning to this architecture requires a methodical approach. The following guide outlines the path to establishing a secure, certificate-authenticated recovery pipeline.

Phase 1: Infrastructure Readiness

Before beginning, ensure both the DR server and the Backup Node have pgBackRest and the necessary PostgreSQL binaries installed. Unlike SSH-based setups, the DR server does not require an account on the Backup Node; it only requires the ability to reach the TLS listener on port 8432.

Phase 2: Building the Certificate Authority (CA)

The root of trust is the CA. In production environments, this should be handled by your organization’s existing PKI (such as Microsoft Active Directory Certificate Services or HashiCorp Vault). For demonstration, one can generate a local CA on the Backup Node:

1. Generate the CA Key: Create a 4096-bit RSA key.
2. Issue the CA Certificate: Sign the CA certificate to be distributed to all participating nodes.
3. Permissions: Ensure the CA key is strictly protected (chmod 600) and stored securely.

Phase 3: Certificate Issuance and Exchange

Each node needs a unique server/client certificate signed by the CA.

• The Backup Node requires a server certificate that matches the DNS name or IP address the DR server will use to reach it.
• The DR Server requires a client certificate with a specific CN (e.g., "dr-server") that will serve as its identity in the authorization handshake.

Since SSH access is no longer the transport method, the certificate exchange—specifically the signing of the Certificate Signing Request (CSR)—is a manual, deliberate act. This lack of automated trust is a feature, not a bug, preventing unauthorized nodes from joining the backup network.

Phase 4: Configuring the TLS Daemon

On the Backup Node, modify the pgBackRest configuration to include the TLS server block. Define the tls-server-address, port, and the paths to your signed certificates. Finally, establish the authorization policy:

tls-server-auth=dr-server=db

This single line replaces complex SSH key management with explicit, stanza-level access control.

Phase 5: The Final Handshake

On the DR server, configure repo1-host-type=tls and point the application to the client certificate and the CA certificate. Once configured, a simple pgbackrest --stanza=db info command verifies that the TLS handshake is successful and that the backup metadata is accessible.

Implications for Disaster Recovery Strategy

The shift to TLS-based transport in pgBackRest is not merely a change in configuration; it is an evolution in how we view the relationship between recovery infrastructure and the primary production environment.

Operational Resilience

By separating backup transport from OS-level shell access, organizations effectively decouple their security boundaries. The backup node becomes a "hardened vault" that can only be opened by specific, authenticated clients. This reduces the risk of accidental configuration changes and limits the potential impact of a compromised DR node.

Compliance and Auditing

In industries governed by strict compliance frameworks (such as HIPAA, PCI-DSS, or SOC2), the ability to cryptographically verify connections is invaluable. TLS provides a clear, audit-ready trail of authentication. Since access is tied to a specific CN and configured centrally on the backup node, auditors can verify the security posture of the backup pipeline with significantly less effort than auditing distributed SSH authorized_keys files.

The "Archive Mode" Warning: A Critical Human Factor

During the restore process, one must be vigilant regarding PostgreSQL’s archive_mode. A common, high-risk error involves starting a restored database instance without disabling the archive_command. If the restored instance begins pushing WAL files to the production archive, it can lead to data corruption or "split-brain" scenarios where production backups become unusable. Always verify archive_mode = off in the postgresql.conf file before initiating the service on a DR node.

Conclusion: Choosing the Right Tool for the Job

Both SSH and TLS transport modes are production-grade, but they serve different operational philosophies.

SSH transport remains the ideal choice for smaller environments where simplicity, ease of setup, and rapid deployment are prioritized. It leverages the existing security expertise of Linux administrators and requires minimal infrastructure overhead.

TLS transport is the definitive choice for enterprises operating at scale. It addresses the fundamental complexities of key management, provides superior security isolation, and aligns perfectly with zero-trust principles. As database footprints grow and the regulatory requirements for data protection tighten, moving toward certificate-authenticated backups is a necessary step in hardening the database lifecycle.

By adopting pgBackRest TLS mode, teams are not just backing up data—they are building a more resilient, transparent, and secure foundation for the future of their infrastructure. While the setup requires more initial coordination, the long-term benefits in security and operational clarity are substantial.