Configuring PostgreSQL Backup via Barman

Barman PostgreSQL backup: why recovery breaks down

The classic picture: configuration check returns ok, backups run on schedule, reports are green — the Barman setup is considered complete.

A failure or a nightly attempt to restore the database shows something else: the WAL chain is broken, and recovery stops at the last full backup — along with the loss of hours or days of transactions.

The first source of failures is WAL archiving. The segment transfer command returns an error, but the server keeps writing: from the application's perspective, everything works.

Barman receives fresh backups as expected, but between the last of them and the failure point there is a gap — PostgreSQL backup formally exists, but database recovery after a failure hits the nearest intact point.

The second source is the retention policy. Retention by number of files or by age, without being tied to the WAL chain, removes the segments needed for a recovery point and leaves full backups that can no longer be reached.

Access issues also surface separately: after service keys are rotated or network exchange is closed, archiving stops silently, while the report shows yesterday's successful backup.

The third source is that recovery has never been tested. Until a restore is performed on a separate instance and the time to operational state is measured, no one knows either the actual data loss window or the downtime duration. A check that has never been run does not count as a check.

All three failure modes lie in the same plane: backup export is configured, but recovery assurance is not. We'll break down how this is addressed.

Measurable effect of managed backup

Metrics after configuring managed backup do not change by themselves — they are visible only because we record baseline values before implementation.

We capture the initial picture: how long recovery currently takes, when a backup was last actually restored, how much space the archive occupies, and who is responsible for cleaning it up.

We measure the same numbers again after configuring Barman and repeat them at every scheduled check.

How to ensure the numbers are not just a declaration

Once a quarter, we restore a backup on a separate staging environment and measure the actual recovery time — without this, any promises about rollback time are worthless. We record the result in a report: date, selected recovery point, actual time, what interfered.

If the metric worsens, we investigate the cause: the database size grew, the storage scheme changed, or the launch schedule broke.

Operating modes and limitations of different backup schemes

Barman does not reduce backup to a single scenario: full database snapshots, incremental backups, and continuous change streaming solve different tasks and limit recovery in different ways.

The mistake is choosing a mode out of habit rather than based on recovery point requirements and the acceptable maintenance window.

The working scheme is usually hybrid: an infrequent full snapshot as a foundation, continuous change streaming for intraday precision, and incremental levels in between — this keeps the maintenance window within acceptable limits, while recovery depth is measured in days, not hours.

Before putting it into the regulations, we run a trial recovery: the chain is checked for gaps, not on paper.

Implementation procedure: from assessment to handover to operations

Backup implementation begins not with installing Barman, but with an inventory: which clusters we support, what data loss volume is acceptable, and how much time is available for recovery.

The answers determine the backup scheme — write-ahead log archiving together with periodic full backups, a separate storage for backups, and a scheduled retention policy.

1. Cluster assessment: versions, volumes, change rate, maintenance windows, recovery point and time requirements.
2. Backup scheme: where the backup server is placed, where backups are written, retention depth, WAL archiving and streaming mode.
3. Configuration: server connections, full and incremental backup schedules, retention policy, archiving error notifications.
4. Test recovery: restore a backup on a separate instance, measure time to operational state, and verify point-in-time rollback.
5. Backup regulations: schedules, responsible parties, failure response procedure, integrity checks, and backup rotation.
6. Monitoring and handover to operations: alerts for archiving failure, status dashboard, documentation, team training.

We hand over the system after a control recovery: until rollback is verified on real data, the regulations are considered a draft.

Configurations, regulations, and documentation at output

After implementation, the customer's team is left not only with working backup jobs, but also with everything needed to maintain them without the implementer.

An engineer who did not participate in the setup should be able to use these materials to bring up recovery on a test environment and get the same result.

• Backup configuration — working server and connected node settings files with explanations: what sets the schedule, retention depth, WAL transfer mode, and why these values were chosen.
• Backup documentation — a description of the entire chain: where the backup is taken from, where it is stored, how long it lives, and what happens if the source or storage is unavailable.
• Access policies — roles and permissions for reading settings, starting backups, and recovery, separation by environment, and the procedure for approving manual operations in production.
• Recovery instructions — a step-by-step scenario for full and point-in-time data restoration, including rollback to the required moment, with the expected result at each step.
• Verification regulations — how often and in which environment recovery is run, which signs confirm a backup is suitable, and what to do in case of a discrepancy.
• Status monitoring — automated checks and alert rules: who receives an alert about a failed backup and in which cases.
• Acceptance log — recorded test recovery results with time and data volume.

