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

1. Назначение

Резервное копирование и восстановление СУБД PostgreSQL, Postgres Pro, Tantor Special Edition и Jatoba выполняется с помощью модуля PostgreSQL Universal, входящего в состав СРК RuBackup.

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

PostgreSQL

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

Postgres Pro

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

Tantor Special Edition

15, 1С 15, 16, 17, 18

Jatoba

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

postgresql

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

pg_probackup

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

superb

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

2. Резервируемые данные

Осуществляется резервное копирование всей СУБД и архивных журналов транзакций (WAL).

При выполнении резервного копирования данных для подмодулей 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.

3. Типы резервного копирования

Модуль поддерживает следующие типы резервного копирования СУБД:

4. Типы восстановления данных

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

5. Способы резервного копирования

Модуль поддерживает резервное копирование СУБД с помощью:

6. Способы восстановления данных

Модуль поддерживает следующие способы восстановления СУБД из резервных копий:

7. Способы аутентификации в СУБД

Модуль поддерживает три способа аутентификации в СУБД.

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

  2. Через Unix-сокет с помощью метода peer. Для аутентификации используются полномочия пользователя ОС.

  3. С помощью внешнего хранилища секретов. Для аутентификации используются учетные данные пользователя СУБД в зашифрованном виде.

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

    HashiCorp Vault 1.16.3

    Astra Linux 1.7

    Ubuntu 20.04

    RHEL 8

8. Комплект поставки

Дистрибутив модуля поставляется в виде deb-пакета с именем rubackup-postgresql_<version>_amd64_signed.deb и в виде rpm-пакета с именем rubackup-postgresql-<version>.x86_64.rpm, где <version> — номер версии поставляемого модуля.

Пакет доступен для скачивания на официальном сайте https://www.rubackup.ru/go/.

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

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

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

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

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

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

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

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

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