Barman и pgBackRest оба бэкапят PostgreSQL, но по-разному устроены внутри. Исторически Barman строился вокруг rsync поверх SSH: backup_method = rsync копирует файлы кластера по ssh-соединению, а archiver = on принимает WAL-сегменты через archive_command, которая переносит их на сервер бэкапов. Со стороны PostgreSQL это полностью агентless-модель — отдельный процесс не нужен, достаточно ssh-доступа.
Более новый вариант — backup_method = postgres вместе со streaming_archiver = on: Barman получает WAL напрямую по протоколу репликации, тем же способом, каким это делает pg_receivewal, не дожидаясь ротации сегмента и срабатывания archive_command. На практике разница ощутима — сегмент попадает в репозиторий бэкапов почти сразу после коммита, и для передачи WAL уже не нужен SSH, достаточно обычного подключения к PostgreSQL.
Retention настраивается одной строкой — либо по числу бэкапов, либо по окну восстановления:
; хранить 2 последних full-бэкапа, остальные удалять
retention_policy = REDUNDANCY 2
; либо хранить всё необходимое для восстановления на любую точку за последние 14 дней
retention_policy = RECOVERY WINDOW OF 14 DAYS
При RECOVERY WINDOW Barman сам досчитывает, какие WAL-сегменты всё ещё нужны для PITR внутри окна, и не удаляет их, даже если формально они старше самого окна, — иначе восстановление на границе окна оказалось бы невозможным.
В отличие от pgBackRest, который всегда работает через собственный протокол и умеет сам параллелить передачу и сжатие по воркерам, Barman в rsync-режиме остаётся завязан на пропускную способность одного ssh-канала. Зато это самый простой способ поднять бэкап там, где на сервере PostgreSQL нежелательно держать выделенный процесс.
#postgresql #backup