pgBackRest is a well-known powerful backup and
restore tool. Old backups and archives are removed by the expire command
based upon the defined retention policy.
Since the latest version published last month, new features regarding retention have been committed. We’ll here first overview those changes and then make a tour of the retention policy options that should be available in the next release.
pgBackRest is a well-known powerful backup and restore tool. The 2.26 version has been released on Apr 20, 2020. New features have been developed since then.
Today, let’s have a look at: add backup/expire running status to the info command.
This is implemented by checking for a backup lock on the host where info is running so there are a few limitations:
* It is not currently possible to know which command is running: backup, expire, or stanza-*.
The stanza commands are very unlikely to be running so it's pretty safe to guess backup/expire.
Command information may be added to the lock file to improve the accuracy of the reported command.
* If the info command is run on a host that is not participating in the backup, e.g. a standby, then there will be no backup lock.
This seems like a minor limitation since running info on the repo or primary host is preferred.
check_pgbackrest is designed to
monitor pgBackRest backups, relying on the status information given by the
info command.
The changes in this new release are:
--debug mode;--list-archives argument to print the list of all the archived WAL segments found.pgBackRest is a well-known powerful backup and restore tool.
The 2.24 version, released on February 25, introduced auto-selection of backup
set on restore when time target is specified. Auto-selection is performed only
when --set is not specified. If a backup set for the given target time can’t
be found, the latest (default) backup set will be used.
Let’s illustrate it!
check_pgbackrest is designed to
monitor pgBackRest backups, relying on the status information given by the
info command.
The main features are:
pgBackRest is a well-known powerful backup and restore tool.
While the documentation describes all the parameters, it’s not always that simple to imagine what you can really do with it.
In this post, I will introduce some of the parameters needed to configure the access to an Amazon S3 bucket.
For the first PGDay organized in Belgium by the PgBE PostgreSQL Users Group Belgium, this event regrouped around 40 PostgreSQL fans on 17 May 2019 in Leuven. It was for me a really nice day and I’d like to share it with you.
As of 15 April 2019, there is only one repository RPM per distro, and it includes repository information for all available PostgreSQL releases.
This change, announced by Devrim on the pgsql-pkg-yum mailing list, has some
impacts.
pgBackRest is a well-known powerful backup and restore tool.
While the documentation describes all the parameters, it’s not always that simple to imagine what you can really do with it.
In this post, I will introduce the asynchronous archiving and the possibility to avoid PostgreSQL to go down in case of archiving problems.
With its “info” command, for performance reasons, pgBackRest doesn’t check that all the needed WAL segments are still present. check_pgbackrest is clearly built for that. The two tricks mentioned above can produce gaps in the archived WAL segments. The new 1.5 release of check_pgbackrest provides ways to handle that, we’ll also see how.
pgBackRest is a well-known powerful backup and restore tool.
While it works with a really simple configuration, a major version upgrade of PostgreSQL has some impact on it.
Immediately after upgrading PostgreSQL to a newer major version, the pg-path
for all pgBackRest configurations must be set to the new database location and
the stanza-upgrade command must be run.
That command updates the stanza information to reflect the new cluster information and, for example, allows to archiving process to work.