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.
pgBackRest is a well-known powerful backup and restore tool.
Relying on the status information given by the “info” command, we’ve build a specific plugin for Nagios : check_pgbackrest.
This post will help you discover this plugin and assume you already know pgBackRest and Nagios.
pgBackRest is a well-known powerful backup and restore tool. It offers a lot of possibilities.
While pg_basebackup is commonly used to setup the initial database copy for the Streaming Replication, it could be interesting to reuse a previous database backup (eg. taken with pgBackRest) to perform this initial copy.
Furthermore, the --delta option provided by pgBackRest can help us to
re-synchronize an old secondary server without having to rebuild it from
scratch.
To reduce the load on the primary server during a backup, pgBackRest even allows to take backups from a standby server.
We’ll see in this blog post how to do that.