Veeam Backup & Replication 13.1: Резервное копирование кластера Patroni

В Veeam Backup & Replication 13.1 появилась поддержка резервного копирования кластеров PostgreSQL под управлением Patroni. Veeam определяет текущий primary-узел, создаёт image-level резервные копии виртуальных машин и сохраняет WAL, необходимые для восстановления на выбранный момент времени.

Главное преимущество новой реализации — на узлах не требуется заранее устанавливать и постоянно обслуживать Veeam Agent. Обработка PostgreSQL выполняется при помощи application-aware processing в обычном задании резервного копирования виртуальных машин.

Зачем нужна поддержка Patroni?

В Veeam 13.1 задание получает информацию о топологии Patroni-кластера, определяет текущий primary и выполняет WAL backup только для него. Реплики распознаются как участники того же кластера и пропускаются при обработке WAL.

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

• все виртуальные машины Patroni можно включить в одно задание;
• смена primary не требует ручного редактирования задания;
• WAL сохраняются вместе с основной цепочкой резервных копий;
• становится доступно восстановление PostgreSQL на выбранный момент времени;
• управление выполняется из стандартной консоли Veeam Backup & Replication.

Архитектура тестового стенда

Компонент	Параметры стенда
Veeam Backup & Replication	13.1
PostgreSQL	17
Patroni	4.0.7
etcd	3.5.16
Узлы	pg-patroni-01 pg-patroni-02 pg-patroni-03
Гостевая ОС	Debian 13
Гипервизор	VMware ESXi 8

Требования и ограничения

Перед настройкой задания необходимо проверить требования Veeam к PostgreSQL:

• PostgreSQL работает на Linux;
• включён archive_mode=on;
• archive_command и archive_library не содержат пользовательских значений;
• wal_level установлен в replica или logical;
• временный каталог доступен из гостевой ОС и имеет достаточно свободного места;
• каталог /tmp смонтирован с параметром exec;
• у Veeam есть учётная запись PostgreSQL с необходимыми полномочиями;
• application-aware processing включён для всех виртуальных машин кластера.

Следует также учитывать границы решения:

• резервная копия PostgreSQL не заменяет резервное копирование конфигурации Patroni;
• состояние etcd/DCS необходимо учитывать в общем плане аварийного восстановления;
• если основная image-level копия не создана, связанная с ней новая цепочка WAL restore points также не формируется.

Подготовка Patroni и PostgreSQL

Параметры PostgreSQL лучше изменять централизованно через конфигурацию Patroni, чтобы они применялись ко всем участникам кластера, включая узел, который может стать новым primary.

Проверяем текущие значения:

SHOW archive_mode;
SHOW archive_command;
SHOW archive_library;
SHOW wal_level;

Ожидаемая конфигурация:

archive_mode = on
archive_command = ''
archive_library = ''
wal_level = replica

Фрагмент конфигурации Patroni:

postgresql:
  parameters:
    archive_mode: "on"
    archive_command: ""
    archive_library: ""
    wal_level: "replica"

Как работает архивирование WAL

WAL — журнал изменений PostgreSQL. Сначала изменения фиксируются в WAL, а затем применяются к файлам данных. Эти же записи используются потоковой репликацией PostgreSQL, которой управляет Patroni.

Транзакция записывается в WAL
        ↓
WAL-сегмент заполняется
        ↓
PostgreSQL закрывает сегмент
        ↓
Сегмент передаётся механизму архивирования
        ↓
После успешного архивирования сегмент можно переиспользовать

При включённом archive_mode и пустых archive_command и archive_library PostgreSQL не отправляет WAL во внешний архив самостоятельно. Во время WAL backup Veeam устанавливает и контролирует собственный механизм доставки WAL во временный каталог, указанный в настройках задания.

В тестовом стенде использовался каталог: /var/lib/postgresql/veeam-wal

Каталог должен быть доступен учётной записи обработки, иметь достаточно свободного места и контролироваться системой мониторинга. При проблемах с архивированием WAL могут начать накапливаться в pg_wal.

Создание задания резервного копирования

Создаём обычное задание резервного копирования виртуальных машин.

В задание добавляем все виртуальные машины Patroni кластера: pg-patroni-01, pg-patroni-02 и pg-patroni-03.

Важно. Добавлять нужно все узлы, а не только текущий primary. Иначе после switchover новый primary может оказаться вне области действия задания.

Включение application-aware processing

На этапе Guest Processing включаем Enable application-aware processing, указываем учётные данные гостевой ОС и проверяем сетевую доступность виртуальных машин.

Без application-aware processing Veeam создаст только crash-consistent копию виртуальной машины. Такая копия не обеспечивает полноценную обработку PostgreSQL и не позволяет использовать все возможности Veeam Explorer for PostgreSQL.

Настройка PostgreSQL и WAL backup

В параметрах обработки приложения выбираем учётную запись PostgreSQL. В протестированной конфигурации использовалась учётная запись с атрибутом SUPERUSER.

