Barman 3.20.1

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Barman 3.20.1 on Ubuntu 24.04 as the software version and select your Region. Choose Launch through EC2, then select m5.large, your key pair, a security group as described above, and a root volume large enough for the backups you plan to keep.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=<size-in-GiB>,VolumeType=gp3}' \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=barman}]'

Version SSH user

Barman 3.20.1 on Ubuntu 24.04 ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot takes about 20 seconds. It creates the PostgreSQL cluster, its certificate and the role passwords, starts WAL streaming and takes the first base backup. Afterwards, the WAL receiver, PostgreSQL and both timers are active:

systemctl is-active barman.timer barman-backup.timer barman-receive-wal@pg.service postgresql@16-main.service
sudo test -f /var/lib/sac/data/barman-firstboot.done && echo FIRSTBOOT_DONE

active active active active FIRSTBOOT_DONE

barman.timer runs barman cron every minute, which keeps WAL streaming alive and archives incoming WAL. barman-backup.timer runs the daily base backup.

PostgreSQL listens on loopback only, and SSH is the only network listener:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | sed -E 's/pid=[0-9]+,fd=[0-9]+/.../g' | sort

0.0.0.0:22 users:(("sshd",...),("systemd",...)) 127.0.0.1:5432 users:(("postgres",...)) 127.0.0.53%lo:53 users:(("systemd-resolve",...)) 127.0.0.54:53 users:(("systemd-resolve",...)) [::]:22 users:(("sshd",...),("systemd",...))

First boot writes a short root-only note. The note holds no secret. The role passwords live only in /var/lib/barman/.pgpass. Read the note:

sudo cat /root/barman-credentials.txt

# Barman 3.20.1 on Ubuntu 24.04 - first-boot details, unique to this instance (root only). barman.host=<private-ip> barman.server=pg barman.backup_method=postgres (pg_basebackup over streaming replication) barman.wal_streaming=on (replication slot barman, barman-receive-wal@pg.service) barman.schedule=barman-backup.timer, daily 01:30 UTC (barman backup all) postgres.listen=127.0.0.1:5432 and [::1]:5432 only (no public database port) postgres.tls.sha256=<POSTGRES_TLS_SHA256> roles=barman (backup functions only, not superuser), streaming_barman (REPLICATION) role.logins=passwords are generated on first boot and kept only in /var/lib/barman/.pgpass (mode 0600, owner barman)
#
# Everyday use:
#
sudo -u barman barman check pg health of the source and WAL streaming
#
sudo -u barman barman list-backups pg the backup catalogue
#
sudo -u barman barman backup pg --wait take a base backup now
#
sudo barman-selftest backup + restore proof on this instance
# Guide: https://secureanycloud.com/stacks/barman-3-20-1/

Your instance shows its own private address and certificate fingerprint.

Barman's health check covers the connection, WAL streaming, the replication slot, the retention policy and the backups:

sudo -u barman barman check pg

Server pg: PostgreSQL: OK superuser or standard user with backup privileges: OK PostgreSQL streaming: OK wal_level: OK replication slot: OK directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) backup minimum size: OK (22.2 MiB) wal maximum age: OK (no last_wal_maximum_age provided) wal size: OK (0 B) compression settings: OK failed backups: OK (there are 0 failed backups) minimum redundancy requirements: OK (have 1 non-incremental backups, expected at least 1) pg_basebackup: OK pg_basebackup compatible: OK pg_basebackup supports tablespaces mapping: OK systemid coherence: OK pg_receivexlog: OK pg_receivexlog compatible: OK receive-wal running: OK archiver errors: OK

The catalogue already holds the base backup that was taken on first boot:

sudo -u barman barman list-backups pg

pg 20261108T154819 - F - Sun Nov 8 15:48:20 2026 - Size: 38.2 MiB - WAL Size: 0 B

WAL is streamed by streaming_barman through the slot barman:

sudo -u barman barman replication-status --target wal-streamer pg | grep -E 'Application name|User name|Current state|Replication slot'

Application name: barman_receive_wal User name : streaming_barman Current state : streaming (async) Replication slot: barman

Show the details of one backup. Use an ID from list-backups, or latest:

sudo -u barman barman show-backup pg latest | grep -E 'Status|Backup Method|Backup Size|Begin WAL|Begin time|End time'

