It's absolutely clear now. Many thanks.
After some playing with Barman's backups and recoveries, I get the following errors related to the new 'backup' command:
ERROR: Impossible to start the backup. Check the log for more details, or run 'barman check gl'
In barman.log file:
2022-02-02 12:26:01,703  barman.wal_archiver INFO: Found 1 xlog segments from streaming for gl. Archive all segments in one run.
2022-02-02 12:26:01,703  barman.wal_archiver INFO: Archiving segment 1 of 1 from streaming: gl/00000003.history
2022-02-02 12:26:01,707  barman.server INFO: Starting receive-wal for server gl
2022-02-02 12:26:01,824  barman.wal_archiver INFO: Activating WAL archiving through streaming protocol
2022-02-02 12:26:01,897  barman.command_wrappers INFO: gl: pg_receivewal: starting log streaming at 0/19000000 (timeline 3)
2022-02-02 12:26:01,910  barman.command_wrappers INFO: gl: pg_receivewal: error: could not send replication command "START_REPLICATION": ERROR: requested timeline 3 is not in this >2022-02-02 12:26:01,911  barman.command_wrappers INFO: gl: pg_receivewal: error: disconnected
2022-02-02 12:26:01,913  barman.server ERROR: ArchiverFailure:pg_receivewal terminated with error code: 1
2022-02-02 12:26:17,435  barman.server ERROR: Check 'replication slot' failed for server 'gl'
2022-02-02 12:26:17,442  barman.server ERROR: Check 'receive-wal running' failed for server 'gl'
2022-02-02 12:26:17,444  barman.server ERROR: Impossible to start the backup. Check the log for more details, or run 'barman check gl'
$ Barman's 'check' command:
superuser or standard user with backup privileges: OK
PostgreSQL streaming: OK
replication slot: FAILED (slot 'barman' not initialised: is 'receive-wal' running?)
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
backup minimum size: OK (137.4 MiB)
wal maximum age: OK (no last_wal_maximum_age provided)
wal size: OK (48.0 MiB)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 4 backups, expected at least 3)
pg_basebackup compatible: OK
pg_basebackup supports tablespaces mapping: OK
systemid coherence: OK
pg_receivexlog compatible: OK
receive-wal running: FAILED (See the Barman log file for more details)
archiver errors: OK
$ Barman's 'status' command:
Description: gl Database (Streaming-Only)
PostgreSQL version: 14.1
Cluster state: in production
pgespresso extension: Not available
Current data size: 164.4 MiB
PostgreSQL Data directory: /var/lib/postgresql/data
Current WAL segment: 00000002000000000000001A
Passive node: False
Retention policies: enforced (mode: auto, retention: RECOVERY WINDOW OF 4 WEEKS, WAL retention: MAIN)
No. of available backups: 4
First available backup: 20220131T195320
Last available backup: 20220201T142738
Minimum redundancy requirements: satisfied (4/3)
$ Barman's 'receive-wal' command:
gl: pg_receivewal: starting log streaming at 0/19000000 (timeline 3)
gl: pg_receivewal: error: could not send replication command "START_REPLICATION": ERROR: requested timeline 3 is not in this server's history
gl: pg_receivewal: error: disconnected
ERROR: ArchiverFailure:pg_receivewal terminated with error code: 1
$ Barman's 'receive-wal --create-slot':
ERROR: Replication slot 'barman' already exists
$ Barman's 'receive-wal --reset':
ERROR: The receive-wal position is ahead of PostgreSQL current WAL lsn (000000030000000000000019.partial > 00000002000000000000001B)
It looks like the database is on Timeline 2 after the recovery, but Barman's state is already pointing to Timeline 3.
Please explain how I should act in such situations. I'm trying to figure it out now because when the database is filled with real data, I won't have the opportunity and time to experiments.
And one more question that worries me a lot. Let's say I want the Barman to completely reset his state. Is it enough to just delete the server directory in the Barman directory or does it store the related data somewhere else? Will there be any problem later?