Skip to content

Barman

Barman stores PostgreSQL backups and archived changes for recovery. A separate backup server can manage copies from more than one PostgreSQL server.

Visit Barman

Does keeping three copies mean you can recover any time this week?

Barman can retain a number of recent backups or keep what is needed for a recovery window, a period stretching back from now. A time target needs a usable backup that finished before it and the archived change log through the target. A count of backups alone does not prove that window.

The archived change log is called WAL. Check which PostgreSQL server the backup came from and use a timestamp with a time zone. The Barman guide says a target time inside one backup needs the preceding backup.

Where can you inspect a recovered copy?

Barman can restore to a local directory or a separate server reached through SSH, a secure remote connection. Use an empty isolated target with enough room for backup files and the archived change log. Confirm where the restored server will read the log and that it will not join the live app or write to its backup system.

Before starting the isolated PostgreSQL server, check that the account running it can read the restored data files and fetch the archived log. If tables use separate storage locations, check where they will be restored too. Test records, user access and any external file references independently before reconnecting anything.

What do you pay for when Barman is open source?

Barman is GPL-licensed open-source software. You still run the backup host, keep copies and change logs, and provide storage and network capacity for recovery. The longer the recovery window and the more changes your database makes, the more data you may need to retain.

Keep the backup inventory, recovery configuration and separately protected credentials. If your app uses files or a separate sign-in service, keep its own recovery records.

How can you choose a backup when the error happened during one?

Draw a fictional server with a completed 8 a.m. backup and another that ran from 9 to 9:40. Use no server, password or remote connection.

  1. Choose a target with a time zone
    The mistake happened at 9:30 UTC. Choose 9:29 UTC and mark the 8 a.m. backup as the candidate because the later one was still running at the target.
  2. Check what has to be present
    Mark the archived log from the earlier copy through 9:29. If a segment is missing, leave recovery to that point unverified.
  3. Name what would prove recovery
    On a separate test copy, expect a fictional booking made at 9:20 to be present and the 9:30 change to be absent. Mark files and access as their own checks.