Затем включаем периодическое резервное копирование WAL. В тестовом стенде использовались следующие параметры:

• интервал WAL backup — 15 минут;
• хранение WAL — до удаления соответствующей image-level копии;
• временный каталог — /var/lib/postgresql/veeam-wal;
• log shipping server — Automatic selection.

Для производственной среды стоит рассмотреть как минимум два log shipping server. Это повысит доступность обработки WAL и позволит распределить нагрузку.

RPO. Интервал 15 минут — это период обработки, а не безусловная гарантия потери не более 15 минут данных. Фактический RPO зависит от закрытия WAL-сегментов, доступности log shipping server и отсутствия разрывов цепочки.

Выполнение image-level backup

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

Как Veeam определяет primary

Во время тестирования pg-patroni-02 был primary-узлом. Veeam сохранял WAL только с него, а остальные экземпляры распознал как реплики:

Succeeded: Skipping non-primary database in cluster: pg-patroni-01:5432
Succeeded: Skipping non-primary database in cluster: pg-patroni-03:5432

Это подтверждает, что Veeam видит участников Patroni-кластера и не пытается создавать независимые цепочки WAL для каждой реплики.

Проверка переключения primary

До переключения:

pg-patroni-01 — Replica

pg-patroni-02 — Leader

pg-patroni-03 — Replica

После:

pg-patroni-01 — Leader

pg-patroni-02 — Replica

pg-patroni-03 — Replica

В тесте после смены primary узла, Veeam автоматически определил новую роль узлов и продолжил обработку WAL без изменения задания. Так же не стоит обращать внимание на то, к какому серверу в данном случае «привязаны» WAL, это никак не мешает PIRT базы, с какого бы сервера вы её не восстанавливали.

Восстановление через Veeam Explorer for PostgreSQL

Созданные резервные копии можно открыть в Veeam Explorer for PostgreSQL. Explorer отображает обнаруженный экземпляр PostgreSQL и его базы данных. В зависимости от сценария можно восстановить экземпляр или базу, а также выполнить восстановление на альтернативный сервер.

Риск. Не восстанавливайте экземпляр поверх действующего участника Patroni без отдельного плана. Необходимо учитывать состояние DCS, роли узлов, timeline PostgreSQL и повторное присоединение восстановленного экземпляра.

Для проверки копии безопаснее использовать изолированную тестовую сеть, альтернативный PostgreSQL-сервер или отдельный экземпляр без подключения к рабочему DCS.

Восстановление на выбранный момент времени

При наличии основной image-level копии и непрерывной цепочки WAL Veeam позволяет произвести восстановление данных на конкретный момент времени — Point-in-Time Recovery.

Восстановление

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

Как мы видим – база восстановлена, и PIRT работает

Типичные ошибки

Настроить только текущий primary. После switchover новый ведущий узел может оказаться вне области задания. Добавляйте все узлы Patroni.

Проверить только archive_mode. Контролируйте также archive_command, archive_library, wal_level и pg_stat_archiver.

Оставить собственный archive_command. Пользовательская команда может конфликтовать с механизмом Veeam.

Не контролировать свободное место. WAL могут накапливаться в pg_wal или временном каталоге и заполнить файловую систему.

Считать интервал гарантированным RPO. Интервал задания не заменяет проверку непрерывности WAL и тестовое восстановление.

Проверить только наличие restore point. Успешный статус задания не доказывает, что данные действительно восстанавливаются.

Считать backup PostgreSQL копией всего Patroni. Отдельно защищайте конфигурацию Patroni, DCS, сертификаты и сетевую конфигурацию.

Что нужно запомнить

• В Veeam 13.1 появилась поддержка определения ролей Patroni-кластера.
• В задание необходимо добавлять все виртуальные машины Patroni.
• Image-level backup выполняется для всех узлов, а WAL сохраняются только с текущего primary.
• На узлах не требуется постоянно установленный Veeam Agent.
• Для WAL backup необходимы archive_mode=on и корректный wal_level.
• Временный каталог и pg_wal необходимо контролировать по свободному месту.
• После switchover нужно проверить, что WAL backup перешёл на новый primary.
• Наличие WAL restore points позволяет выполнять PITR, но восстановление нужно регулярно тестировать.
• Резервная копия PostgreSQL не заменяет план восстановления Patroni и etcd/DCS.

Итог

Поддержка Patroni в Veeam Backup & Replication 13.1 заметно упрощает защиту кластеров PostgreSQL в виртуальной среде. Администратору не нужно создавать отдельные задания для каждой возможной роли или вручную менять источник WAL после switchover: Veeam определяет текущий primary и продолжает работу в рамках одного задания.

При этом автоматическое определение топологии не отменяет обычных требований к резервному копированию. Необходимо контролировать цепочку WAL, свободное место, учётные данные, retention и состояние log shipping server, а также регулярно выполнять тестовое восстановление.