First of all, let me tell you what EDB BART is? It’s a backup and recovery feature exclusively launched by EDB Postgres in 2014 to eliminate the human errors occurred during any backup processes. EDB BART was built on the pg_basebackup which allows us to take complete hot physical backups of the PostgreSQL or PPAS databases. EDB has been continuously improvising the tool to make it customer friendly.
In 2016, EDB enhanced and released BART with usability and performance features like deletion management custom compression techniques, 2 modes of retention with MANAGE command etc. And yet, BART didn’t have the most needed feature by customers – incremental backup. Which has now been taken care of – In 2017, EDB released a new version of BART with add-on features and here in my blog, I’d like to discuss those:

• The latest BART-2.0 version supports the Postgres 9.5 and later. While BART-1.0 supported only Postgres database version 9.4 and earlier.
• The biggest advantage is BART is absorbed into the existing setups immediately after release to fix the underlying issues. One of our customers was facing a huge problem in taking backup of the cluster but ended up with incomplete backups due to disk space availability and the DBAs were alerted at odd hours about the failure, which they had to fix immediately. This was happening in spite of correct housekeeping, mainly due to the growing data and insufficient diskspace. Soon after, the customer added BART into their environment. Now they are mighty pleased about the disk space check feature even before the backup has started and most importantly the incremental backup and retention feature which saves a lot of space.

Let me take you through the new Features in BART 2.0

1. Block-Level incremental backups

• Incremental backup saves the copy of the backup similar to full basebackup but only the relations that are modified since the parent full backup. This helps in reducing the time taken for completing the backup and also saves the disk space in storing multiple full backups. As full backup is taken in tar file it saves more space resulting in less cost on storage.
• Incremental backups are taken using the BACKUP sub command with the – parent option to specify the backup identifier or name of a previous, full base backup or an incremental backup. The BART process identifies the changes in the WAL, only the modified blocks are copied and saved. For identifying the modified blocks a bart-scanner is a WAL scanner program which identifies the modifications done in the WALS. This feature of Block-level increment helped the DBA’s who are already facing an issue with the disk space management as well as it gave a chance to save more copies of backup.

2.Full base backups with the user-defined tablespaces
Base backups are taken in tar and plaintext format from BART. The previous version supported the zip format. By using the transaction log streaming method (xlog=stream) in the BART configuration file, the backup of the user defined tablespaces which are created using the create tablespace command can also be taken.

• One of our customers was having 60+ user defined tablespaces in their cluster, where the DBAs always had an issue while taking the backup in zip format. To overcome this, a script was used to take the backup of the tablespaces and zip them. With BART, the customer is now able to avoid using multiple tasks for a single backup. It also helped in reducing the effort of monitoring the successful completion of multiple tasks as well as it made it easy to manage.

3.New command called Check-Config
The check-config command is used to check the configuration parameters in both global and individual database server sections. Certain processes such as WAL file archiving are verified by the bart-scanner when check-config is used.  This helps in avoiding the unexpected errors before starting the BART backup process for the parameters like bart-host, backup path and pg_basebakup path. It helps the DBA to take a proactive step to avoid the failure of backup.
4.Additional Parameters in config file
More additional parameters are added in BART to make it more user friendly in maintenance. Some of them are:

• Thread_count: no of threads used to copy the modified blocks from the database server to BART backup catalog. This parameter is helpful in reducing the time taken to complete the incremental backup
• Batch_size: The number of blocks of memory used to copy the modified blocks from database server to BART catalog can be specified to pin the memory for the backup
• Scanner_logfile: The path to the wal scanner can be added which holds the details of the bart-scanner process

Talking of more universal features of BART:
There’s more than just the above mentioned features, and I have got it covered for you:
1.The BART configuration process has been simplified with the INIT subcommand that performs functions such as creating the BART backup catalog, automatically configuring the archive_command configuration parameter (for Postgres version 9.4), and rebuilding the backupinfo file, which contains the information for each backupSimplified configuration process with INIT subcommand: Automatic configuration of archive_command, Rebuilding the backupinfo file
2.Simplified configuration process with INIT subcommand: Automatic configuration of archive_command, Rebuilding the backupinfo file
In the postgres-9.4 archive_command can be automatically configured with INIT subcommand. This archive _command specifies the format of the archive_commad which is used in moving the wals to archive location. In BART, the server section of the BART configuration file can contain a BART archive_command parameter to specify the desired format of the archive command string to be generated into the Postgres archive_command parameter in the postgresql.auto.conf file. If the BART archive_command parameter is not set in the server section for a given database server, the command string that is configured uses the default format.
The BART backupinfo file which contains the information of the backup is created by a subcommand BACKUP in BART1.0. This is automated in BART when INIT –r is invoked rebuilding the backupinfo file using the content of the backup directory.
3.Retention policy: A retention policy can be defined according to redundancy
BART manage command will provide two modes of retention, Redundancy and Recovery_Window.
The redundancy option will allow users to specify the number of backups for all the servers, backups and associated WALs will be marked obsolete if the number of backups for a server exceeds the specified number. The backups aren’t removed at this point. Instead, they are marked as obsolete to give users a chance to keep the backups if needed.
The recovery_window option for retention will allow the user to specify the window in which the backup is expected to be restored. The recovery window can be specified in number of DAYS|WEEKS|MONTHS|YEAR from the backup creation date. The backups that are over the recovery window will be marked as obsolete.
This was a quick snippet on BART and how we used this reliever tool in real-life use cases with great success. It’s an interesting tool by EDB Postgres and we are looking forth to see it evolve better, as time goes.
Prathima Mulpuri I Database consultant, Ashnik

Prathima is a Database consultant with Ashnik. She is very passionate about learning new technologies and working on different database administrations. In her words, Ashnik is a place where she got an opportunity to learn so much about PostgreSQL, which is making her journey to Postgres very interesting and challenging. She handled the installations for our clients successfully which is her key role.