Storage AWS

Barman for PostgreSQL on AWS User Guide

Last updated: 2026-07-21 | Product: Barman for PostgreSQL on AWS

Overview

This image runs Barman (Backup and Recovery Manager), the open source disaster-recovery manager for PostgreSQL from EnterpriseDB. Barman manages base backups and continuous write-ahead-log (WAL) archiving for one or more PostgreSQL servers and performs point-in-time recovery, so you can restore a database to any moment inside your retention window. The image ships Barman 3.19.1 with a bundled PostgreSQL 16 source (both from the official PostgreSQL PGDG package repository) wired together as a fully working demonstration, so a real base backup is taken and verified the moment your instance boots.

This is a headless image. There is no web interface; you operate it over SSH as the barman system user. The bundled PostgreSQL source binds to loopback only on 127.0.0.1:5432 and is never exposed to the network. Barman connects to it over a streaming replication connection using a named replication slot, so no WAL is lost, and takes physical base backups with pg_basebackup.

On the first boot of your instance a one-shot service generates fresh, strong passwords for the PostgreSQL, Barman, and replication roles, unique to that instance, writes them only to the Barman user's protected ~/.pgpass, creates the replication slot, takes the first base backup, and confirms the backup source is fully healthy before completing. No shared or default database credentials ship in the image.

The entire Barman catalogue, every base backup and every streamed WAL segment, lives on a dedicated, independently resizable EBS data volume mounted at /var/lib/barman, so your backups sit on durable storage that you can grow, snapshot, and back up independently of the operating system disk.

cloudimg is not affiliated with or endorsed by EnterpriseDB. Barman is a project of EnterpriseDB Corporation.

Prerequisites

Before you deploy this image you need:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network
The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Recommended instance type: m5.large (2 vCPU, 8 GB RAM) or larger. Barman benefits from additional memory and I/O headroom as the number of protected servers and the size of the catalogue grow.

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for Barman. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network. The dedicated Barman catalogue volume is attached automatically from the image.

Select Launch instance. First boot initialisation runs once after the instance state becomes Running and the status checks pass: it brings up PostgreSQL, rotates the per-instance passwords, creates the replication slot, takes the first base backup, and verifies backup health. This takes a minute or two on first boot.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg Barman Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <sub-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <sub-id> \
  --security-group-ids <security-group-id> \
  --metadata-options HttpTokens=required \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=barman}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Step 3: Connect to Your Instance

Connect over SSH using your key pair and the login user for your operating system variant.

OS variant	Login user
Ubuntu 24.04	`ubuntu`

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

The message of the day summarises the key Barman commands. Everyday Barman commands run as the barman system user via sudo -u barman.

Step 4: Confirm the Backup Source Is Healthy

Barman's check command verifies every part of the backup pipeline for a server: the PostgreSQL connection, backup privileges, streaming replication, the WAL level, the replication slot, WAL streaming (receive-wal), the archiver, and the retention policy. On this image the bundled server is named pg.

systemctl is-active postgresql@16-main.service
sudo -u barman barman check pg

Every line should report OK, confirming the backup source and WAL streaming are healthy.

barman check pg reporting every backup, streaming replication, WAL archiving and retention check OK, with the bundled PostgreSQL 16 source active

Step 5: List and Inspect Backups

A base backup is taken automatically on first boot. List the catalogue and inspect the most recent backup. The catalogue lives on the dedicated EBS volume mounted at /var/lib/barman.

sudo -u barman barman list-backup pg
sudo -u barman barman show-backup pg latest

show-backup reports the backup status (DONE), the backup method (postgres, meaning a streaming pg_basebackup), the PostgreSQL version, and the estimated size.

barman list-backup and show-backup showing real base backups in the catalogue on the dedicated EBS volume, with backup method postgres and status DONE

Step 6: Take a Backup on Demand

You can take a base backup at any time. A scheduled base backup also runs daily at 01:30 by cron, and barman cron maintains WAL streaming every minute.

sudo -u barman barman switch-wal --force --archive pg
sudo -u barman barman backup pg --wait
sudo -u barman barman list-backup pg

Step 7: Point-in-Time Recovery

barman recover restores a chosen backup (plus the WAL needed to reach a target time) into a target directory, producing a ready-to-start PostgreSQL data directory. The example restores the latest backup into /var/tmp/restore.

sudo rm -rf /var/tmp/restore
sudo install -d -o barman -g barman /var/tmp/restore
sudo -u barman barman recover pg latest /var/tmp/restore
sudo ls /var/tmp/restore

To recover to a specific moment instead of the latest state, add --target-time "YYYY-MM-DD HH:MM:SS". On Debian and Ubuntu the PostgreSQL configuration files live under /etc/postgresql/16/main; copy them alongside the recovered data directory (or supply a config_file) before starting the recovered cluster.

barman recover restoring the latest base backup to a target directory and pg_controldata confirming a structurally valid recovered PostgreSQL data directory

Step 8: The Backup Catalogue Volume

The Barman catalogue is stored on a dedicated EBS volume, separate from the operating system disk, so your backups are isolated, easy to snapshot off-instance, and simple to resize.

df -h /var/lib/barman
findmnt /var/lib/barman

Because the mount is defined by filesystem UUID in /etc/fstab, it re-attaches automatically on every boot. Use Amazon EBS Snapshots to copy the catalogue off-instance, or grow the volume in the EC2 console and extend the filesystem to increase capacity.

Step 9: Back Up Your Own PostgreSQL Servers

The bundled pg server is a working demonstration. To protect your production databases, add a Barman server configuration under /etc/barman.d/ that points at your PostgreSQL host, grant Barman a replication connection on that host, and open network reachability from this instance to your database (a security group rule for the PostgreSQL port, typically 5432, on the private network). Barman can manage many servers from this one host, each with its own retention policy. See the official Barman documentation for the streaming and rsync/SSH backup methods and for multi-server topologies.

Support

cloudimg provides 24/7 technical support for this image by email and live chat. Our engineers assist with deployment, Barman configuration, multi-server setup, WAL archiving and streaming, retention policy design, and point-in-time recovery. Contact support@cloudimg.co.uk with your instance ID, Region, and a description of your question. For refund requests, email the same address with your AWS Marketplace subscription details.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.