Select Page

Let’s Compare: BARMAN vs. Manual Backup

Author: Lohit Gupta | | May 6, 2020

BARMAN is one of the most popular tools for backup and recovery management in PostgreSQL. PostgreSQL, as an open source database has different methods to approach database backups. Let’s look at the different types in this blog post.

Manual Backup Methods

  1. Pg_dump (Logical Backup)

    Logical backups can be table level to database level based on requirements. These backups do not block read/write activity on the database. Logical backups may decrease overall performance and take time to complete based on amount of data.

    Global objects cannot be backed up with pg_dump. You will have to use pg_dumpall to backup those. This backup supports parallel processes, but the overall database load increases as well.

    One advantage of taking these backups is that they can be restored onto different major versions of PostgreSQL, or even in different OS architecture.

  2. Filesystem (Physical Backup)
    Physical backups are PostgreSQL offline backups taken after stopping the PostgreSQL cluster. These backups contain entire cluster data. These are faster than Logical backups, but can only be restored on same major version of PostgreSQL.
  3. Basebackups (Online Backup)

    Online Backups can be taken online without stopping the PostgreSQL cluster. These are also called “Hot Backups,” where the database is put in backup mode and then an online database copy is backed up along with archives generated during the backup operation. These are recommended way to perform backups as you can take a backup of entire cluster without any downtime on your application.

  4. Continuous Archiving (Point-In-Time-Recovery)

    These backups are incremental backups. It happens where a complete backup is taken followed by backing up archives/WALs generated, which can then be restored by recovering the WALs. These do provide PITR capability but could take a long time recovering the data from archives. These are mostly used in databases with huge volume where frequent backups are not feasible.

  5. Snapshots and Cloud Backups

    Snapshots need support from the operating system and there are tools like rsync that can be used to take snapshots. These won’t work on cases where database store tablespaces in multiple drive volumes.

    All cloud providers such as Amazon (AWS) or Azure also provide backup offerings within their service which can be logical, physical or PITR level. These usually come with their own licensing and maintenance costs.


When compared to the manual solutions I described, BARMAN combines PostgreSQL’s online backup and continuous archiving into one tool. This gives the user an easy to manage backup architecture that can be deployed over multiple PostgreSQL applications that supports different major versions in a single tool. Here’s a list of what BARMAN has to offer:

  • Capable of performing remote backups.
  • Capable of supporting multiple PostgreSQL clusters with a single setup.
  • Capable of supporting different PostgreSQL versions.
  • No deployment or licensing cost, as it’s an open source tool.
  • Management of multiple backups from a single location.
  • Enforce retention policies.
  • Perform database and WAL level backup from single tool.
  • Perform parallel backups and backup compression.
  • Perform operations over backups with pre/post hookup scripts.

So, as you can see, BARMAN is extremely popular option for PostgreSQL backup and can offer many benefits for this open source environment. If you’re needing support in a BARMAN implementation for your PostgreSQL database or are looking to make the move to PostgreSQL, look no further. Contact us today and set up a meeting with an expert to get started.

Read This Next

Why BARMAN is the PostgreSQL Disaster Recovery Solution You’ve Been Searching For

In this white paper we’ll cover BARMAN features, benefits, use cases, how to set up BARMAN for disaster and recovery and why organizations are making the move to open-sourced PostgreSQL.

How to Solve the Oracle Error ORA-12154: TNS:could not resolve the connect identifier specified

The “ORA-12154: TNS Oracle error message is very common for database administrators. Learn how to diagnose & resolve this common issue here today.

Vijay Muthu | February 4, 2021

Data Types: The Importance of Choosing the Correct Data Type

Most DBAs have struggled with the pros and cons of choosing one data type over another. This blog post discusses different situations.

Craig Mullins | October 11, 2017

How to Recover a Table from an Oracle 12c RMAN Backup

Our database experts explain how to recover and restore a table from an Oracle 12c RMAN Backup with this step-by-step blog. Read more.

Megan Elphingstone | February 2, 2017

Subscribe to Our Blog

Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.


Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.