Status : DONE Backup Method : postgres Backup Size : 22.2 MiB (38.2 MiB with WALs) Begin WAL : 000000010000000000000003 Begin time : 2026-11-08 15:48:19.829596+00:00 End time : 2026-11-08 15:48:20.248134+00:00

sudo -u barman barman backup pg --wait sudo -u barman barman list-backups pg --minimal

--wait returns once the WAL that the backup needs has been archived, so you can use the new backup for a restore immediately. With REDUNDANCY 2, Barman keeps the two newest base backups (and the WAL they need) and removes older ones during barman cron.

barman-selftest checks the whole backup and restore path without touching your data. It writes a random marker row into a scratch table of the local source, takes a base backup, writes a second marker, and switches and archives the WAL. It restores the latest backup with barman recover into a private temporary directory, starts a throwaway PostgreSQL on the restored copy (no network listener) and checks that both markers are there. It then removes everything it made. The test takes about 30 seconds:

sudo barman-selftest 2>&1 | tail -2

barman-selftest: backup 20261108T154848 restored; base-backup and WAL-replayed markers both present in the recovered copy BARMAN_SELFTEST_OK 20261108T154848

The self-test adds a base backup to the catalogue. The retention policy treats it like any other backup.

barman recover writes a complete PostgreSQL data directory from a backup and the archived WAL. Restore into an empty directory owned by barman (here on this instance). Use your own directory and, for point-in-time recovery, a target time:

sudo install -d -o barman -g barman -m 0700 <restore-directory>
sudo -u barman barman recover pg latest <restore-directory>
sudo -u barman barman recover pg latest <restore-directory> --target-time "<YYYY-MM-DD HH:MM:SS+00>"

To restore straight onto another server over SSH, add --remote-ssh-command "ssh postgres@<pg-host>". That host must trust the SSH key of this instance's barman user. Start PostgreSQL on the restored directory with the same major version as the backup.

Each server that Barman protects is defined in one file in /etc/barman.d/. On the PostgreSQL server you want to back up (not on this instance), create the two roles with passwords of your own and allow this instance in its pg_hba.conf:

-- on the PostgreSQL server, as a superuser CREATE ROLE barman LOGIN PASSWORD '<barman-password>'; GRANT EXECUTE ON FUNCTION pg_backup_start(text, boolean) TO barman; GRANT EXECUTE ON FUNCTION pg_backup_stop(boolean) TO barman; GRANT EXECUTE ON FUNCTION pg_switch_wal() TO barman; GRANT EXECUTE ON FUNCTION pg_create_restore_point(text) TO barman; GRANT pg_read_all_settings, pg_read_all_stats, pg_checkpoint TO barman; CREATE ROLE streaming_barman LOGIN REPLICATION PASSWORD '<streaming-password>';

# pg_hba.conf on the PostgreSQL server: this instance's private address only hostssl all barman <barman-instance-ip>/32 scram-sha-256 hostssl replication streaming_barman <barman-instance-ip>/32 scram-sha-256

The server also needs wal_level = replica (the default) and free max_wal_senders and max_replication_slots. Then, on this instance, add the passwords to /var/lib/barman/.pgpass and add a server file. Here <server> is a short name of your choice:

printf '%s\n' '<pg-host>:5432:*:barman:<barman-password>' '<pg-host>:5432:*:streaming_barman:<streaming-password>' | sudo -u barman tee -a /var/lib/barman/.pgpass >/dev/null
sudo tee /etc/barman.d/<server>.conf >/dev/null <<'EOF' [<server>] description = "Production PostgreSQL" conninfo = host=<pg-host> port=5432 user=barman dbname=postgres sslmode=require streaming_conninfo = host=<pg-host> port=5432 user=streaming_barman dbname=postgres sslmode=require backup_method = postgres streaming_archiver = on slot_name = barman create_slot = auto retention_policy = RECOVERY WINDOW OF 7 DAYS EOF
sudo -u barman barman cron
sudo -u barman barman check <server>
sudo -u barman barman backup <server> --wait

barman cron (every minute) creates the replication slot and starts barman-receive-wal@<server>.service for the new server. The daily timer backs it up with the others (barman backup all). When you no longer need the demo source, remove /etc/barman.d/pg.conf and stop postgresql@16-main.service.

systemctl list-timers barman.timer barman-backup.timer grep -vE '^[[:space:]]*(;|$)' /etc/barman.d/pg.conf

