Расскажите про barman, пожалуйста

но никак не могу понять разницу между сценарием 1 и сценарием 1b на их сайте.

Streaming-only backup (Scenario 1)

vs

Streaming backup with WAL archiving (Scenario 1b)

Не понимаю что не понятно.

То есть грубо говоря чтобы в «начале» дня делался полный бэкап, а затем просто сохранялись wal, но у них на сайте как то крайне непонятно все написано.

backup
The backup command takes a full backup (base backup) of a given server. It has several options that let you override the corresponding configuration parameter for the new backup. For more information, consult the manual page.

You can perform a full backup for a given server with:

barman backup <server_name>
TIP: You can use barman backup all to sequentially backup all your configured servers.

Да вроде всё понятно.

Спасибо кэп.

Но в чем разница на практике то?

Да вроде всё понятно.

Применительно для моей задачи, правильно ли я понимаю следующие тезисы:

1. Каждый день в 00:00 мне надо делать

barman backup my_server

2. Что делать в дальнейшем? То есть как получать необходимые мы WAL до 23:59, момент когда я снова вернусь на шаг 1?

Извиняюсь за сумбурность, просто я вообще не въезжаю, что бывает крайне редко.

Streaming-only backup (Scenario 1)

vs

Streaming backup with WAL archiving (Scenario 1b)

По моему это все равно что на сайте заказа такси написать:

- Вызов такси: 100р.

- Вызов такси с шофером: 120р.

Я не прикалываюсь вот сейчас, а реально пытаюсь понять разницу уже неделю почти.

В сценарии 1 все коммуникации проходят по стриминговому протоколу постгреса (как снятие базового бэкапа, так и архивация WAL - barman просто прикидывается репликой и получает все журналы).

В сценарии 1b дополнительно постгрес сам (через archive_command) архивирует WAL. До того, как в постгресе появились replication slots (а в barman их поддержка), archive_command был единственным способом гарантировать архивацию всех журналов даже в случае пропадания коннекта между базой и barman.

Если есть возможность использовать replication slot (postgres >= 9.4, barman >= 2.0), то сценарий 1 ничем не хуже сценария 1b. Если нет, то, соответственно, надо дополнительно настроить archive_command и получить 1b.

В сценарии 1 все коммуникации проходят по стриминговому протоколу постгреса...

Вот спасибо, теперь все понятно. Удивляюсь, почему разработчики бармана не включили такое простое объяснение в доки.

Удивляюсь, почему разработчики бармана не включили такое простое объяснение в доки.

Это знают все, кто администрирует постгрес. В доках инструмента для бэкапа это описывать излишне.

Это знают все, кто администрирует постгрес. В доках инструмента для бэкапа это описывать излишне.

Ну понятно... Но инструмен то вроде не новый, могли бы за столько лет уже такие как я дописать где нибудь, хотя я, скорее всего, тоже ничего не напишу.

Ну понятно... Но инструмен то вроде не новый, могли бы за столько лет уже такие как я дописать где нибудь, хотя я, скорее всего, тоже ничего не напишу.

Описание стримингового протокола репликации постгреса в документации инструмента для бэкапа, который опционально может использовать этот протокол - излишне.

Ты же не ожидаешь в документации например по nginx'у описание протокола http?

Ты же не ожидаешь в документации например по nginx'у описание протокола http?

Видимо да, слишком я еще зелен в вопросах баз данных.

А можно ли еще вопрос?

Вот насколько я понимаю barman он бэкапит каждую транзакцию. А каким образом я могу увидеть список этих транзакций чтобы «отмотать» на нужную?

Ведь в этом же и заключается point in time recovery, я правильно понимаю?

А каким образом я могу увидеть список этих транзакций чтобы «отмотать» на нужную?

А вот это как раз должно быть в документации по постгресу описано. Помню, что была даже возможность взять и пропустить одну транзакцию из лога (например drop database какой-нибудь), но мои знания про это уже устарели и даже подпротухли.
Думаю, надо смотреть куда-то сюда: https://www.postgresql.org/docs/11/continuous-archiving.html

Думаю, надо смотреть куда-то сюда:

Спасибо большое.