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

Основная
KorP0

В 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-кластера
В задание добавляем все виртуальные машины 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
Без 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.

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

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

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

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

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

Результат image-level резервного копирования

Как 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 для каждой реплики.

WAL backup выполняется только для текущего primary-узла

Проверка переключения 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Проверка переключения primary

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

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

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

Восстановление через Veeam Explorer for 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, а также регулярно выполнять тестовое восстановление.

Добавить комментарий

Связанные записи

Veeam Backup & Replication V12 изучаем новый функционал

KorP

Новый выпуск подкаста «Техничка» уже здесь

KorP

Вебинары второго квартала

KorP