LoginSign Up
← Back to all sparks
B

Barman

DEVOPS
Velocity2.5

Backup and recovery manager for PostgreSQL

pgbarman.org ↗

Barman's cloud lifecycle is closed; 3.20.0 starts hardening it for regulated storage.

postgresqlbackupobject-storageencryptiondata-residencydisaster-recovery
◆Current state
The arc that ran through 3.18.0 (block-level incremental backups written straight to object storage) and 3.19.0 (restoring from that storage with the standard restore command) is complete. 3.20.0 works the edges of it: SSE-C server-side encryption with customer-supplied keys across every barman-cloud command, parallel uploads to Google Cloud Storage, S3 access point ARNs including S3 on Outposts, and EBS snapshots kept on the Outpost rather than the parent region. A new check-archived-wal-range command reports gaps in the WAL archive, and the minimum Python is now 3.12.
◆Where it's heading
With backup and restore both working against object storage, the work has moved to the requirements that decide whether a regulated shop can adopt it — who holds the encryption keys, whether data stays in a given location, and whether the archive can be proven complete. The inactive-server handling that began in 3.17.0 also continues: barman cron now stops WAL receivers left streaming on servers switched to active = false, and command behaviour on those servers has been made consistent, with commands that ingest new data still rejected.
◆Prediction
The Outposts and SSE-C work points toward more storage-backend and residency coverage rather than new backup mechanics. A 3.20.x patch settling the Python 3.12 floor or the new access-point handling is the more likely near-term release.

◆Recent moves

  1. 19d ago

    Python 3.12 floor, SSE-C keys and AWS Outposts support

    Raises the Python floor to 3.12 and spends the rest of the release on storage-side requirements: customer-supplied S3 encryption keys, parallel GCS uploads, S3 access point ARNs, and Outpost-local EBS snapshots for data residency. It rides the cloud lifecycle that 3.18.0 and 3.19.0 established rather than extending it, with a new check-archived-wal-range command to verify the archive has no missing segments.

    View source ↗
  2. 3mo 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 ↗
  3. 3mo 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 ↗
  4. 6mo 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 ↗
  5. 8mo 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 ↗
  6. 10mo 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 ↗