LoginSign Up
← Back to all sparks
B

Barman

DEVOPS
Velocity0.0

Backup and recovery manager for PostgreSQL

pgbarman.org ↗

Barman 3.20.1 closes a CVE that let a writable catalog delete unrelated snapshots.

postgresqlbackupobject-storagesecurityleast-privilegedisaster-recovery
◆Current state
Barman 3.20.1 fixes CVE-2026-93853: Barman trusted snapshot IDs from the backup catalog, so anyone able to overwrite backup.info could make it delete unrelated cloud snapshots with Barman's own credentials. It now checks snapshot names against provider metadata before deleting. 3.20.0 in August raised the Python floor to 3.12 and added SSE-C encryption, parallel GCS uploads and S3 Outposts support.
◆Where it's heading
After closing the cloud backup-and-restore loop in 3.18 and 3.19, Barman is hardening it for regulated, least-privilege setups: customer-supplied keys, data kept on Outposts, and now a fix aimed exactly at deployments where the uploading identity has fewer rights than Barman. Releases come roughly every two to three months.
◆Prediction
A 3.21.0 feature release is the likely next step on the usual cadence, probably continuing cloud storage and retention safety work.

◆Recent moves

  1. 1mo ago

    CVE fix: forged catalog could delete unrelated cloud snapshots

    Fixes a privilege escalation where a principal that could overwrite the backup catalog could get Barman to delete unrelated cloud snapshots on AWS, Azure or GCP. It matters most for the least-privilege setups Barman itself recommends.

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