Tools: How To Back Up, Restore, and Migrate PostgreSQL Databases with Barman on CentOS

By Sadequl Hussain, Sharon Campbell and Vinayak Baranwal PostgreSQL is an open-source database platform quite popular with web and mobile application developers for its ease of maintenance, cost effectiveness, and simple integration with other open-source technologies. One critical task of maintaining a PostgreSQL environment is to back up its databases regularly. Backups form part of the Disaster Recovery (DR) process for any organization. This is important for a few reasons: Usually the responsibility of database backup and restoration falls on the shoulder of a DBA. In smaller organizations or startups, however, system administrators, DevOps engineers, or programmers often have to create their own database backends. So, it’s important for everyone using PostgreSQL to understand how backups work and how to restore from a backup. In this tutorial you’ll set up the Barman backup server, make a backup from a primary database server, and restore to a standby server. Compatibility: This tutorial was originally written for CentOS 7 but has since been updated and validated for CentOS Stream 9 and other supported RHEL-based distributions. CentOS 7 and 8 have reached end of life; for production deployments, use a supported RHEL-based distribution such as CentOS Stream. Before launching into your Barman setup, let’s take a moment to review the types of backups available for PostgreSQL, and their uses. (For an even broader overview of backup strategies, read our article about effective backups.) PostgreSQL offers two types of backup methods: Logical backups are like snapshots of a database. These are created using the pg_dump or pg_dumpall utility that ships with PostgreSQL. Logical backups: This means if you make a logical backup of your database(s) at 2:00 AM in the morning, when you restore from it, the restored database will be as it was at 2:00 AM. There is no way to stop the restore at a particular point in time, say at 1:30 AM. If you are restoring the backup at 10:00 AM, you have lost eight hours’ worth of data. Physical backups are different from logical backups because they deal with binary format only and make file-level backups. Physical backups: WAL files contain lists of transactions (INSERT, UPDATE or DELETE) that happen to a database. The actual database files containing the data are located within the data directory. So when it comes to restoring to a point in time from a physical backup, PostgreSQL restores the contents of the data directory first, and then plays the transactions on top of it from the WAL files. This brings the databases to a consistent state in time. Traditionally, PostgreSQL DBAs would write their own backup scripts and scheduled cron jobs to implement physical backups. Barman does this in a standardized way. Barman or Backup and Recovery Manager is a free, open-source PostgreSQL backup tool from 2ndQuadrant - a professional Postgres solutions company. Barman was written in Python and offers a simple, intuitive method of physical backup and restoration for your PostgreSQL instance. Some benefits of using Barman are: In this tutorial we will create three DigitalOcean Droplets, install PostgreSQL 12 or later (this guide was tested with PostgreSQL 14) on two of these machines, and install Barman on the third. One of the PostgreSQL servers will be our main database server: this is where we will create our production database. The second PostgreSQL instance will be empty and treated as a standby machine where we can restore from the backup. The Barman server will communicate with the main database server and perform physical backups and WAL archiving. We will then emulate a “disaster” by dropping a table from our live database. Finally, we will restore the backed up PostgreSQL instance from the Barman server to the standby server. To follow this tutorial, you will need to create three DigitalOcean Droplets (or your own Linux servers), each with at least 2 GB of RAM and 2 CPU cores. We won’t go into the details of creating a Droplet; you can find more information in how to create your first DigitalOcean Droplet. All three servers should use the same RHEL-based OS (e.g., CentOS Stream 9 or another supported distribution, x64). We will name the machines as follows: The actual IP addresses of the machines can be found from the DigitalOcean control panel. You should also set up a sudo user on each server and use that for general access. Most of the commands will be executed as two different users (postgres and barman), but you will need a sudo user on each server as well so you can switch to those accounts. To understand how sudo privileges work, see this DigitalOcean tutorial about enabling sudo access. Note: This tutorial will use the default Barman installation directory as the backup location. In CentOS, this location is: /var/lib/barman/. 2ndQuadrant recommends it’s best to keep the default path. In real-life use cases, depending on the size of your databases and the number of instances being backed up, you should check that there is enough space in the file system hosting this directory. Warning: You should not run any commands, queries, or configurations from this tutorial on a production server. This tutorial will involve changing configurations and restarting PostgreSQL instances. Doing so in a live environment without proper planning and authorization would mean an outage for your application. We will first set up our database environment by installing a supported PostgreSQL version on the main-db-server and the standby-db-server. Install PostgreSQL using your distribution’s packages or the PGDG repository. For CentOS Stream 9 and later, use: For CentOS 7, replace dnf with yum. If you are using PGDG packages, install the desired PostgreSQL version from the enabled repository and initialize the database cluster before starting the service. After installation, locate pg_hba.conf and postgresql.conf in your PostgreSQL data directory. With distribution packages initialized via postgresql-setup --initdb, this is commonly /var/lib/pgsql/data/. With PGDG packages (for example, postgresql15-server), the data directory is usually a versioned subdirectory such as /var/lib/pgsql/15/data/. Configure access as described below. In pg_hba.conf, add this line so the Barman server can connect, using the barman-backup-server IP address, followed by /32: For production environments, avoid using trust authentication. Instead, use md5 or scram-sha-256 and configure appropriate credentials for the barman user. Note: Installing PostgreSQL will create an operating system user called postgres on the database server. This account does not have a password; you’ll switch to it from your sudo user. Make sure you have installed PostgreSQL on both the main-db-server and the standby-db-server, and that you have allowed access on both of them from the barman-backup-server. Next we’ll add some sample data to the main database server. Once PostgreSQL is installed and configured on both the machines, we’ll add some sample data to the main-db-server to simulate a production environment. On the main-db-server, switch to the user postgres: Start the psql utility to access the database server: From the psql prompt, run the following commands to create a database and switch to it: An output message will tell you that you are now connected to database mytestdb as user postgres. Next, add two tables in the database: These are named mytesttable1 and mytesttable2. Quit the client tool by typing \q and pressing ENTER. Now we’ll install Barman on the backup server, which will both control and store our backups. Complete this step on the barman-backup-server. On CentOS Stream 9 and later, replace yum with dnf. To check your OS version, run: To do this, you will first need to install the following repositories: Run the following command to install EPEL. On CentOS Stream 9, use dnf instead of yum. Install the PostgreSQL Global Development Group (PGDG) repository so you can install Barman. Visit https://yum.postgresql.org/repopackages/ and download the PGDG repository RPM for your platform. The site provides packages for el7, el8, el9, and el10; for RHEL 9 / CentOS Stream 9 (x86_64), use the EL-9 RPM. For el7, el8, or el10, select the matching RPM from the same page. Install with rpm -ivh: Finally, run this command to install Barman: Note: Installing Barman will create an operating system user called barman. This account does not have a password; you can switch to this user from your sudo user account. Barman is installed! Now, let’s make sure the servers can connect to each other securely. In this section, we’ll establish SSH keys for a secure passwordless connection between the main-db-server and the barman-backup-server, and vice versa. Likewise, we’ll establish SSH keys between the standby-db-server and the barman-backup-server, and vice versa. This is to ensure PostgreSQL (on both database servers) and Barman can “talk” to each other during backups and restores. For this tutorial you will need to make sure: We will not go into the details of how SSH works. There’s a very good article on DigitalOcean about SSH essentials which you can refer to. All the commands you’ll need are included here, though. We’ll show you how to do this once for setting up the connection for the user postgres to connect from the main-db-server to the barman-backup-server. From the main-db-server, switch to user postgres if it’s not already the current user: Run the following command to generate an SSH key pair: Accept the default location and name for the key files by pressing ENTER. Press ENTER twice to create the private key without any passphrase. Once the keys are generated, there will be a .ssh directory created under the postgres user’s home directory, with the keys in it. You will now need to copy the SSH public key to the authorized_keys file under the barman user’s .ssh directory on the barman-backup-server. Note: Unfortunately you can’t use the ssh-copy-id barman@barman-backup-server-ip command here. That’s because this command will ask for the barman user’s password, which is not set by default. You will therefore need to copy the public key contents manually. Run the following command to output the postgres user’s public key contents: Copy the contents of the output. Switch to the console connected to the barman-backup-server server and switch to the user barman: Run the following commands to create a .ssh directory, set its permissions, copy the public key contents to the authorized_keys file, and finally make that file readable and writable: Make sure you put the long public key string starting with ssh-ed25519 between the quotation marks, instead of public_key_string. You’ve copied the key to the remote server. Now, to test the connection, switch back to the main-db-server and test the connectivity from there: After the initial warning about the authenticity of the remote server not being known and you accepting the prompt, a connection should be established from the main-db-server server to the barman-backup-server. If successful, log out of the session by executing the exit command. You need to set up SSH key connections three more times. You can skip making the .ssh directory if it’s already made (although this isn’t necessary). Make sure you test the connection each way so that you can accept the initial warning about the new connection. From standby-db-server: From barman-backup-server: From barman-backup-server: Note: Ensuring SSH connectivity between all three servers is a requirement for backups to work. You will now configure Barman to back up your main PostgreSQL server. The main configuration file for BARMAN is /etc/barman.conf. The file contains a section for global parameters, and separate sections for each server that you want to back up. The default file contains a section for a sample PostgreSQL server called main, which is commented out. You can use it as a guide to set up other servers you want to back up. A semicolon (;) at the beginning of a line means that line is commented out. Just like with most Linux-based applications, a commented-out configuration parameter for Barman means the system will use the default value unless you uncomment it and enter a different value. One such parameter is the configuration_files_directory, which has a default value of /etc/barman.d. What this means is, when enabled, Barman will use the .conf files in that directory for different Postgres servers’ backup configurations. If you find the main file is getting too lengthy, feel free to make separate files for each server you want to back up. For the sake of simplicity in this tutorial, we will put everything in the default configuration file. Open /etc/barman.conf in a text editor as your sudo user (user barman has only read access to it): The global parameters are defined under the [barman] section. Under this section, make the following changes. The finished values are shown below the bullet points: The new settings should look like this exactly: What we are doing here is this: At the end of the file, add a new section. Its header should say [main-db-server] in square brackets. (If you want to back up more database servers with Barman, you can make a block like this for each server and use a unique header name for each.) This section contains the connection information for the database server, and a few unique backup settings. Add these parameters in the new block: The retention_policy settings mean that Barman will overwrite older full backup files and WAL logs automatically, while keeping enough backups for a recovery window of 7 days. That means we can restore the entire database server to any point in time in the last seven days. For a production system, you should probably set this value higher so you have older backups on hand. You’ll need to use the IP address of the main-db-server in the ssh_command and conninfo parameters. Otherwise, you can copy the above settings exactly. The final version of the modified file should look like this, minus all the comments and unmodified settings: Save and close the file. Next, we’ll make sure our main-db-server is configured to make backups. There is one last configuration to be made on the main-db-server, to switch on backup (or archive) mode. First, we need to locate the value of the incoming backup directory from the barman-backup-server. On the Barman server, switch to the user barman: Run this command to locate the incoming backup directory: This should output something like this: Note down the value of incoming_wals_directory; in this example, it’s /var/lib/barman/main-db-server/incoming. Now switch to the main-db-server console. Switch to the user postgres if it’s not the current user already. Open the postgresql.conf file in a text editor: Make the following changes to the file: Switch back to your sudo user. Some distributions use version-specific service names; verify with systemctl list-units | grep postgresql. Note: If you are configuring an existing production PostgreSQL instance, there’s a good chance these three parameters will be set already. You will then have to add/modify only the archive_command parameter so PostgreSQL sends its WAL files to the backup server. It’s now time to check if Barman has all the configurations set correctly and can connect to the main-db-server. On the barman-backup-server, switch to the user barman if it’s not the current user. Run the following command to test the connection to your main database server: Note that if you entered a different name between the square brackets for the server block in the /etc/barman.conf file in Step 5, you should use that name instead. If everything is okay, the output should look like this: Don’t worry about the backup maximum age FAILED state. This is happening because we have configured Barman so that the latest backup should not be older than 1 day. There is no backup made yet, so the check fails. If any of the other parameters are in a FAILED state, you should investigate further and fix the issue before proceeding. There can be multiple reasons for a check to fail: for example, Barman not being able to log into the Postgres instance, Postgres not being configured for WAL archiving, SSH not working between the servers, etc. Whatever the cause, it needs to be fixed before backups can happen. Run through the previous steps and make sure all the connections work. To get a list of PostgreSQL servers configured with Barman, run this command: Right now it should just show: Now that you have Barman ready, let’s create a backup manually. Run the following command as the barman user on the barman-backup-server to make your first backup: Again, the main-db-server value is what you entered as the head of the server block in the /etc/barman.conf file in Step 5. This will initiate a full backup of the PostgreSQL data directory. Since our instance has only one small database with two tables, it should finish very quickly. So where does the backup get saved? To find the answer, list the contents of the /var/lib/barman directory: There will be one directory there: main-db-server. That’s the server Barman is currently configured to back up, and its backups live there. (If you configure Barman to back up other servers, there will be one directory created per server.) Under the main-db-server directory, there will be three sub-directories: During a restoration, Barman will recover contents from the base directory into the target server’s data directory. It will then use files from the wals directory to apply transaction changes and bring the target server to a consistent state. There is a specific Barman command to list all the backups for a server. That command is barman list-backup. Run the following command to see what it returns for our main-db-server: To see more details about the backup, execute this command using the name of the server, and the backup ID (20151111T051954 in our example) from the previous command: A detailed set of information will be shown: To drill down more to see what files go into the backup, run this command: This will give a list of the base backup and WAL log files required to restore from that particular backup. Ideally your backups should happen automatically on a schedule. In this step we’ll automate our backups, and we’ll tell Barman to perform maintenance on the backups so files older than the retention policy are deleted. To enable scheduling, run this command as the barman user on the barman-backup-server (switch to this user if necessary): This will open a crontab file for the user barman. Edit the file, add these lines, then save and exit: The first command will run a full backup of the main-db-server every night at 11:30 PM. (If you used a different name for the server in the /etc/barman.conf file, use that name instead.) The second command will run every minute and perform maintenance operations on both WAL files and base backup files. You will now see how you can restore from the backup you just created. To test the restoration, let’s first simulate a “disaster” scenario where you have lost some data. We’re dropping a table here. Don’t do this on a production database! Go back to the main-db-server console and switch to the user postgres if it’s not already the current user. Start the psql utility: From the psql prompt, execute the following command to switch the database context to mytestdb: Next, list the tables in the database: The output will show the tables you created at the beginning of this tutorial: Now, run this command to drop one of the tables: If you now execute the \dt command again: You will see that only mytesttable1 remains. This is the type of data loss situation where you would want to restore from a backup. In this case, you will restore the backup to a separate server: the standby-db-server. You can follow this section to restore a backup, or to migrate your latest PostgreSQL backup to a new server. Go to the standby-db-server. First, stop the PostgreSQL service as the sudo user. (The restart will choke if you try to run the restoration while the service is running.) Once the service stops, go to the barman-backup-server. Switch to the user barman if it’s not already the current user. Let’s locate the details for the latest backup: From the output, note down the backup ID printed on the first line (20160114T173552 above). If the latest backup has the data you want, you can use latest as the backup ID. Also check when the backup was made, from the Begin time field (2016-01-14 17:35:53.164222-05:00 above). Next, run this command to restore the specified backup from the barman-backup-server to the standby-db-server: There are quite a few options, arguments, and variables here, so let’s explain them. For a successful restore operation, you should receive output like this: Now switch to the standby-db-server console again. As the sudo user, start the PostgreSQL service: Let’s verify that our database is up. Switch to user postgres and start the psql utility: Switch the database context to mytestdb and list the tables in it: The list should show two tables in the database. In other words, you have just recovered the dropped table. Depending on your larger recovery strategy, you may now want to fail over to the standby-db-server, or you may want to check that the restored database is working, and then run through this section again to restore to the main-db-server. To restore to any other server, just make sure you’ve installed PostgreSQL and made the appropriate connections to the Barman server, and then follow this section using the IP address of your target recovery server. Can this tutorial be used on CentOS Stream?
Yes. The steps are compatible with CentOS Stream 9 and other RHEL-based distributions. Use dnf instead of yum and choose repository packages that match your OS (el9 for CentOS Stream 9). How do I check my CentOS version?
Run cat /etc/os-release to see your distribution and version. Use this to select the correct PGDG and EPEL package variants (el7, el8, or el9). Does Barman support point-in-time recovery?
Yes. Barman performs physical backups and archives WAL files, so you can restore to a specific point in time within your retention window (e.g., the 7-day window configured in this tutorial). Can I back up multiple PostgreSQL servers with one Barman instance?
Yes. Add a separate server block in /etc/barman.conf (or a file under /etc/barman.d/) for each PostgreSQL instance. Ensure SSH and pg_hba.conf allow the barman user to connect to each server. In this tutorial we have seen how to install and configure Barman to back up a PostgreSQL server. We have also learned how to restore or migrate from these backups. With careful consideration, Barman can become the central repository for all your PostgreSQL databases. It offers a robust backup mechanism and a simple command set. However, creating backups is only half the story. You should always validate your backups by restoring them to a different location. This exercise should be done periodically. Some questions for fitting Barman into your backup strategy: Another point to be mindful of is that Barman cannot backup and restore individual databases. It works on the file system level and uses an all-or-nothing approach. During a backup, the whole instance with all its data files are backed up; when restoring, all those files are restored. Similarly, you can’t do schema-only or data-only backups with Barman. We therefore recommend you design your backup strategy so it makes use of both logical backups with pg_dump or pg_dumpall and physical backups with Barman. That way, if you need to restore individual databases quickly, you can use pg_dump backups. For point-in-time recovery, use Barman backups. Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products Hi, I am Sadequl Hussain. I have been in IT for more than eighteen years and have worked with a number of technologies. Welcome to my page :=) Current fan and former Editorial Manager at DigitalOcean. Hi! Expertise in areas including Ubuntu, Docker, Rails, and more. Building future-ready infrastructure with Linux, Cloud, and DevOps. Full Stack Developer & System Administrator. Technical Writer @ DigitalOcean | GitHub Contributor | Passionate about Docker, PostgreSQL, and Open Source | Exploring NLP & AI-TensorFlow | Nailed over 50+ deployments across production environments. This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! This tutorial is really fantastic. Great job/thank you! As creators, developers and maintainers of Barman, we really thank you for this great tutorial. Very well done! What to do when i have 3 Amazon instance EC2 in which every instance has ‘centos’ username with secure-key by default. Thank you for a very nice tutorial. I have a small problem. I’m trying to use incremental backup reuse_backup = link, but it doesn’t work. [barman]
barman_home = /backup/barman barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link immediate_checkpoint = true basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS configuration_files_directory = /etc/barman/conf.d [db.server.local]
description = “db.server.local server backup”
ssh_command = ssh [email protected]
conninfo = host=db.server.local user=barman dbname=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 1 MONTH
wal_retention_policy = main barman list-backup db.server.local
db.server.local 20160325T151000 - Fri Mar 25 15:12:17 2016 - Size: 16.9 GiB - WAL Size: 0 B
db.server.local 20160325T150322 - Fri Mar 25 15:05:44 2016 - Size: 16.9 GiB - WAL Size: 410.6 KiB
db.server.local 20160324T233002 - Thu Mar 24 23:32:24 2016 - Size: 16.9 GiB - WAL Size: 240.6 MiB
db.server.local 20160324T135916 - Thu Mar 24 14:02:29 2016 - Size: 16.9 GiB - WAL Size: 208.0 MiB
db.server.local 20160324T135447 - Thu Mar 24 13:57:17 2016 - Size: 16.9 GiB - WAL Size: 32.0 MiB
db.server.local 20160324T124245 - Thu Mar 24 12:45:00 2016 - Size: 16.8 GiB - WAL Size: 80.0 MiB barman show-backup db.server.local 20160325T151000
Backup 20160325T151000:
Server Name : db.server.local
Status : DONE
PostgreSQL Version: 90405
PGDATA directory : /pgdata/9.4/main Base backup information:
Disk usage : 16.9 GiB
Timeline : 1
Begin WAL : 00000001000000050000005E
End WAL : 00000001000000050000005E
WAL number : 1
Begin time : 2016-03-25 15:10:00.864661
End time : 2016-03-25 15:12:17.171181
Begin Offset : 40
End Offset : 1041680
Begin XLOG : 5/5E000028
End XLOG : 5/5E0FE510 WAL information:
No of files : 0
Disk usage : 0 B
Last available : 00000001000000050000005E Catalog information:
Retention Policy: VALID
Previous Backup : 20160325T150322
Next Backup : - (this is the latest base backup) Any idea what could be wrong? barman@pg01-VirtualBox:/root$ barman show-backup main 20161003T121716
Backup 20161003T121716:
Server Name : main
Status : STARTED
EXCEPTION: ‘children_timelines’
See log file for more details. When trying for the first backup via below command:-
barman backup main
getting above error in logs as well:- 2016-10-03 12:23:49,908 [2959] barman.cli ERROR: ‘children_timelines’
See log file for more details.
Traceback (most recent call last):
File “/usr/lib/python2.7/dist-packages/barman/cli.py”, line 1022, in main
p.dispatch(pre_call=global_config)
File “/usr/lib/python2.7/dist-packages/argh/helpers.py”, line 55, in dispatch
return dispatch(self, *args, **kwargs)
File “/usr/lib/python2.7/dist-packages/argh/dispatching.py”, line 174, in dispatch
for line in lines:
File “/usr/lib/python2.7/dist-packages/argh/dispatching.py”, line 277, in _execute_command
for line in result:
File “/usr/lib/python2.7/dist-packages/argh/dispatching.py”, line 231, in _call
result = function(namespace_obj)
File “/usr/lib/python2.7/dist-packages/barman/cli.py”, line 539, in show_backup
server.show_backup(backup_info)
File “/usr/lib/python2.7/dist-packages/barman/server.py”, line 1688, in show_backup
output.result(‘show_backup’, backup_ext_info)
File “/usr/lib/python2.7/dist-packages/barman/output.py”, line 254, in result
_dispatch(_writer, ‘result’, command, *args, **kwargs)
File “/usr/lib/python2.7/dist-packages/barman/output.py”, line 127, in _dispatch
return handler(*args, **kwargs)
File “/usr/lib/python2.7/dist-packages/barman/output.py”, line 659, in result_show_backup
if data[‘children_timelines’]:
KeyError: ‘children_timelines’ Any suggestion , Thanks in advance I have followed each and every step in this guide (checked it 4 or 6 times now) and when i run the ‘barman check’ command im getting the follwing
WAL archive: FAILED (please make sure WAL shipping is setup)
PostgreSQL: FAILED
directories: OK
retention policy settings: OK
backup maximum age: FAILED (interval provided: 1 day, latest backup age: No available backups)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 0 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
archiver errors: OK I can SSH from my 2 postgresql servers to the barman server (using the command ssh barman@pgbarman01) and from barman to the 2 postgresql servers (ssh postgres@pgpoc01 and ssh postgres@pgpoc02).I am doing this in RHEL 7.3 (does this actually matter though?). I am also using servers that I have on premise at my work if that helps. Please let me know thanks. Why does barman say this: Also, in my case it also says the following: It appears that barman attempts to create a new postgresql.conf file in the data directory. Although in my case (using Ubuntu 14 LTS) the postgresql.conf file lives in /etc/postgresql/9.5/ … Hi, I’m having an issue executing the following command, to make a remote recover: Starting remote restore for server master_server using backup 20170315T163002
Destination directory: /var/lib/pgsql/9.5/data
Doing PITR. Recovery target time: ‘2017-03-15 16:30:02.638819-03:00’
Using safe horizon time for smart rsync copy: 2017-03-15 16:30:02.638819-03:00
Copying the base backup.
Generating recovery.conf
ERROR: unable to create the archive_status directory ‘/var/lib/pgsql/9.5/data/pg_xlog/archive_status’: mkdir execution failed Do I missed something ? If you need some other information (server status, check server, etc.) please let me know. Excellent tutorial btw ! I haven’t found another like this one, but sadly I’m stuck in the final step. Hey thanks for the detailed tutorial. I had one small question though. Why do you use “Begin time” instead of “End time” for --target-time during the barman recover command? Does barman time stamp backups by start time and only uses “End time” for display purposes? You would think that you would want to use the “End time” because it is the latest on the time spectrum. Anyways thanks again for the solid tutorial. Very Nice Blog , Could you please also create a blog for setting barman using pg_receivexlog / streaming protocol . Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.