Резервное копирование и восстановление PostgreSQL и Tantor

Модуль PostgreSQL Universal предназначен для резервного копирования и восстановления СУБД PostgreSQL, Tantor Special Edition и Jatoba.

Таблица 1. Поддерживаемые версии СУБД

PostgreSQL

11, 12, 13, 14, 15, 16, 17

Tantor Special Edition

15, 1С 15, 16

Jatoba

6
Таблица 2. Поддерживаемые типы резервного копирования

Полное резервное копирование

—

Резервное копирование архивных журналов транзакций (WAL)

Модуль PostgreSQL Universal поддерживает безопасное хранение аутентификационной информации для подключения к СУБД с помощью внешнего хранилища секретов HashiCorp Vault.

Таблица 3. Хранилища секретов
Хранилище секретов Операционные системы

HashiCorp Vault 1.16.3

Astra Linux 1.7

Ubuntu 20.04

RHEL 8

Возможно выбрать один из подмодулей PostgreSQL Universal при настройке правил и стратегий резервного копирования:

Таблица 4. Подмодули

postgresql

Использует низкоуровневый API СУБД для выполнения резервного копирования

pg_probackup

Использует утилиту pg_probackup для выполнения резервного копирования СУБД

superb

Резервное копирование и восстановление СУБД в режиме непрерывного резервного копирования и резервного копирования архивных журналов транзакций

Модуль обеспечивает поддержку дедупликации данных в ходе резервного копирования.

Принцип резервного копирования состоит в периодическом создании полных резервных копий экземпляра СУБД и резервном копировании архивных журналов транзакций по заданному расписанию.

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

При выполнении резервного копирования данных для подмодулей postgresql и superb будут созданы резервные копии:

  • файлов данных СУБД, расположенных в директории, которая определяется автоматически или задается параметром data_directory в файле postgresql.conf (Подготовка СУБД PostgreSQL);

  • архивных журналов транзакций (WAL-файлов), расположенных в директории, которая определяется параметром archive_catalog в файле /opt/rubackup/etc/rb_module_postgresql.conf (Подготовка СУБД PostgreSQL);

  • файлов настроек СУБД, независимо от их расположения:

    • postgresql.conf. Если в конфигурационный файл postgresql.conf включены другие конфигурационные файлы (с помощью директив include, include_if_exists, include_dir), то будет создана резервная копия этих файлов;

    • pg_hba.conf;

    • pg_ident.conf.

После успешного резервного копирования WAL-файлы могут быть автоматически удалены клиентом RuBackup из каталога с архивными WAL-файлами (параметр archive_catalog в конфигурационном файле модуля), если включен параметр auto_remove_wal в конфигурационном файле модуля.

1. Ограничения

Запустить одновременно две операции резервного копирования или восстановления для модуля PostgreSQL Universal на одном хосте невозможно. Выполнение резервного копирования СУБД производится методом, не предусматривающим параллельных задач резервного копирования и восстановления для одной и той же СУБД. Если параллельная задача будет запущена, она завершится с ошибкой.

Восстановление на определенный момент времени (point-in-time recovery (PITR)) для подмодуля pg_probackup невозможно.

Во время выполнения задачи на создание инкрементальной резервной копии в RuBackup производится анализ WAL-файлов. Если анализ показывает, что в текущем WAL-файле изменилась линия времени по сравнению с последним WAL-файлом из предыдущей итерации создания резервной копии, то вместо инкрементальной копии создается полная резервная копия. Это актуально для подмодулей postgresql и superb.

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

Рекомендуем отключить возможность централизованного восстановления СУБД на клиенте и выполнять восстановление из резервной копии только со стороны клиента под контролем администратора СУБД.

Централизованное восстановление и восстановление с развертыванием рекомендуем предварительно выполнять на резервном хосте (виртуальной машине) для проверки корректности восстановления СУБД.

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

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

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