The TLS server is an alternative to using SSH for protocol connections to remote hosts.
It is supported since the 2.37 release.
In this section, we will examine a configuration used to run pgBackRest from a dedicated repository host like described in the Use Case 2, but using TLS rather than SSH connections.
We will set up a demo cluster (using EDB Postgres Advanced Server version 14 on Rocky Linux 8) where the repository host will be called backup-srv and the 3 Postgres nodes in Streaming Replication: pg1-srv, pg2-srv, pg3-srv.
Create a Dedicated User on the Repository Host
The pgbackrest user is created to own the backups and archives repository. Any user can own the repository, but it is recommended not to use postgres or enterprisedb to avoid confusion.
Create the user and the repository location on backup-srv:
The repository should be reachable from the backup server. It can be located on the various supported types described in the first use case.
For example, let us create /backup_space to store our backups and archives locally:
Certificates generation
The TLS server implementation relies on certificates.
In this example, we will:
create our own root certificate authority (CA),
generate keys and certificates for the Postgres nodes and for the backup server.
Then, you have to deploy it on each server (ca.crt + server_name.crt + server_name.key).
Here is an example using a shared folder between the hosts:
Configuration
We will now prepare the configuration for our stanza called demo.
Update the backup-srv pgBackRest configuration file:
Update the pg1-srv, pg2-srv and pg3-srv pgBackRest configuration file:
( Remark: obviously, adjust pg1-srv by pg2-srv on pg2-srv and pg3-srv on pg3-srv. )
Clients are authorized on the server by verifying their certificate and checking the certificate CN (Common Name) against a list on the server configured with the tls-server-auth.
A CN can be authorized for as many stanzas as needed by repeating the tls-server-auth option, or for all stanzas by specifying tls-server-auth=*.
The idea is to have a TLS server running on each host to serve the request coming from the other.
In example, the backup command running on the repository host will act as client for the TLS server running on the Postgres node.
The archive-push command running on the Postgres node will act as client for the TLS server running on the repository host.
The server command can be used to start the TLS server and will run until terminated by the SIGINT signal (Control+C).
If not done by the PGDG package already, create a service file on the backup-srv server:
Start the server and check it's running:
The server-ping command serves as an aliveness check only since no authentication is attempted.
Don't forget to terminate/restart the process when the tls-* configuration is changed.
Now, apply the same steps (service configuration and start) on the on pg1-srv, pg2-srv and pg3-srv using this configuration:
Now, let us configure Postgres archiving in the postgresql.conf file (on pg1-srv):
The Postgres instance must be restarted after making these changes and before performing a backup.
Let us finally create the stanza and check the configuration on backup-srv:
Perform a backup
If everything is working correctly, we can now take our first backup:
The info command can then be executed from any server where pgBackRest is correctly configured:
Prepare the servers for Streaming Replication
On pg1-srv, create a specific user for the replication:
Configure pg_hba.conf:
Reload configuration:
Configure ~enterprisedb/.pgpass on pg2-srv and pg3-srv:
Setup the standby servers
Adjust /etc/pgbackrest.conf on pg2-srv and pg3-srv to add the recovery-option.
The idea is to automatically configure the Streaming Replication connection string with the restore command.
Then, make sure the configuration is correct by executing the info command. It should print the same output as above.
Restore the backup taken from the pg1-srv server on pg2-srv and pg3-srv:
The restore will add extra information to the postgresql.auto.conf file:
The --type=standby option creates the standby.signal needed for Postgres to start in standby mode. All we have to do now is to start the Postgres instances:
If the replication setup is correct, you should see those processes on the pg1-srv server:
We now have a 3-nodes cluster working with Streaming Replication and archives recovery as safety net.
Take backups from the standby servers
Add the following settings to the pgBackRest configuration file on backup-srv, in the [demo] stanza section:
Now, perform a backup fetching the data from the first standby server found in the configuration:
Conclusion
The TLS server provides an alternative to SSH for remote operations.
This new feature will fit perfectly in a containerized world where it can significantly improve performance and user experience.