Configuring pgBackRest: where PostgreSQL backup breaks
pgBackRest can be configured in a couple of hours, and copies begin to appear on schedule. But repository overflow breaks the process silently: volume grows faster than the retention policy, and when space runs out, both full copies and WAL segments stop being accepted.
A backup failure surfaces not via an alert, but by the fact that there is no fresh copy — usually during an incident.
A separate trap is a gap in WAL archiving. The archive process may lag or stop after a server restart, while full copies continue to be created on schedule.
Formally, copies exist, but point-in-time recovery is impossible: between the last copy and the incident there remains a hole that nothing can close.
Another source of restore failure from a copy is schedule mismatch. Copying, WAL archiving, and cleanup of old copies live in different timers; when the copy window overlaps with the cleanup window, the retention policy deletes the base copy on which incremental copies depend. Restore fails with a missing segment message exactly when the copy is most needed.
An unverified copy is the most expensive class of failure: reports of successful completion do not prove that the cluster will come up from this data.
A corrupted segment, version mismatch, or lack of permissions on the restore directory are revealed only during a real run on a separate test environment.
We break down how this is closed: space and retention control in the repository, WAL archiving monitoring, coordinated job windows, and restore with integrity verification.
Restore to the required point and copy integrity verification
A backup is useful exactly as much as it is precisely known to what moment it can be restored, and there is confirmation that it reads.
Without this, the team learns about the problem at the moment of failure: the archive lies on disk, but there is nothing to deploy it with or build the chain from. This is exactly what pgBackRest is tuned for — not for the fact of copy creation, but for predictable recovery.
Recovery point and schedule
A full copy once a day, differential copies every few hours, transaction logs go to storage continuously. This sets a recovery point with minute accuracy: rollback is possible not only to the nightly snapshot, but also to the moment before an erroneous data change.
The retention policy keeps the required number of generations, so the rollback window is measured in weeks, not in the last archive.
Integrity verification and test restores
A copy is considered valid only after checksum verification and parsing of the entire log chain — the tool does this on schedule and points to the first corrupted segment.
Once a month we deploy a copy on a separate test environment and measure database recovery time: the output is not an estimate of "roughly", but a fact — how many minutes the bring-up takes.
Thus the class of failures "copy exists, cannot restore" goes away: each copy is verified, the chain is assembled, recovery time is known in advance.
Regularity of copying and checks is brought into monitoring — a missed window is visible immediately, not at the moment when the copy is needed.
Comparison of backup and retention modes
Modes do not compete, but add up into layers: full backup sets the base for recovery, incremental and differential reduce volume and window, continuous WAL archiving determines the point to which you can return. The mistake is to choose one option and expect everything from it at once.
| Option | When it fits | Limitations |
|---|---|---|
| Full backup | Primary support, base for chains, infrequently changing databases | Long disk reads, volume and traffic to the repository grow |
| Incremental backup | Large databases with intensive writes, frequent backup needed | Restore pulls the entire chain; segment corruption breaks the branch |
| Differential backup | Compromise: shorter chain than incrementals | Copy grows between fulls — with frequent runs the gain disappears |
| Continuous WAL archiving | Point-in-time recovery within minutes needed | Does not replace the base copy: logs are stored together with it |
| External replica | Fast switchover, offloading the primary node | Does not catch logical errors — deletion will reach the replica |
Local and external repository
A local repository is faster: the copy lands on an adjacent volume without network, the backup window is shorter. But it dies together with the host — if the server fails or disks are encrypted, the copy disappears too.
An external repository on a separate node survives primary failure, and pgBackRest writes to two repositories in parallel: the local one remains for fast rollback.
Retention and rotation
The retention rule fixes how many full copies and log chains lie on disk, the rest is cleaned on schedule — repository volume stops growing, and rollback to the required depth is preserved.
Integrity is confirmed by restore to a test node, not by the status "task completed successfully".
Configuring pgBackRest: implementation and handover stages
We carry out the work in stages: each next step relies on the confirmed result of the previous one, so an error is visible before changes reach the production database. Below is the sequence by which implementation proceeds.
Infrastructure preparation
- Backup audit. We look at what is backed up now, where dumps are written, how long they are stored, what volumes are involved, and when the maintenance window is open.
- Repository placement scheme. We decide where the repository lives — local disk, separate server, or object storage. A separate repository per database simplifies restoring one database without affecting the others.
- Copy configuration. Full backup on schedule, incremental between them, continuous WAL archive. The retention policy keeps copies for the required period, the rest is cleaned — the repository does not grow endlessly.
- Schedule and control. We put copying in the minimum load window, check completion, and set notifications: a signal comes on error or missed run, not during the next failure analysis.
Verification on the test environment
- Test restore. We deploy a copy on a separate environment — to the required point in time, measuring recovery time. A backup is considered ready only after a successful restore.
- Procedure and handover to operation. We hand over documentation: where repositories are, how to start restore, how to verify integrity, who receives notifications. We record who does what during a failure — on our side or on the customer side.
Implementation artifacts: configurations, procedures, documentation
At the output, the infrastructure retains not a "configured server", but a set of artifacts by which copying is further maintained by your team without us.
We check each item at acceptance: the configuration can be deployed on a new node, the procedure can be read and executed on a night shift.
- pgBackRest configuration: repository parameters, schedule, encryption and compression, cluster binding, and exclusion rules.
- Backup retention policy: how many full and intermediate sets we keep, what time depth, how automatic cleanup works.
- Restore procedure: step-by-step scenario for full and point-in-time restore to a separate node, with mandatory verification on the test environment.
- Access separation: roles for repository write and read, a separate service user, restriction of access to encryption keys and logs.
- Duty shift instructions: morning check checklist, analysis of typical alerts, escalation procedure.
- Placement diagram: where copies are, what survives primary site failure, how the archive is organized.
- Drill log: dates and results of test restores, measured time to an operational database.
Documentation composition
Separately we hand over a description of the backup architecture, a data flow diagram, a configuration change registry, and a responsibility matrix. Documentation is stored next to the infrastructure code, not in chat — when an engineer changes, the context is not lost.
Monitoring and notifications
Backup metrics go to the common monitoring system: duration, volume, status of the last set, lag behind schedule. Alerts are separated by criticality — absence of data at night separately from a real failure, so the duty engineer does not get used to ignoring notifications.
Case: restoring a database in minutes instead of hours
Before switching to streaming archiving, restoring a database after primary node failure took from four to six hours: we brought up the last nightly dump, manually rolled WAL logs, and every third attempt ended in data mismatch.
Copies physically existed, but no one deployed them before the incident — verification happened at incident time, when every minute of downtime added up to halted orders.
The scheme was rebuilt around continuous archiving and full copies with incrementals in pgBackRest: a daily full copy, incremental between them, and constant WAL shipping.
Once a day the copy is automatically deployed on the test environment and compared by checksums — restore suitability is confirmed in advance, not after failure.
What changed in day-to-day operation
Recovery time on the test environment decreased from four-six hours to eight-twelve minutes, the share of successful restores increased from 60 to 100 percent: over the entire time one attempt failed, and the cause was a corrupted disk, not the copy.
A whole class of failures is gone — "backup exists but is unreadable": broken and outdated sets are cut off by automatic verification and do not live until the incident.
Rolling a database back to a previous state became a routine operation of several minutes, so updates and schema migrations stopped being planned for weekends.
How does hot standby differ from a verified copy?
A replica and a copy solve different tasks, and confusing them is expensive. A replica is a continuous stream of changes: it repeats the state of the primary database almost without delay and keeps the service available if the primary node drops.
A copy is a snapshot at a specific moment, which lies separately from the cluster and does not depend on what happens to the data right now.
Hot standby helps with hardware failure: switchover takes minutes, the application continues to work for read and write. But it honestly repeats everything passed to it — mass deletion or an erroneous edit reaches the standby in seconds. A replica has no point-in-time rollback, so it is not protection against human error.
A copy for checks is needed exactly for this: it is deployed in a separate environment and scenarios are practiced on it.
Restore to the point before failure, integrity verification, checking that the application starts and data matches — all this is done on an isolated site without affecting the production environment. Thus it is regularly confirmed that the reserve really works, not just exists.
In this scheme pgBackRest covers the full and cumulative sets of copies: you can return both to the nightly snapshot and to the required moment between them, without rebuilding the cluster from scratch.
The choice of recovery mechanism depends on the failure class: node loss — switchover to hot standby scenario, corrupted data — restore from copy. Therefore a project usually keeps both mechanisms, and each has its own verification procedure.
Restore checks, copy retention, and access
Verifiability of copies is more important than their presence. We do not consider backup working until a trial deployment on a separate test environment is performed: deploy the full copy, apply WAL segments to the point before failure, compare checksums and index integrity.
The run is on schedule, and the result goes to a report — you can see which copy was checked and to which timestamp the cluster comes up from it.
What proves that the database will actually restore?
By an automatic restore run on an isolated test environment. If deployment fails, an alert comes with the stage at which it stopped — not a report "backup completed successfully". Index integrity is also checked, not only the fact that the cluster started.
What about retention, rotation, and copy terms?
Copies go to separate storage in another failure domain, the local disk for the archive does not overflow: pgBackRest writes in streaming mode. The rotation policy is set explicitly — daily copies kept for a month, weekly for a quarter, monthly for a year. Old versions are deleted on schedule, so archive volume stops growing linearly.
Who has access to the copies, and are they protected?
Access to the archive does not match access to the production database: write is performed by a separate account, read and deployment by a separate role, keys are stored outside the repository.
Copies are encrypted on the source side, so an exported archive without the key is useless. We learn about storage failure or expiration from alerts, not from post-failure analysis.
Let's discuss the task: what is needed from infrastructure at the start
Discussion of a backup task starts not with choosing parameters, but with an inventory of what you already have deployed. We need input data on the infrastructure to come back not with general words, but with a scope estimate and an implementation plan for your environment. Below is what is worth clarifying in the first conversation.
- Placement scheme: how many instances, whether replicas and managed clusters exist, which databases are critical for recovery and which can be brought up on a residual basis.
- Volumes and change profile: current database size, daily growth, share of "hot" tables — the type of backups and their frequency depend on this.
- Recovery goals: how much data is acceptable to lose and in what time the system must return to service.
- Backup storage location: local disk, network storage, object storage, separate site — and whether there is a requirement to keep copies outside the primary environment.
- Accesses and roles: how credentials for service tasks are issued, who owns the bucket or directory, how key rotation is arranged.
- Environment constraints: maintenance windows, network filter rules between segments, encryption requirements in transit and at rest.
- What already works: old dumps, scheduled scripts, manual exports — they will have to be either migrated or carefully decommissioned.
Having collected this, we fix the scope of work, the order of configuration and checks, and the order of documentation handover: configurations, retention policy description, restore instructions with a verified rollback scenario on the test environment. Describe the task and current state — we will come back with an estimate and plan.