Frequently Asked Questions
Introduction
Frequently Asked Questions are intended to provide details for specific questions that may or may not be covered in the User Guide, Configuration, or Command reference. If you are unable to find details for your specific issue here, remember that the
pgBackRest
Issues List in GitHub
is also a valuable resource.
What if I get the
could not find WAL segment
error?
The cause of this error can be a result of many different issues, some of which may be:
- misconfigured archive_command
- misconfigured pgBackRest configuration files
- network or permissions issue
- third party product (e.g. S3, Swift or Minio) configuration issue
- large amount of WAL queueing to be archived
It is advisable to:
- check the archive_command in PostgreSQL
- check the pgBackRest configuration settings on each host (e.g. pg* settings are set on the repository host and repo* settings on the pg host)
- run the check command with --archive-timeout set to a higher value than in the pgBackRest configuration file (or default) to see if the WAL queue needs more time to clear. If the system is generating a lot of WAL, then consider configuring asynchronous archiving
How do I manually purge a backup set?
Backup sets in the middle cannot be expired, but it is possible to expire the oldest backup sets by running the
expire
command with retention. For example, the following command will keep only the last two full backups, purging any prior full backups including their associated incremental/differential backups and archive:
pgbackrest --stanza=xxx --repo1-retention-full=2 expire
Using the
--repo1-retention-full
option on the command- line simply overrides the setting in the configuration file for that one execution of the command. See the
Retention
section in the User Guide for more information on retention.
How can I configure options independently for each command?
pgBackRest
has the ability to set options independently in the configuration file for each command.
Configure Cluster Stanza
details this feature as well as option precedence.
For example, the
process-max
option can be optimized for each command:
[global] # used where not overridden process-max=2 [global:backup] # more cores for backup process-max=4 [global:restore] # all the cores for restore process-max=8 [global:archive-push] # more cores for archive-push process-max=3 [global:archive-get] # fewer cores for archive-get process-max=1
Can I use dots (periods) in my S3 bucket name?
RFC-2818
does not allow wildcards to match on a dot (.) so s3 bucket names must not contain dots. If there are dots in the S3 bucket name then an error such as
unable to find hostname 'my.backup.bucket.s3.amazonaws.com' in certificate common name or subject alternative nameswill occur.
Where can I find packages for older versions of pgBackRest ?
The
apt.postgresql.org
repository maintains an
archive of older versions
. Debian also maintains
snapshots
of all test builds.
Why does a backup attempt fail when backup-standby=y and the standby database is down?
Configuring backup from standby is generally intended to reduce load on the primary, so switching backups to the primary when the standby is down often defeats the point. Putting more load on the primary in a situation where there are already failures in the system is not recommended. Backups are not critical as long as you have one that is fairly recent -- the important thing is to keep up with WAL archiving. There is plenty of time to get a backup when the system is stable again.
If you really need a backup, the solution is to have more standbys or remove
backup-standby
. This can be overridden on the command line with
--no-backup-standby
, so there is no need to reconfigure for a one-off backup.
Should I setup my repository on a standby host?
No. When primary and standby databases are configured, the
pgBackRest
configuration files should be symmetric in order to seamlessly handle failovers. If they are not, the configurations will need to be changed on failover or further problems may result.
See the
Dedicated Repository Host
section of the
User Guide
for more information.
Time-based Point-in-Time Recovery does not appear to work, why?
The most common mistake when using time-based Point-in-Time Recovery is forgetting to choose a backup set that is before the target time.
pgBackRest
defaults to the latest backup and if it is after the target time, then
--target=
is not considered valid by
PostgreSQL
and is therefore ignored, resulting in WAL recovery to the latest time available.
To choose the correct backup set, run the
info
command and find the backup with a timestamp stop that is before the target time. When running the restore, specify the option
--set=BACKUP_LABEL
where
BACKUP_LABEL
is the backup that was found with a
stop
timestamp before the target time.
See the
Point-in-Time Recovery
section of the
User Guide
for more information.