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
- 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.
- 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.
- 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.
- 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.
- 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
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.
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.
Imagine over 100 logins on the source server, you need to migrate them to the destination server. Wouldn’t it be awesome if we could automate the process?