Настройка правил резервного копирования СУБД PostgreSQL

Чтобы выполнять регулярное резервное копирование СУБД PostgreSQL, необходимо создать правило в глобальном расписании (в случае групповых операций можно так же использовать стратегии резервного копирования).

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

Для создания правила в глобальном расписании выполните следующие действия:

  1. Находясь в разделе «Глобальное расписание», нажмите на кнопку «Добавить», чтобы добавить правило глобального расписания (Рисунок 1).

    11
    Рисунок 1. Глобальное расписание

  2. Выберите клиент и тип ресурса «PostgreSQL Universal» (Рисунок 2).

    12
    Рисунок 2. Выбор клиента и типа ресурса

  3. Нажмите на иконку «…​» рядом с надписью «Тип ресурса», чтобы выбрать следующие параметры (Рисунок 3):

    13
    Рисунок 3. Выбор типа ресурса

    • connection_monitoring — мониторинг соединения с базой данных (параметр используется только для подмодуля postgresql);

    • engine — выбор подмодуля для резервного копирования (postgresql, pg_probackup, superb):

      • postgresql — подмодуль, использующий низкоуровневый API СУБД PostgreSQL для выполнения резервного копирования;

      • pg_probackup — подмодуль, использующий утилиту pg_probackup для выполнения резервного копирования СУБД Postgres Pro;

      • superb — подмодуль, использующий снапшоты для выполнения резервного копирования СУБД PostgreSQL.

    • incremental_subtype — выбор подтипа инкрементального резервного копирования (параметр используется только для подмодуля postgresql):

      • archive_wal — режим инкрементального резервного копирования, при котором модуль PostgreSQL Universal выполняет резервное копирование архивных WAL-файлов;

      • page (страничное копирование) — режим инкрементального копирования, при котором Модуль PostgreSQL Universal сканирует все файлы WAL в архиве с момента создания предыдущей полной или инкрементальной копии. Новая резервная копия будет содержать только страницы, упомянутые в записях WAL;

        Для работы подтипа page необходимо настроить параметр конфигурационного файла pg_waldump (подробнее см. в разделе «Конфигурационный файл»).

      • delta (разностное копирование) — режим инкрементального копирования, при котором Модуль PostgreSQL Universal считывает все файлы данных в каталоге данных и копирует только те страницы, которые изменились со времени предыдущего копирования;

      • ptrack (копирование изменений) — режим инкрементального копирования, при котором Модуль PostgreSQL Universal использует функционал отслеживания изменения страниц на лету. При каждом изменении страницы отношения она помечается в специальной карте PTRACK.

    • snapshot_type. Выбор типа снимка (параметр используется только для подмодуля superb):

      • lvm — использование снапшотов LVM;

        СУБД PostgreSQL должна располагаться в файловой системе, которая использует том LVM.

        Модуль поддерживает СУБД PostgreSQL с дополнительными табличными пространствами (tablespaces). Табличные пространства так же должны располагаться в файловых системах, которые используют тома LVM.

      • dattobd — использование модуля ядра dattobd, позволяющего делать снимки блочного устройства;

      • tatlin – использование Tatlin Unified Storage, позволяющего делать мгновенные снимки состояния данных СУБД PostgreSQL, которая располагается в системе хранения данных Tatlin Unified Storage.

        Перед выполнением резервного копирования создаётся мгновенный снимок состояния (в зависимости от способа мгновенного снимка состояния: логического тома LVM, данных на блочном устройстве, системы хранения данных Tatlin Unified Storage), по окончанию резервного копирования мгновенный снимок состояния будет удалён.

        При использовании Tatlin Unified Storage необходимо предварительно на хосте, на котором развёрнут модуль резервного копирования и восстановления данных файловых систем, установить утилиты multipath и sg3_utils.

    • snapshot_size — выбор размера снимка в процентах от размера Logical Volume тома, на котором расположены файлы базы данных, для которой выполняется резервное копирование, в случае LVM. Либо размер снимка в процентах от размера устройства, на котором расположены файлы базы данных, для которой выполняется резервное копирование, в случае использования dattobd. Параметр используется только для подмодуля superb.

      В LVM volume groups, в которых расположены тома LVM, должно быть не менее 10% свободного места для возможности создания моментальных снимков LVM.

      В ходе выполнения задания резервного копирования в журнальном файле задания резервного копирования (файл с номером задачи в /opt/rubackup/log) можно проконтролировать реальную утилизацию созданного снэпшота:

      07
      Рисунок 4. Утилизация созданного снэпшота

      В том случае, если это значение при реальном резервном копировании близко к 100%, то необходимо увеличить размер свободного места в LVM группе и увеличить lvm_snapshot_size.

    • entire_snapshot_backup — при выставлении этого параметра будет выполняться резервное копирование всего снэпшота диска (логического тома lvm), на котором располагается СУБД PostgreSQL. Если параметр не выставлен, то будет выполняться резервное копирование только данных СУБД PostgreSQL. Параметр используется только для подмодуля superb.

    • pg_pro_threads — выбор количества параллельных потоков при резервном копировании. Параметр используется только для подмодуля pg_probackup;

    • pg_pro_backup_mode — выбор подтипа инкрементального резервного копирования. Параметр используется только для подмодуля pg_probackup;

    • pg_pro_stream — выбор режима доставки WAL. При включенном переключателе — режим STREAM. Копии типа STREAM включают все сегменты WAL, необходимые для восстановления согласованного состояния кластера на момент создания копии. При выключенном переключателе действует режим ARCHIVE — в таком режиме целостность копий обеспечивается посредством непрерывного архивирования (подробнее см. на https://postgrespro.ru/docs/enterprise/). Параметр используется только для подмодуля pg_probackup;

    • secret_method — выбор метода получения аутентификационных данных (секрета) для подключения к резервируемой базе данных. Для выбора метода необходимо предварительно его добавить в соответствии с описанием в пункте "Добавление метода получения секрета". Выбор предоставляется в соответствии с назначенными правами доступа авторизованного пользователя СРК RuBackup. Возможные значения: «No secret method» — учётные данные пользователя для подключения к резервируемой базе данных будут считаны из конфигурационного файла /opt/rubackup/etc/rb_module_postgresql.conf; «Название метода» — метод, который предварительно добавлен и права на который назначены пользователю, учётные данные пользователя для подключения к резервируемой базе данных будут запрошены в хранилище секретов HashiCorp Vault.

  4. Выберите ресурс, нажав на иконку «…​» рядом с надписью «Ресурс» (Рисунок 5).

    14
    Рисунок 5. Выбор ресурса

    В окне выбора всегда будет предложен только один вариант: PostgreSQL с номером версии. Модуль rb_module_postgresql будет пытаться подключиться к прописанной в файле настроек /opt/rubackup/etc/rb_module_postgresql.conf базе данных по выбранному методу получения аутентификационной информации (секрета): из файла настроек модуля или хранилища секретов HashiCorp Vault.

    Если на хосте, который не является лидером, в поле «Ресурс» отсутствуют необходимые ресурсы, то выберите клиент, который является лидером.

  5. Установите настройки правила: название правила, тип резервного копирования (full — для базового резервного копирования, incremental — для резервного копирования архивных WAL), ёмкость хранилища и ёмкость хранилища клиента (в ГБ), приоритет, алгоритм защитного преобразования, скрипт при нормальном выполнении и при выполнении с ошибками, скрипт при восстановлении резервной копии (Рисунок 6).

    15
    Рисунок 6. Настройки правила

    Сделать инкрементальную резервную копию одного ресурса в разные пулы при включенном параметре auto_remove_wal невозможно. Чтобы создать инкрементальную резервную копию одного ресурса в разных пулах, установите в конфигурационном файле /opt/rubackup/etc/rb_module_postgresql.conf параметр auto_remove_wal в значении no. По умолчанию этот параметр имеет значение yes.

    Опционально, при использовании хранилища секретов: при создании инкрементальной резервной копии ресурса следует учитывать метод получения секрета при выполнении предыдущих резервных копий выбранного ресурса. Созданные РК будут находится в одном репозитории при условии использования одного и того же метода получения секрета для подключения к резервируемому ресурсу. В случае выполнения инкрементальной РК ресурса с отличным методом получения секрета, который был использован для получения предыдущей РК, будет выполнено полное резервное копирование ресурса и созданная РК будет помещена в другой репозиторий.

  6. После выбора настроек правила глобального расписания нажмите на кнопку «Добавить правило в шаблон», если хотите создать сразу несколько правил — правило для выбранного типа ресурса и выбранного ресурса появится в списке правил под кнопкой (Рисунок 7). Таким образом создайте столько правил, сколько требуется. Для создания одного правила нажимать на кнопку не нужно.

    16
    Рисунок 7. Добавление правила в шаблон

  7. Заполните раздел «Шаблон глобального расписания» (подробнее см. в документе «Руководство системного администратора RuBackup»).

  8. Если необходимо создать правило, которое пока не должно порождать задач резервного копирования, нужно убрать отметку «Включить после создания».

  9. Правила глобального расписания имеют срок жизни, определяемый при их создании, а также предоставляют следующие возможности:

    • выполнить скрипт на клиенте перед началом резервного копирования;

    • выполнить скрипт на клиенте после успешного окончания резервного копирования;

    • выполнить скрипт на клиенте после неудачного завершения резервного копирования;

    • выполнить защитное преобразование резервной копии на клиенте;

    • периодически выполнять проверку целостности резервной копии;

    • хранить резервные копии определенный срок, по окончании которого удалять их из хранилища резервных копий и из записей репозитория, либо уведомлять клиента об окончании срока хранения;

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

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

  10. Нажмите на кнопку «Применить» в правом-верхнем углу для завершения настройки и создания правила/правил.

Вновь созданное правило будет иметь статус run. При необходимости, администратор может приостановить работу правила или немедленно запустить его (т.е. инициировать немедленное создание задачи при статусе правила wait).

При создании задачи RuBackup она появляется во вкладке «Очередь задач». Отслеживать выполнение правил может как администратор (при помощи RBM или утилит командной строки), так и клиент (при помощи утилиты командной строки rb_tasks).

После успешного завершения резервного копирования резервная копия будет помещена в хранилище резервных копий, а информация о ней будет размещена в репозитории RuBackup.

1. Срочное резервное копирование при помощи RBM

Для выполнения срочного резервного копирования любого источника данных на клиенте необходимо в RBM во вкладке «Объекты» выбрать нужный клиент СРК и нажать кнопку «Срочное РК» (Рисунок 8):

17
Рисунок 8. Выполнение срочного резервного копирования

Появится окно, в котором можно будет выбрать нужный источник данных для выполнения срочного резервного копирования (Рисунок 9):

18
Рисунок 9. Источник данных для выполнения срочного резервного копирования

После выбора настроек нажать кнопку «Применить» в правом верхнем углу (Рисунок 10):

19
Рисунок 10. Кнопка "Применить"

Проверить ход выполнения резервного копирования можно в окне «Очередь задач» (Рисунок 11):

20
Рисунок 11. Очередь задач

При успешном завершении резервного копирования задача переходит в статус «Done».