To change the backup time, override the timer with sudo systemctl edit barman-backup.timer (for example OnCalendar=*-*-* 03:00:00 UTC). To change retention_policy and minimum_redundancy, edit the server's file in /etc/barman.d/. Both settings apply per server.

The Barman services (and PostgreSQL) are denied the instance metadata service and reserved address ranges:

systemctl show barman.service -p IPAddressDeny --value | tr ' ' '\n' | sort

168.63.129.16/32 169.254.169.254/32 192.0.0.0/24 198.18.0.0/15 224.0.0.0/4 240.0.0.0/4 fd00:ec2::254/128

Barman can still reach your PostgreSQL servers in the VPC, because connecting to them is its job. Only root can add a server to /etc/barman.d/. The services run as the unprivileged barman user with systemd sandboxing:

systemctl show barman.service -p User -p NoNewPrivileges -p ProtectSystem -p ProtectHome -p PrivateTmp

User=barman PrivateTmp=yes ProtectHome=yes ProtectSystem=full NoNewPrivileges=yes

Neither Barman role is a superuser, and the secrets are readable by their owner only:

sudo -u postgres psql -X -tA -c "SELECT rolname, rolsuper, rolreplication FROM pg_roles WHERE rolname IN ('barman','streaming_barman') ORDER BY 1"
sudo stat -c '%a %U %n' /var/lib/barman/.pgpass /root/barman-credentials.txt /etc/postgresql/16/main/tls/server.key
sudo openssl x509 -in /etc/postgresql/16/main/tls/server.crt -noout -fingerprint -sha256 | cut -d= -f2

barman|f|f streaming_barman|f|t 600 barman /var/lib/barman/.pgpass 600 root /root/barman-credentials.txt 600 postgres /etc/postgresql/16/main/tls/server.key <POSTGRES_TLS_SHA256>

The local source's pg_hba.conf admits local OS users by peer authentication. It admits the two Barman roles over TLS on loopback only:

sudo grep -vE '^[[:space:]]*(#|$)' /etc/postgresql/16/main/pg_hba.conf

local all all peer hostssl all barman 127.0.0.1/32 scram-sha-256 hostssl all barman ::1/128 scram-sha-256 hostssl replication streaming_barman 127.0.0.1/32 scram-sha-256 hostssl replication streaming_barman ::1/128 scram-sha-256

Component Path

Barman /usr/bin/barman (packages barman, barman-cli, python3-barman 3.20.1)

Global configuration /etc/barman.conf (as packaged)

Server definitions /etc/barman.d/*.conf (pg.conf is the local demo source)

Backups, WAL and catalogue /var/lib/barman/<server>/

Logs /var/log/barman/barman.log, journalctl -u barman -u 'barman-receive-wal@*' -u barman-backup

Service units barman.timer, barman.service, barman-receive-wal@.service (upstream), barman-backup.timer, barman-backup.service, barman-firstboot.service, with SecureAnyCloud drop-ins in /etc/systemd/system/<unit>.d/

Demo source PostgreSQL 16 cluster 16/main, configuration in /etc/postgresql/16/main/

Helpers /usr/local/sbin/barman-selftest

Licence and provenance /usr/share/doc/barman/

barman --version 2>&1 | head -1 dpkg-query -W -f '${Package} ${Version}\n' barman barman-cli python3-barman postgresql-16

3.20.1 Barman by EnterpriseDB (www.enterprisedb.com) barman 3.20.1-1.pgdg24.04+1 barman-cli 3.20.1-1.pgdg24.04+1 postgresql-16 16.15-1.pgdg24.04+2 python3-barman 3.20.1-1.pgdg24.04+1

• Allow port 22 in the security group from your own networks only. Allow this instance into your database servers' security groups on 5432 by its private address or security group, never from the internet.
• Use hostssl and scram-sha-256 for the Barman roles on your servers, and keep /var/lib/barman/.pgpass at mode 0600.
• Keep a copy of the backups off the instance. Take EBS snapshots of the volume that holds /var/lib/barman, or copy the backups to another region.
• Monitor with sudo -u barman barman check all --nagios, and run sudo barman-selftest after configuration changes.
• Keep the operating system patched. Unattended security upgrades are on, and sudo apt-get update && sudo apt-get upgrade applies everything else, including new Barman and PostgreSQL releases from apt.postgresql.org.