# Barman: PostgreSQL Backup and Recovery Manager for Multiple Servers

> Barman is an open source Python administration tool for disaster recovery of PostgreSQL servers, maintained by EnterpriseDB under GPL-3.0. It is built for DBAs who need remote backups of several clusters from one host.

**EnterpriseDB/barman** — Barman - Backup and Recovery Manager for PostgreSQL

- Repository: https://github.com/EnterpriseDB/barman
- Website: https://www.pgbarman.org/
- Stars: 3,248 · Forks: 273
- Language: Python
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/enterprisedb-barman

## What Barman Solves for PostgreSQL Operators

A single PostgreSQL server can be backed up with pg_dump or pg_basebackup from a cron job. Ten of them cannot, at least not without ten sets of scripts, ten retention policies and ten places to look when a restore is needed. Barman is aimed at that second case. The README describes it as an open-source administration tool for disaster recovery of PostgreSQL servers written in Python, and says it allows an organisation to perform remote backups of multiple servers in business critical environments.

The audience is system administrators and DBAs, which the project states directly in its pyproject.toml classifiers under Intended Audience. The supported platforms listed there are POSIX Linux, FreeBSD and Unix, so Windows is not a target. Python 3.12 or newer is required, and the classifiers name 3.12, 3.13 and 3.14.

The design assumption is a dedicated backup host. Barman runs on one machine and reaches out to the PostgreSQL servers it protects, rather than asking every database server to push its own backups somewhere. That single control point is what makes cataloguing, retention and restore orchestration possible across a fleet.

## How Barman Works: One Catalog, Remote Servers, WAL Streaming

Barman keeps a catalogue of the backups it has taken. Each PostgreSQL server you register gets an entry, and commands operate on that entry by name. The catalogue is what lets Barman apply a retention policy, list what exists, and decide which base backup plus which WAL segments are needed to reach a target recovery time.

Backups are taken over the network from the Barman host to the PostgreSQL server. The README frames the tool as performing remote backups of multiple servers, which implies connectivity from the Barman host to each server, and in practice that means the Barman host needs credentials and network reachability for every server it manages. The project documentation, linked from the README at pgbarman.org/documentation, is where the connection configuration is described; the README itself does not enumerate the connection settings.

WAL archiving is the other half. A base backup alone restores a cluster to the moment the backup finished. To recover to an arbitrary point, Barman needs the write-ahead log segments produced after that backup, and the documentation describes the archive_command configuration on the PostgreSQL side that hands those segments to Barman. The README does not spell out this mechanism, so treat the documentation as the source of truth for the exact settings.

The repository layout reflects this split. The barman directory holds the Python sources, docs holds the tutorial and man pages, scripts holds auxiliary scripts, and tests holds unit tests. There is no daemon binary or compiled component to deploy beyond the Python package and its two runtime dependencies, psycopg2 and python-dateutil.

## Installing Barman and Taking a First Backup

The README does not contain installation steps. It points to the documentation at pgbarman.org/documentation and to the GitHub repository for download, and notes that versions before 2.13 lived on SourceForge. The pyproject.toml tells you what the package needs: Python 3.12 or newer, psycopg2 and python-dateutil as runtime dependencies, and an optional argcomplete extra for shell completion.

Because the project is packaged with uv_build as its build backend, a source install follows the normal Python path. The dependency list in pyproject.toml is the authoritative statement of what the package pulls in:

```toml
dependencies = [
  "psycopg2 >= 2.4.2",
  "python-dateutil",
]
```

For cloud object storage or cloud snapshot support, the optional dependency groups are separate. The aws-snapshots extra pulls in boto3, and the azure extra pulls in azure-identity and azure-storage-blob. Installing the base package does not give you either.

```toml
[project.optional-dependencies]
argcomplete = ["argcomplete"]
aws-snapshots = ["boto3"]
azure = ["azure-identity", "azure-storage-blob"]
azure-snapshots = ["azure-identity", "azure-mgmt-compute"]
```

Once installed, the entry point is the barman command. The README does not document its subcommands, so the man pages in the docs directory and the online documentation are where the command surface is defined. What the README does establish is the model: you register PostgreSQL servers with Barman and then operate on them by name. The documentation describes the full set of subcommands and the retention behaviour that applies afterwards.

## Where Barman Is the Wrong Choice

Barman assumes it can reach your PostgreSQL servers over the network from a central host. If your database servers sit in a network segment that permits no inbound connections from a backup host, or if your security model forbids a central machine holding credentials for every cluster, the architecture works against you. A tool that runs locally on each server and pushes backups outward fits that constraint better.

The Python requirement is a second boundary. Barman needs Python 3.12 or newer plus psycopg2, which means either a system Python new enough or a managed interpreter. On long-lived distributions with an older system Python, that is an extra runtime to install and keep patched on the backup host.

