Learn pgBackRest - Remote Repository & Object Storage

#Introduction

So far our repository has been on the same host as the database. This works, but leaves one big gap: if that host dies — broken disk, seized machine, burned data center — the backup goes with it, along with the data it was supposed to protect. In episode 12 we move the repository out: to a remote host via SSH, or to S3-compatible object storage for cloud scale.

This is a crucial step toward real disaster recovery. A correct backup must always live somewhere that can't be lost at the same time as its data source.

#Remote Repository via SSH

#Concept

In a remote architecture, the database runs on host A and the repository is on host B. All backup operations are still triggered from host A, but files are written to host B over SSH. The advantage: full physical separation, and you directly control the storage media.

#Configuration

On the database host, add the remote repository options in /etc/pgbackrest.conf:

[global]
repo1-host = backup01.internal
repo1-host-user = postgres
repo1-path = /var/lib/pgbackrest
 
[main]
pg1-path = /var/lib/postgresql/16/main

• repo1-host — the host where the repository lives.
• repo1-host-user — the SSH user on that host (usually postgres or a dedicated pgbackrest user, episode 13).
• repo1-path — the repository directory on the remote host.

All pgBackRest commands run from the database host and connect to the remote host automatically. No need to run anything on host B — pgBackRest uses SSH according to the configuration.

#Verification and First Backup

sudo -u postgres pgbackrest --stanza=main check
sudo -u postgres pgbackrest --stanza=main backup --type=full

check validates the SSH connection to repo1-host — a connection error at this stage is almost always about SSH keys (not pgBackRest). Make sure key authentication works without a password (episode 13).

#S3-Compatible Repository (Object Storage)

#Concept

With repo1-type = s3, pgBackRest talks directly to S3-compatible object storage: AWS S3, MinIO, Cloudflare R2, Backblaze B2, or another S3 gateway. There's no SSH host to maintain — the storage media is managed by the cloud provider.

#Configuration

[global]
repo1-type = s3
repo1-s3-bucket = db-backup-prod
repo1-s3-endpoint = s3.ap-southeast-1.amazonaws.com
repo1-s3-region = ap-southeast-1
repo1-s3-key = AKIAXXXXXXXX
repo1-s3-key-secret = aBcDeFgH...
repo1-s3-uri-style = virtual-host

Options commonly adjusted:

• repo1-s3-endpoint — regional endpoint; for local MinIO, replace it with the MinIO host and repo1-s3-uri-style = path.
• repo1-s3-key / repo1-s3-key-secret — static credentials.
• repo1-s3-region — bucket region.
• repo1-s3-role — a credentials alternative: use an IAM role instead of static keys (we cover this in episode 20).

#Backup to S3

After the config, the flow is exactly the same:

sudo -u postgres pgbackrest --stanza=main stanza-create
sudo -u postgres pgbackrest --stanza=main check
sudo -u postgres pgbackrest --stanza=main backup --type=full

Notice that the stanza, check, and backup concepts don't change — only the storage location differs. This is the strength of pgBackRest's design: one workflow, many media.

#Two Repositories at Once: Local + Off-Site

pgBackRest supports repo1 and repo2 simultaneously. A common production pattern: repo1 local (fast RTO) + repo2 S3 (off-site/archive).

[global]
repo1-path = /var/lib/pgbackrest
 
repo2-type = s3
repo2-s3-bucket = db-backup-archive
repo2-s3-endpoint = s3.ap-southeast-1.amazonaws.com
repo2-s3-region = ap-southeast-1
repo2-s3-key = AKIAXXXXXXXX
repo2-s3-key-secret = aBcDeFgH...

When backing up, use --repo1 --repo2 (the default when both are configured). Restore can pull from either repository:

sudo -u postgres pgbackrest --stanza=main --repo=2 restore

This combination answers two needs at once: speed (local) and location security (cloud).

#Use Cases: Off-Site and Cheap Storage

• Off-site backup: S3/remote host at a different location → survives fire, theft, or regional disasters. This is a mandatory requirement for a serious production architecture.
• Cheap storage: object storage enables long retention (audit archives, compliance) without maintaining your own disks. Old backups can live on S3 at low cost.

#Conclusion

Key takeaways:

• A remote repository via repo1-host + SSH physically separates data and backups.
• S3-compatible (repo1-type = s3) stores backups in provider-managed object storage.
• The stanza/check/backup workflow doesn't change — only the storage media.
• Combining local repo1 + S3 repo2 gives fast RTO and an off-site archive.
• S3 credentials are secrets — secure them like the encryption passphrase.

In the next episode we'll secure the transport path: SSH & networking — creating a dedicated pgbackrest user with key authentication, configuring access via pg1-host/repo1-host and SSH options in the config, plus network rules: don't expose the backup server, use VPN or tunnels for remote. Data security in transit is half of overall security!