barman check - incoming' must be empty when archiver=off

[dulh...@mailbox.org]

I get this error on barman check

[barman@barman-paper ~]$ barman check postgres-local
Server postgres-local:
    empty incoming directory: FAILED ('/var/lib/barman/postgres-local/incoming' must be empty when archiver=off)

however, the only appearance if something name 'archiver' in the configuration (.../conf.d/localhost.conf) indicates it is on

[barman@barman-paper ~]$ grep -r streaming_archiver /etc/barman.d/localhost.conf
streaming_archiver = on
;streaming_archiver_name = barman_receive_wal
;streaming_archiver_batch_size = 50

so is there any other component named archiver which may be causing this?
Or is it required to clear the .../incoming folder manually in order to being able to do a new backup.

here are some recurring lines from the log

2022-03-06 12:15:38,543 [1637] barman.wal_archiver INFO: No xlog segments found from streaming for postgres-local.
2022-03-06 12:15:45,330 [1638] barman.server ERROR: Check 'empty incoming directory' failed for server 'postgres-local'
2022-03-06 12:23:01,840 [1823] barman.server INFO: Another cron process is already running on server postgres-local. Skipping to the next server

[Luca Ferrari]

On Sun, Mar 6, 2022 at 1:43 PM dulhaver via Barman, Backup and
Recovery Manager for PostgreSQL <pgba...@googlegroups.com> wrote:
> [barman@barman-paper ~]$ grep -r streaming_archiver /etc/barman.d/localhost.conf
> streaming_archiver = on
> ;streaming_archiver_name = barman_receive_wal
> ;streaming_archiver_batch_size = 50

AFAIK there is a setting named 'archiver' that should be off by
default if there's another strategy, as it seems from your
configuration file.

Luca

[Michael Wallace]

There are two different types of archiver supported by Barman:

* `archiver = on` configures Barman for standard WAL archiving, where PostgreSQL copies WALs into the `incoming` directory via its `archive_command`. Barman will then move WALs from `incoming` into the `wals` directory when `barman cron` runs.

* `streaming_archiver = on` configures Barman for WAL streaming, where it spawns a `pg_receivewal` process which streams WALs into the `streaming` directory. Once a WAL segment is complete Barman will move it from `streaming` into the `wals` directory when `barman cron` runs.

If WALs are appearing in `incoming` but the standard archiver is not enabled then Barman considers this an error condition, since WALs are just going to accumulate in `incoming` and serve no useful purpose.

Since the standard WAL archiver is disabled by default and you have enabled the streaming archiver, you could try the following:

1. Verify that WAL streaming is working.

2. Check whether PostgreSQL has `archive_command` configured to copy WALs into Barman's `incoming` directory for that server - if so you should disable it.

3. Move the WALs in `incoming` somewhere safe rather than deleting them, just in case you end up needing them later.

--
--
You received this message because you are subscribed to the "Barman for PostgreSQL" group.
To post to this group, send email to pgba...@googlegroups.com
To unsubscribe from this group, send email to
pgbarman+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pgbarman?hl=en?hl=en-GB

---
You received this message because you are subscribed to the Google Groups "Barman, Backup and Recovery Manager for PostgreSQL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pgbarman+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pgbarman/CAKoxK%2B58SBoPUG8kOQGJT2HJCLkEBLGm%3DyQ-gT09LRWLWKCtug%40mail.gmail.com.

[dulh...@mailbox.org]

thx for the explanation & recommendations

> 3. Move the WALs in `incoming` somewhere safe rather than deleting them, just in case you end up needing them later.

so you recommend to do that every time before I run a backup

It feels a bit weird to use a tool such as barman, but in order to making it work having to do such manual or scripted work each and every time before running a backup (especially as none of this is mentoned in the manual as far as I can tell [the manual being so hard to not get lost in I could be wrong though]).

can't I add archiver = on to my configuration file (then contain both streaming_archiver = on as well as archiver = on) to satisfy barmans desires?

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/pgbarman/CAGxDL9LexyOs9DO2Aw7VyqD2ZeR%3DsRz89h9nrOo7vQkWjgcyRA%40mail.gmail.com.

[Michael Wallace]

I'm recommending you clear the incoming directory as a one-off job - if WALs are still being copied into `incoming` then whatever is doing that should be stopped. Typically that would be PostgreSQL via `archive_command`, hence my suggestion of checking `archive_command` in postgresql.conf.

As an alternative you could indeed add `archiver = on` and use both the streaming archiver and the non-streaming archiver.

To view this discussion on the web, visit https://groups.google.com/d/msgid/pgbarman/1923735430.882620.1646651113200%40office.mailbox.org.

[dulh...@mailbox.org]

On 07.03.22 12:35, Michael Wallace wrote:

I'm recommending you clear the incoming directory as a one-off job - if WALs are still being copied into `incoming` then whatever is doing that should be stopped. Typically that would be PostgreSQL via `archive_command`, hence my suggestion of checking `archive_command` in postgresql.conf.

I have been trying to get this running for  quite a while and the archive_command plaid the main painpoint in this I think.
Running on a local setup for testing (where postgres and barman live on the same machine) this is what I figured out finally

archive_command = 'barman-wal-archive localhost postgres-local /var/lib/pgsql/14/data/%p'