There is also a scope limit worth stating plainly: Barman is a PostgreSQL tool. The README, the classifiers and the dependencies are all PostgreSQL-specific. If your estate mixes PostgreSQL with MySQL or MongoDB, Barman covers one part of it and you still need something else for the rest.

Finally, the README does not document rollback of a Barman upgrade, nor does it describe what happens to existing catalogues when you move between major versions. The release notes in release_notes and RELNOTES.md are the place to check before upgrading a production backup host, and the README is silent on the subject.

## Barman Compared with pgBackRest and pg_basebackup

The closest comparison is pgBackRest, and the difference is architectural rather than cosmetic. pgBackRest is a single compiled binary that runs on the database host and writes to a repository, with its own parallel backup and delta restore machinery. Barman is a Python application that lives on a separate host and orchestrates backups of many servers from there. If you want one place from which to see every cluster's backup status, Barman's model is the more natural fit. If you want the smallest possible footprint on the database server, pgBackRest's is.

Against pg_basebackup, which ships with PostgreSQL, the difference is scope. pg_basebackup produces a base backup of one cluster and does nothing else. It has no catalogue, no retention policy across servers, and no notion of managing ten clusters as a set. Barman does not replace pg_basebackup at the file level so much as wrap the same idea in inventory and policy.

Barman also has optional integrations that the alternatives do not share in the same form. The pyproject.toml lists extras for AWS snapshots via boto3, Azure via azure-identity and azure-storage-blob, and Azure snapshots via azure-identity and azure-mgmt-compute. Those extras are opt-in, and installing the base package leaves them out.

## Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-18. Releases are frequent: 3.20.0 on 2026-08-27, 3.19.1 on 2026-05-27 and 3.19.0 on 2026-05-20. The pyproject.toml still declares version 3.19.1, so the packaged metadata lags the newest release tag. If you install from a source checkout rather than a release artifact, check which version you actually got.

Barman is licensed GPL-3.0-only, stated in the README, in the LICENSE file and in the pyproject.toml license field. The README repeats the standard GPL warranty disclaimer: the software is distributed in the hope that it will be useful but without any warranty. That is a licence condition, not legal advice, and whether GPL-3.0 fits your distribution model is a question for your own counsel.

Maintenance is handled by EnterpriseDB, which the README names as the maintainer, and the project offers both community support through pgbarman.org and professional support through EnterpriseDB. The build backend is pinned to uv_build with an upper bound below 0.12, and the comment in pyproject.toml explains the pin as a guard against breaking changes in a new minor version. Anyone building from source inherits that constraint.

Upgrade cost is mostly operational. Because Barman holds the catalogue of your backups, upgrading the backup host is not a routine package bump. The README does not describe a rollback path, and the release notes are the only place in the repository where upgrade behaviour would be documented.

## Conclusion

Adopt Barman if you run several PostgreSQL clusters and want one control host that takes remote backups and keeps retention policies for all of them, and if a GPL-3.0 tool maintained by EnterpriseDB fits your environment. Do not adopt it if you need a tool with no Python runtime on the backup host, or if you cannot place a dedicated backup host with network access to every database server. Before committing, verify the exact package and version your distribution ships, check that your PostgreSQL version is supported by the Barman release you install, and confirm whether the optional cloud or snapshot extras you want are installed, since boto3 and the Azure libraries are separate optional dependencies in pyproject.toml.

## FAQ

### How do I install Barman for PostgreSQL?

The README does not give installation steps and points to the documentation at pgbarman.org/documentation and the GitHub repository for download. The package declares Python 3.12 or newer with psycopg2 and python-dateutil as runtime dependencies, plus optional extras for AWS snapshots, Azure and Azure snapshots.

### What is Barman in the context of PostgreSQL?

Barman stands for Backup and Recovery Manager for PostgreSQL. The README describes it as an open-source administration tool for disaster recovery of PostgreSQL servers written in Python, allowing remote backups of multiple servers in business critical environments.

### What is a Barman alternative for PostgreSQL?

The README does not name alternative tools, so no direct comparison can be made from it. What can be compared is the approach: Barman is a Python application that runs on a separate host and manages backups of multiple PostgreSQL servers from one catalogue, with optional AWS snapshot and Azure extras declared in pyproject.toml.

## Sources

- [EnterpriseDB/barman on GitHub](https://github.com/EnterpriseDB/barman)
- [License: GPL-3.0](https://github.com/EnterpriseDB/barman/blob/master/LICENSE)
- [Project website](https://www.pgbarman.org/)
- [README](https://github.com/EnterpriseDB/barman/blob/master/README.md)
- [Releases](https://github.com/EnterpriseDB/barman/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/enterprisedb-barman