Select Page

Let’s Compare: BARMAN vs. Manual Backup

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.

BARMAN

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.

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.

ORA-12154: TNS:could not resolve the connect identifier specified

Most people will encounter this error when their application tries to connect to an Oracle database service, but it can also be raised by one database instance trying to connect to another database service via a database link.

Jeremiah Wilton | March 4, 2009

12c Upgrade Bug with SQL Tuning Advisor

Learn the steps to take on your Oracle upgrade 11.2 to 12.1 if you’re having performance problems. Oracle offers a patch and work around to BUG 20540751.

Megan Elphingstone | March 22, 2017

Best RAID For SQL Server | RAID 0, RAID 1, RAID 5, RAID 10

Which RAID should you use with SQL Server? Learn the differences between RAID 0, RAID 1, RAID 5, and RAID 10, along with best practices.

Eric Russo | June 8, 2015

Work with Us

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

CONTACT US

Work for Us

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

EXPLORE JOBS