LoginSign Up
← Back to all sparks
B

Barman

DEVOPS
Velocity0.0

Backup and recovery manager for PostgreSQL

pgbarman.org ↗

Barman is finishing its move from a backup host to a cloud-native lifecycle.

postgresqlbackupobject-storageincremental-backupdisaster-recoveryencryption
◆Current state
EnterpriseDB has spent the last four releases rebuilding Barman around object storage. 3.18.0 added block-level incremental backups direct to cloud with only a small staging area on the Barman host; 3.19.0 closed the loop with cloud restore and a dedicated cloud-wal-restore command. Encryption and compression restrictions on incremental backups were removed in 3.14/3.15, and the release notes are unusually detailed — each change carries a rationale and a BAR- ticket reference.
◆Where it's heading
The Barman host is being demoted from storage tier to control plane. Every recent release moves another operation that required local disk into object storage, and the deprecations follow the same line — local_staging_path and recovery_staging_path replaced by a generic staging_path plus staging_location. The care taken over CloudNativePG compatibility in 3.16.1 shows Kubernetes-operator deployments are now a constituency worth issuing a point release for.
◆Prediction
Expect the remaining barman-cloud-* standalone scripts to be folded into the main barman command surface, continuing the pattern set by cloud-wal-restore. Deprecated compression and staging options are the likely removals in the next major.

◆Recent moves

  1. 2mo ago

    Fix cloud-wal-restore missing prefix-colliding WAL files

    A single-bug patch shipped six days after 3.19.0, fixing WAL lookup when a backup file shares a prefix with the requested WAL segment in the same bucket. Routine cleanup on newly released cloud restore code.

    View source ↗
  2. 2mo ago

    Cloud restore closes Barman's object-storage lifecycle

    ⚡ SPARK

    3.19.0 makes backups stored in object storage restorable through the standard barman restore command and adds cloud-wal-restore for parallel WAL fetching during recovery. Together with the cloud incremental backups added in 3.18.0, it completes the arc this product has been on for a year — cloud as a first-class location rather than an archive destination.

    View source ↗
  3. 4mo ago

    Block-level incremental backups land in cloud storage

    ⚡ SPARK

    3.18.0 brought block-level incremental backups to cloud storage, streaming pg_basebackup output through a bounded staging directory so the full backup never lands on the Barman host. This is the release that made the cloud path viable at size; 3.19.0 is its restore-side completion.

    View source ↗
  4. 7mo ago

    Query and restore now work on inactive servers

    Query, fetch, and modification commands now work against inactive and disabled servers, with the permitted operations graded by safety. Practical operational relief — restoring from a server you have deliberately switched off no longer requires re-enabling it first.

    View source ↗
  5. 9mo ago

    Detect MissingContentMD5 errors by message on S3-compatible stores

    A narrow compatibility patch for S3-compatible storage that returns InvalidRequest instead of MissingContentMD5 on delete, now detected by inspecting the error text. The kind of fix that accumulates as the cloud paths meet real-world object stores.

    View source ↗
  6. 9mo ago

    Bucket auto-creation returns for CloudNativePG compatibility

    Restores automatic bucket creation in barman-cloud-check-wal-archive after 3.16.0 moved it and broke CloudNativePG automation. Notable less for the fix than for what it signals: the project shipped a point release, developed with the CNPG team, to unbreak a Kubernetes operator's workflow.

    View source ↗