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

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

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

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

PostgreSQL

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.

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