В этом разделе

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

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

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

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

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

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

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

Нажмите на иконку «…» рядом с надписью «Тип ресурса». Откроется окно с дополнительными параметрами модуля (Таблица 1):

Таблица 1. Дополнительные параметры модуля
Наименование параметра	Описание параметра	Допустимые значения	Значение по умолчанию
`connection_monitoring`	Мониторинг соединения с базой данных (параметр используется только для подмодуля `postgresql`)	`true`, `false`	`true`
`engine`	Выбор подмодуля для резервного копирования	`postgresql` — подмодуль, использующий низкоуровневый API СУБД PostgreSQL для выполнения резервного копирования;	—
		`pg_probackup` — подмодуль, использующий утилиту `pg_probackup` для выполнения резервного копирования СУБД Postgres Pro;
		`superb` — подмодуль, использующий снэпшоты для выполнения резервного копирования СУБД PostgreSQL.
`incremental_subtype`	Выбор подтипа инкрементального резервного копирования (параметр используется только для подмодуля `postgresql`):	`archive_wal` — режим инкрементального резервного копирования, при котором модуль PostgreSQL Universal выполняет резервное копирование архивных WAL-файлов.	—
		`page` (страничное копирование). В режиме `page` Модуль PostgreSQL Universal сканирует все файлы WAL в архиве с момента создания предыдущей полной или инкрементальной копии. Новая резервная копия будет содержать только страницы, фигурирующие в записях WAL. При этом необходимо, чтобы в архиве WAL сохранялись все файлы WAL, записанные после предыдущей копии. Если размер этих файлов сравним с общим размером файлов базы данных, ускорение будет менее значительным, но размер копии будет всё же меньше. Для работы подтипа `page` необходимо настроить параметр конфигурационного файла `pg_waldump` (подробнее см. в разделе «Конфигурационный файл»).
		`delta` (разностное копирование). В режиме `delta` Модуль PostgreSQL Universal считывает все файлы данных в каталоге данных и копирует только те страницы, которые изменились со времени предыдущего копирования. Для использования данного режима не требуется производить непрерывное архивирование. В этом режиме объём ввода/вывода может равняться объёму при полном резервном копировании.
		`ptrack` (копирование изменений). В режиме `PTRACK` Модуль Postgres Pro отслеживает изменения страниц на лету. Чтобы он работал, не требуется производить непрерывное архивирование WAL. При каждом изменении страницы она помечается в специальной карте `PTRACK`. Это отслеживание привносит небольшие издержки в работу сервера, но значительно ускоряет инкрементальное резервное копирование.
