failing to run barman backup

[anarcat]

Hi,

I've tried to follow the streaming replication setup in the documentation. I have a valid password for the backup server to connect to the psql server, and it seems to work, barman check is mostly ok except the WAL archive line:

barman@backup-storage-01:~$ barman check  weather-01
Server weather-01:
        WAL archive: FAILED (please make sure WAL shipping is setup)
        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 (0 B)
        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 0 backups, expected at least 0)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        systemid coherence: OK (no system Id stored on disk)
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: OK
        archiver errors: OK

So I tried to setup the archive_command (which i assume is what WAL shipping refers to), even though i have streaming replciation going and an actual WAL file in /var//lib/barman/weather-01/streaming/0000000100000019000000DE.partial.

When I run barman backup weather-01 it fails with:

ERROR: Impossible to start the backup. Check the log for more details, or run 'barman check weather-01'

and the logfile says:

2024-09-23 20:24:35,596 [756535] barman.server ERROR: Check 'WAL archive' failed for server 'weather-01'
2024-09-23 20:24:18,006 [756530] barman.server ERROR: Impossible to start the backup. Check the log for more details, or run 'barman check weather-01'

what am i missing? i don't have an SSH connection from the backup server to the postgresql server (since it doesn't seem to me that's necessary), is that the missing bit?

[stephane-klein]

@anarcat I have the same problem, have you found a solution?

[anarcat]

@anarcat I have the same problem, have you found a solution?

not really, unless you count "switching to pgbackrest" to be a solution. :)

[martinmarques]

Hi,

Barman expects archiving to be working, and in order to verify that it checks if there are any WALs archived in the back_directory/wals/, which in your case would be /var/lib/barman/weather-01/wals/.

If there are no WALs there because this is a new server and has no activity yet, you can force a WAL switch on the postgres primary using SELECT pg_switch_wal() as a superuser, or through the barman server using barman switch-wal weather-01. Once Postgres switches to the next WAL, the previous is ready to be archived. Just wait one minute for the scheduler to run barman cron or execute it manually to get the WAL archived to the final destination.

One other thing, you don't need archiver = true if you are streaming WALs with streaming_archiver.

I hope this is what you were looking for.

In any case, I'd like the feedback from both @anarcat and @stephane-klein on the experience with the docs. Is there some room for improvement (I surely think there is, but would like some feedback on what is missing or what should change)

[stephane-klein]

I'd like the feedback from both @anarcat and @stephane-klein

See #1067

[anarcat]

In any case, I'd like the feedback from both @anarcat and @stephane-klein on the experience with the docs. Is there some room for improvement (I surely think there is, but would like some feedback on what is missing or what should change)

it was a long journey for us, i'm not sure i can provide constructive, targeted feedback here. the gory details are in this issue:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/40950#note_3082333

what i noted there was:

it's one giant document that you need to jump around to configure things, and it's not always clear what actually needs to be done.

in our service notes, i said:

Debugging was difficult, documentation was confusing, and it just didn't actually work