We hand over together with a walkthrough: we go through each artifact, answer questions, and record owners. After that, the team runs the system on its own.

Case study: recovery in minutes instead of several hours

Before: a dump that no one restored

A multi-node cluster was backed up with a nightly dump and manual copying of the data directory. No one checked backup readiness: it was assumed that if the file was created, it was suitable.

Write-ahead logs were archived irregularly, so point-in-time recovery before a failure did not exist — only the "last successful dump", meaning data loss of a day or more.

After: streaming backup and regular drills

We set up Barman on a separate server: it takes full backups as a stream, continuously receives WAL segments, and stores them outside the main cluster.

The retention policy keeps several full backups and the entire WAL series for the required period — this is enough for point-in-time recovery immediately before an incident.

Once a week, a backup is restored on a separate staging environment: the cluster starts, checksums and row counts in key tables are compared.

Recovery time decreased from about five hours to 12–18 minutes, including transfer and startup. The share of verified backups grew from zero to 100% — every full backup goes through a restore on the staging environment before entering rotation.

A class of failures disappeared where a corrupted backup was discovered only during an incident, as did the scenario with losing a day's worth of changes.

What to do if Barman is already deployed but backups have not been verified?

A deployed Barman is not yet a working backup system. Until recovery has been tested at least once, neither backup integrity nor actual downtime during a failure is known.

We start with a backup audit: which servers actually make it into the configuration, where WAL archives go, whether there are gaps in the chain, and what the archiver log shows.

A gap is critical: losing one WAL segment removes the ability to recover to an arbitrary point in time, and this is usually discovered during an incident, not during a scheduled check.

A recovery test removes the question — the backup is restored to a separate instance and compared with the source by checksums and row counts in key tables.

Then comes a review of the backup scheme.

A daily full snapshot on a growing database stops fitting into the window and begins to affect load; the working scheme combines a base snapshot, incremental backups, and a retention policy where old snapshots are cleaned up while rollback depth remains sufficient.

A separate part is regulations: recovery testing on a schedule, not on occasion. Automatic restore to a test environment, measurement of time to database readiness, an alert on WAL archiving or backup failure, and a status report for each server.

After that, a production failure is a rehearsed scenario with a known recovery time, not a first encounter with the backup.

Technical questions about storing and verifying backups

Backup storage is not a folder on a disk, but a policy: where the backup is located, how long it lives, and how it is verified. Before work starts, we fix three parameters — the placement site, storage volume, and backup lifecycle. Below are answers to the doubts that most often arise when configuring Barman.

How much space will backups take?

Backup storage volume is calculated from database size, change rate, and the chosen lifecycle. The lifecycle determines how many full backups and write-ahead log chains are retained: we keep the latest full backups for the required period, and the rest is deleted. Then the archive does not grow indefinitely, while rollback to the required point remains possible.

How can you tell that a backup will actually restore?

A backup without verification is an assumption. We set up automated verification: the backup is restored on a separate staging environment, the database starts, and control queries run.

If verification fails, the responsible person receives a notification before an incident, not at the moment of recovery.

Let's discuss your backup scheme and come back with a plan

Describe how backup is currently arranged — and we will come back with an assessment and work plan, not generalities.

We start with an analysis of the current scheme: where backups are taken, where the WAL archive goes, whether integrity is checked, and what will happen if the primary node fails.

Based on the results, you receive a target Barman scheme, implementation stages, and responsibility boundaries.

• Topology and requirements: how many nodes, whether there are replicas, which databases are critical, acceptable data loss, and target recovery time.
• Analysis of the current scheme: backup schedule, retention depth, occupied volume, where the WAL archive is written, and how storage access is arranged.
• Backup verification history: whether test recoveries were performed, on which staging environment, how they ended, and whether the backup diverges from the production state.
• Target architecture: streaming transfer of full backups, continuous WAL archiving, moving storage to a separate server or object storage.
• Retention policy: how many full backups and WAL files we keep, how rotation fits into available volume, and which rollback points remain available.
• Verification regulations: schedule of test restores to a separate staging environment, automated comparison, and alerting on archiving failure.
• Assessment and work plan: stages, timelines, dependencies on your infrastructure, approval points, and which accesses are needed from your side.
• Handover to operations: documentation, monitoring settings, instructions for the on-call shift, and the recovery procedure.