apparently that is still not right (even though it should not be writing into the incoming dir (living at /var/lib/barman/[postgres-server]/incoming)
Can anyone here recommend an archive command under these conditions? It looks like I am not getting the logic behind it myself yet.

As an alternative you could indeed add `archiver = on` and use both the streaming archiver and the non-streaming archiver.

that actually seems to work with the archive_commmand mentioned above. I am not understanding the different though.
Is there anything that would be recommended?

To view this discussion on the web, visit https://groups.google.com/d/msgid/pgbarman/CAGxDL9%2Bk%2BvY%3DaJCNNTMi%2BaDjpHdSs%3DcZXqaDX2m32Yy2F5UvYA%40mail.gmail.com.

[Luca Ferrari]

On Mon, Mar 7, 2022 at 3:06 PM dulhaver via Barman, Backup and
Recovery Manager for PostgreSQL <pgba...@googlegroups.com> wrote:
> archive_command = 'barman-wal-archive localhost postgres-local /var/lib/pgsql/14/data/%p'

The archive_command is something the PostgreSQL executes to archive
WALs, while you are doing streaming, that means barman will ask
PostgreSQL for new WALs.
In other words, you need to disable archive_command, at least for what
I see in your desidered configuration.

> As an alternative you could indeed add `archiver = on` and use both the streaming archiver and the non-streaming archiver.
>
> that actually seems to work with the archive_commmand mentioned above. I am not understanding the different though.
> Is there anything that would be recommended?

The idea is this: with both streaming and archiving barman will ask
the WALs to PostgreSQL (streaming) and PostgreSQL will send
autonomously WALs to the barman machine (archiving). Therefore, barman
(as a whole) will always have the WALs in a way or the other.

Luca

[dulh...@mailbox.org]

On 07.03.22 15:48, Luca Ferrari wrote:

On Mon, Mar 7, 2022 at 3:06 PM dulhaver via Barman, Backup and
Recovery Manager for PostgreSQL <pgba...@googlegroups.com> wrote:

archive_command = 'barman-wal-archive localhost postgres-local /var/lib/pgsql/14/data/%p'

The archive_command is something the PostgreSQL executes to archive WALs, while you are doing streaming, that means barman will ask PostgreSQL for new WALs.

I guess this may be what the manual calls streaming-only which "does not require any SSH connection for backup and archiving operations. This is particularly suitable and extremely practical for Docker environments." I seem not being able to extract the right breadcrumbs applying for such a scenario from the manual to get this going. Definitely nothing works without ssh in the state I am in right now.

I wanted to go the streaming only road and was quite surprised that nothing worked without ssh. If there was any sort of article, how-to, blog-entry, ... which leads to a streaming only scenario I would be more then happy to follow that. The manual has caused quite a level of confusion to be honest.

On the other hand I am at a point where I do not care any longer about what exactly is happening or how it is called as long as I can make it work. Or if anybody recommends other modes then streaming only I am all open)

In other words, you need to disable archive_command, at least for what I see in your desidered configuration.

when I disable the archive_command I get

archive_command: FAILED (please set it accordingly to documentation)

upon barman check (which does not come unexpected to be honest). Same (FAILED on barman check) goes for archive_mode = off

As an alternative you could indeed add `archiver = on` and use both the streaming archiver and the non-streaming archiver.

that actually seems to work with the archive_commmand mentioned above. I am not understanding the different though.
Is there anything that would be recommended?

The idea is this: with both streaming and archiving barman will ask the WALs to PostgreSQL (streaming) and PostgreSQL will send
autonomously WALs to the barman machine (archiving). Therefore, barman (as a whole) will always have the WALs in a way or the other.

So again ... my goal was to got the streaming only path, but I seem unable to find that.

Don't get me wrong I totally appreciate all comments and support I am getting here, but I am under the impression that I  may be unfit to maneuver barman successfully.

My problem is that I am writing a paper for my exam on a comparison barman/pgBackRest and and struggling really hard an the barman side. I admin not to be super experienced with postgres (which is my personal weakness) and may have chosen the wrong topic for such a paper due to that. But there is not way back now any longer and I need to get something going, so I can at least take Barman into the comparison (beyond stating that I could not make Barman work).

[Luca Ferrari]

On Tue, Mar 8, 2022 at 11:51 AM dulhaver via Barman, Backup and
Recovery Manager for PostgreSQL <pgba...@googlegroups.com> wrote:
> I guess this may be what the manual calls streaming-only which "does not require any SSH connection for backup and archiving operations. This is particularly suitable and extremely practical for Docker environments." I seem not being able to extract the right breadcrumbs applying for such a scenario from the manual to get this going. Definitely nothing works without ssh in the state I am in right now.

Streaming happens on a request basis: barman (via barman cron, that in
turns starts a pg_walreceiver) asks for wals to PostgreSQL.
On the other hand, archiving happens on a push basis: PostgreSQL
pushes wals thru the archive_command.
You need archive_mode = off (in PostgreSQL), or archive_command =
/bin/true (in PostgreSQL) and archiver = off in barman.

> On the other hand I am at a point where I do not care any longer about what exactly is happening or how it is called as long as I can make it work. Or if anybody recommends other modes then streaming only I am all open)

Backup is the easy part, recovery is the hardest one. If you don't
know what you are doing, you probably will not be able to recover.

> archive_command: FAILED (please set it accordingly to documentation)

I suspect because you have archiver = on in barman.

> that actually seems to work with the archive_commmand mentioned above. I am not understanding the different though.
> Is there anything that would be recommended?

Yes, read again this thread, we explained it quite clearly.

>
> So again ... my goal was to got the streaming only path, but I seem unable to find that.

Starting from scratch with barman configuration could help.

> My problem is that I am writing a paper for my exam on a comparison barman/pgBackRest and and struggling really hard an the barman side. I admin not to be super experienced with postgres (which is my personal weakness) and may have chosen the wrong topic for such a paper due to that. But there is not way back now any longer and I need to get something going, so I can at least take Barman into the comparison (beyond stating that I could not make Barman work).

In my experience, barman has been simpler to configure than
pgbackrest. Also, as you probably already discovered, pgbackrest
requires ssh to work properly always.

Luca