This recipe depends on OmniPITR being installed on all servers that need to utilize it. Please follow the Installing and configuring OmniPITR recipe before continuing.

For this procedure, we will continue to use two servers. The backup server will still be named pg-backup, and our primary PostgreSQL server is pg-primary. As usual, the PostgreSQL data directory will be located at /db/pgdata.

Follow these steps to send WAL files from pg-primary to pg-backup:

We start by ensuring that the postgres user can write to the /db/pg_archived directory on the pg-backup server, which is the location we've set aside to hold WAL files. This is also the only step we perform on the pg-backup server.

One interesting thing to consider about OmniPITR is that it reads configuration files in a similar manner as command-line parameters. With this in mind, and to avoid long and confusing command-lines, we save several in a configuration file for later use.

The first is the path to the PostgreSQL data directory. If this is unset, OmniPITR will assume that the WAL files are local to the data directory in pg_xlog. While this will work, it's better for logging purposes to set this explicitly to /db/pgdata. The second is the remote path to WAL files. As we created the /db/pg_archived directory on pg-backup, we use that same location here. Finally, we'll commit logs to the /var/log/postgresql directory, which should already exist on most Red Hat and Debian-based servers.

Now, we need to ensure PostgreSQL uses OmniPITR to send the files to pg-backup. Once we've confirmed that archive_mode is on, we can set archive_command to invoke omnipitr-archive. Because of our earlier work, we only need to set two parameters. The first is the full path to the configuration file we created, and the second is %p, which represents the full path to the WAL file that PostgreSQL wants to archive. Once PostgreSQL is restarted, it will use OmniPITR to manage its WAL files.

Unlike Barman, OmniPITR has no command to verify that it's working properly. To do this, we must examine the logfile. If we look at the end of the omnipitr.log file in /var/log/postgresql/ with tail, we should see something like this:

Perceptive readers may have noticed that we don't present an analogous situation to pull WAL files from the pg-backup server to a hot-standby. Unfortunately, while the provided omnipitr-restore command will move WAL files to their expected locations and include logging, it can not retrieve these files from a remote server. We are not entirely sure why the authors of OmniPITR would neglect to include this functionality, but it is an issue that we can not overcome.

As such, we do not recommend using OmniPITR to maintain clones or streaming replicas with our suggested architecture. An off-site backup server is invaluable, which means that remote WAL files are an inescapable reality.

This does not imply that OmniPITR is completely unsuited to manage certain elements of larger clusters. If you have time, examine the documentation of each OmniPITR utility and consider how each might be beneficial to your architecture.