`snapshot_type`	Выбор типа снимка (параметр используется только для подмодуля `superb`).	`lvm` — использование снэпшотов LVM; СУБД PostgreSQL должна располагаться в файловой системе, которая использует том LVM. Модуль поддерживает СУБД PostgreSQL с дополнительными табличными пространствами (tablespaces). Табличные пространства также должны располагаться в файловых системах, которые используют тома LVM.	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`) можно проконтролировать реальную утилизацию созданного снэпшота: `Snapshot '/dev/mapper/vg0-var--lib.snap' was used for: 0.92 % The snapshot was removed: /dev/mapper/vg0-var--lib.snap` В том случае, если это значение при реальном резервном копировании близко к 100%, то необходимо увеличить размер свободного места в LVM группе и увеличить `lvm_snapshot_size`.	—	10
`entire_snapshot_backup`	При активировании переключателя будет выполняться резервное копирование всего снимка состояния (снэпшота) диска (логического тома LVM), на котором располагается СУБД PostgreSQL. Если переключатель не активирован, то будет выполняться резервное копирование только данных СУБД PostgreSQL. Параметр используется только для подмодуля `superb`.	—	—
`pg_pro_threads`	Выбор количества параллельных потоков при резервном копировании. Параметр используется только для подмодуля `pg_probackup`.	—	—
`pg_pro_backup_mode`	Выбор подтипа инкрементального резервного копирования. Параметр используется только для подмодуля `pg_probackup`.	`DELTA` (разностное копирование). В режиме `DELTA` `pg_probackup` считывает все файлы данных в каталоге данных и копирует только те страницы, которые изменились со времени предыдущего копирования. Для использования данного режима не требуется производить непрерывное архивирование. В этом режиме объём ввода/вывода может равняться объёму при полном резервном копировании. `PAGE` (страничное копирование). В режиме `PAGE` `pg_probackup` сканирует все файлы WAL в архиве с момента создания предыдущей полной или инкрементальной копии. Новая резервная копия будет содержать только страницы, фигурирующие в записях WAL. При этом необходимо, чтобы в архиве WAL сохранялись все файлы WAL, записанные после предыдущей копии. Если размер этих файлов сравним с общим размером файлов базы данных, ускорение будет менее значительным, но размер копии будет всё же меньше. `PTRACK` (копирование изменений). В режиме `PTRACK` Postgres Pro отслеживает изменения страниц на лету. Чтобы он работал, не требуется производить непрерывное архивирование WAL. При каждом изменении страницы отношения она помечается в специальной карте PTRACK. Это отслеживание привносит небольшие издержки в работу сервера, но значительно ускоряет инкрементальное резервное копирование.	DELTA
`stream`	Выбор режима доставки WAL.	При активированном переключателе включается режим STREAM. Копии типа STREAM включают все сегменты WAL, необходимые для восстановления согласованного состояния кластера на момент создания копии. При выключенном переключателе действует режим ARCHIVE — в таком режиме целостность копий обеспечивается посредством непрерывного архивирования (подробнее см. на https://postgrespro.ru/docs/enterprise/). Параметр используется как для подмодуля `pg_probackup`, так и для `postgresql`. Чтобы использовать параметр `stream` с подмодулем `postgresql`, настройте в конфигурационном файле параметры `pg_receivewal` и `replication_catalog`.	—
`secret_method`	Выбор метода получения аутентификационных данных (секрета) для подключения к резервируемой базе данных. Для выбора метода необходимо предварительно добавить его в соответствии с описанием в пункте "Добавление метода получения секрета". Выбор предоставляется в соответствии с назначенными правами доступа авторизованного пользователя СРК RuBackup.	No secret method — учётные данные пользователя для подключения к резервируемой базе данных будут считаны из конфигурационного файла `/opt/rubackup/etc/rb_module_postgresql.conf`. «Название метода» — метод, который предварительно добавлен и права на который назначены пользователю; учётные данные пользователя для подключения к резервируемой базе данных будут запрошены в хранилище секретов HashiCorp Vault.	—

В правом верхнем углу окна с параметрами может появиться желтая иконка-предупреждение (Рисунок 3).

Рисунок 3. Предупреждение

При нажатии на иконку можно увидеть подробную информацию (Рисунок 4).

Рисунок 4. Подробная информация

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

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

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

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

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

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

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

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

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

Рисунок 7. Добавление правила в шаблон
Заполните раздел «Шаблон глобального расписания» (подробнее см. в документе «Руководство системного администратора RuBackup»).
Если необходимо создать правило, которое пока не должно порождать задач резервного копирования, нужно убрать отметку «Включить после создания».
Правила глобального расписания имеют срок жизни, определяемый при их создании, а также предоставляют следующие возможности:
- выполнить скрипт на клиенте перед началом резервного копирования;
- выполнить скрипт на клиенте после успешного окончания резервного копирования;
- выполнить скрипт на клиенте после неудачного завершения резервного копирования;
- выполнить защитное преобразование резервной копии на клиенте;
- периодически выполнять проверку целостности резервной копии;
- хранить резервные копии определенный срок, по окончании которого удалять их из хранилища резервных копий и из записей репозитория, либо уведомлять клиента об окончании срока хранения;
- через определенный срок после создания резервной копии автоматически переместить ее в другой пул хранения резервных копий, например, на картридж ленточной библиотеки;
- уведомлять пользователей системы резервного копирования о результатах выполнения тех или иных операций, связанных с правилом глобального расписания.
Нажмите на кнопку «Применить» в правом-верхнем углу для завершения настройки и создания правила/правил.

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

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

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

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

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

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

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

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

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

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

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

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

Если при выполнении задачи резервного копирования: * будет изменен размер какого-либо файла ресурса, то этот файл будет добавлен в РК и задача завершится успешно со статусом Done. * какой-либо файл ресурса будет удален, то при восстановлении будет восстановлена та часть этого файла, которая успела войти в РК, при этом задача на создание РК завершится успешно со статусом Done. * произойдет ошибка чтения какого-либо файла ресурса, то задача на резервное копирование завершится ошибкой и перейдет в статус Error (подробную информацию об ошибке см. в Журнале операций очереди задач).

После окончания обработки и резервного копирования файла его повторная проверка не происходит. Все изменения, произошедшие после завершения обработки файла, не попадут в РК.

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