cloning from Barman can use 2ndQuadrant's Barman application to clone a standby (and also as a fallback source for WAL files). Barman (aka PgBarman) should be considered as an integral part of any PostgreSQL replication cluster. For more details see: https://www.pgbarman.org/. Barman support provides the following advantages: the primary node does not need to perform a new backup every time a new standby is cloned a standby node can be disconnected for longer periods without losing the ability to catch up, and without causing accumulation of WAL files on the primary node WAL management on the primary becomes much easier as there's no need to use replication slots, and wal_keep_segments does not need to be set. In order to enable Barman support for repmgr standby clone, following prerequisites must be met: the barman_server setting in repmgr.conf is the same as the server configured in Barman; the barman_host setting in repmgr.conf is set to the SSH hostname of the Barman server; the restore_command setting in repmgr.conf is configured to use a copy of the barman-wal-restore script shipped with the barman-cli package (see below); the Barman catalogue includes at least one valid backup for this server. Barman support is automatically enabled if barman_server is set. Normally it is good practice to use Barman, for instance when fetching a base backup while cloning a standby; in any case, Barman mode can be disabled using the --without-barman command line option. If you have a non-default SSH configuration on the Barman server, e.g. using a port other than 22, then you can set those parameters in a dedicated Host section in ~/.ssh/config corresponding to the value ofbarman_host in repmgr.conf. See the Host section in man 5 ssh_config for more details. It's now possible to clone a standby from Barman, e.g.: NOTICE: using configuration file "/etc/repmgr.conf" NOTICE: destination directory "/var/lib/postgresql/data" provided INFO: connecting to Barman server to verify backup for test_cluster INFO: checking and correcting permissions on existing directory "/var/lib/postgresql/data" INFO: creating directory "/var/lib/postgresql/data/repmgr"... INFO: connecting to Barman server to fetch server parameters INFO: connecting to upstream node INFO: connected to source node, checking its state INFO: successfully connected to source node DETAIL: current installation size is 29 MB NOTICE: retrieving backup from Barman... receiving file list ... (...) NOTICE: standby clone (from Barman) complete NOTICE: you can now start your PostgreSQL server HINT: for example: pg_ctl -D /var/lib/postgresql/data start As a fallback in case streaming replication is interrupted, PostgreSQL can optionally retrieve WAL files from an archive, such as that provided by Barman. This is done by setting restore_command in recovery.conf to a valid shell command which can retrieve a specified WAL file from the archive. barman-wal-restore is a Python script provided as part of the barman-cli package (Barman 2.0 and later; for Barman 1.x the script is provided separately as barman-wal-restore.py) which performs this function for Barman. To use barman-wal-restore with &repmgr; and assuming Barman is located on the barmansrv host and that barman-wal-restore is located as an executable at /usr/bin/barman-wal-restore, repmgr.conf should include the following lines: barman_host=barmansrv barman_server=somedb restore_command=/usr/bin/barman-wal-restore barmansrv somedb %f %p barman-wal-restore supports command line switches to control parallelism (--parallel=N) and compression ( --bzip2, --gzip). To use a non-default Barman configuration file on the Barman server, specify this in repmgr.conf with barman_config: barman_config=/path/to/barman.conf cloning advanced options By default, pg_basebackup performs a checkpoint before beginning the backup process. However, a normal checkpoint may take some time to complete; a fast checkpoint can be forced with the -c/--fast-checkpoint option. However this may impact performance of the server being cloned from so should be used with care. Further options can be passed to the pg_basebackup utility via the setting pg_basebackup_options in repmgr.conf. See the PostgreSQL pg_basebackup documentation for more details of available options. If replication connections to a standby's upstream server are password-protected, the standby must be able to provide the password so it can begin streaming replication. The recommended way to do this is to store the password in the postgres system user's ~/.pgpass file. It's also possible to store the password in the environment variable PGPASSWORD, however this is not recommended for security reasons. For more details see the PostgreSQL password file documentation. If, for whatever reason, you wish to include the password in recovery.conf, set use_primary_conninfo_password to true in repmgr.conf. This will read a password set in PGPASSWORD (but not ~/.pgpass) and place it into the primary_conninfo string in recovery.conf. Note that PGPASSWORD will need to be set during any action which causes recovery.conf to be rewritten, e.g. . It is of course also possible to include the password value in the conninfo string for each node, but this is obviously a security risk and should be avoided. In some circumstances it might be desirable to create a dedicated replication-only user (in addition to the user who manages the &repmgr; metadata). In this case, the replication user should be set in repmgr.conf via the parameter replication_user; &repmgr; will use this value when making replication connections and generating recovery.conf. This value will also be stored in the repmgr.nodes table for each node; it no longer needs to be explicitly specified when cloning a node or executing .