Резервное копирование и восстановление с использованием pgBackRest

Евгения Кузина

Обзор

ADPG использует функциональные возможности утилиты pgBackRest для создания резервных копий кластера (бэкапов) и восстановления его из этих копий. Это решение легко масштабируется для больших баз данных и существенных рабочих нагрузок. Все действия по резервному копированию выполняются от имени пользователя postgres.

Бэкап — это согласованная копия кластера баз данных, которую можно использовать для восстановления после сбоя оборудования, для восстановления на определенный момент времени (Point-In-Time Recovery, PITR) или для запуска нового резервного сервера. Можно создавать следующие типы бэкапов:

  • Full backup — pgBackRest копирует все содержимое кластера. Первая резервная копия кластера базы данных всегда является полным бэкапом (full backup). pgBackRest может восстановить кластер, используя только полный бэкап. Такой бэкап не зависит ни от каких файлов, не входящих в него.

  • Differential backup — pgBackRest копирует только те файлы базы данных, которые изменились с момента последнего полного резервного копирования (full backup). Чтобы восстановить кластер из дифференциального бэкапа, pgBackRest копирует все файлы из текущего дифференциального бэкапа и неизмененные файлы из предыдущего полного бэкапа. Дифференциальный бэкап занимает меньше места на диске, но для восстановления из него также требуется полный бэкап.

  • Incremental backup — pgBackRest копирует только файлы базы данных, изменившиеся с момента последнего резервного копирования, которое может быть созданием еще одного инкрементного, дифференциального или полного бэкапа. Поскольку инкрементные бэкапы включают только файлы, измененные с момента предыдущего резервного копирования, они обычно намного меньше, чем полные или дифференциальные бэкапы. Инкрементный бэкап зависит от других резервных копий. Все предыдущие инкрементные, дифференциальные и полные бэкапы должны быть валидными, чтобы можно было выполнить восстановление из инкрементного бэкапа. Последовательность резервных копий может не включать дифференциальные бэкапы.

Настройка резервного копирования

Чтобы включить создание бэкапов с помощью утилиты pgBackRest, активируйте переключатель Enable backups, отображаемый на вкладке Primary Configuration сервиса ADPG (Clusters → Кластер ADPG → Services → ADPG → Primary configuration). После этого вы сможете развернуть ноду Enable backups и указать настройки pgBackRest, описанные ниже.

Включение резервного копирования
Включение резервного копирования
ПРИМЕЧАНИЕ
После установки всех необходимых параметров на вкладке Primary Configuration нажмите Save, чтобы сохранить текущую конфигурацию, и запустите действие сервиса ADPG Reconfigure & Restart.

В настройках pgBackRest каждый кластер PostgreSQL/ADPG, для которого создается бэкап, имеет свою конфигурацию, называемую станза (stanza). Параметры станзы определяют, где расположен кластер, как следует выполнять его резервное копирование, параметры архивирования и т.д. В ADPG станза создается с именем, указанным в поле Backup stanza, и добавленным префиксом: adpg<версия>-. Например, если указанное имя mystanza, то результат — adpg16-mystanza.

Также можно задать параметр Archive timeout(s), который определяет время ожидания (в секундах) перед принудительным переключением на следующий файл WAL. Значение по умолчанию — 1800. Это полезно, когда база данных загружена незначительно, а WAL-файлы медленно заполняются, чтобы гарантировать, что архивирование WAL не прекращается на длительный период.

Хранилища бэкапов

Используйте параметр Backup repo, чтобы указать путь к репозиторию, в котором pgBackRest хранит бэкапы и архивирует сегменты WAL. Репозиторий должен существовать и быть доступен для всех ADPG-нод кластера.

Чтобы определить тип хранилища, укажите опцию Repo type. Для хранения бэкапов можно использовать следующие типы хранилищ:

  • posix — хранилище, совместимое с POSIX. Это значение по умолчанию. Директории на всех нодах должны быть синхронизированы между собой, например, средствами сетевой файловой системы.

  • s3 — хранилище S3. При выборе типа S3 необходимо указать настройки, находящиеся в разделе S3 Configuration. Настройки S3 перечислены в таблице ниже. Бакет, используемый для хранения репозитория, должен быть создан заранее. Репозиторий может располагаться в корне бакета (/), но обычно его размещают в подкаталоге. Таким образом, лог-файлы хранилища объектов или другие данные также смогут храниться в бакете без конфликтов.

  • cifs — хранилище, поддерживающее протокол CIFS.

ПРИМЕЧАНИЕ

Вам необходимо самостоятельно настроить хранилища POSIX и CIFS для корректной работы кластера. ADPG не проверяет правильность монтирования папок и настройки POSIX и CIFS.

Убедитесь, что папки POSIX принадлежат пользователю postgres или доступны для него на чтение и запись на каждом хосте. Если это не так, пересоздайте их от имени пользователя postgres.
Параметр Описание

S3 URI style

Стиль написания S3 URI. Поддерживаются следующие стили:

  • host — <bucket>.<endpoint>.<host>. Например, mybucket.us-east-1.amazonaws.com.

  • path — <endpoint>.<host>/<bucket>. Например, us-east-1.amazonaws.com/mybucket.

Значение по умолчанию — path

S3 Region

Регион репозитория S3, в котором был создан бакет

S3 Bucket

S3-бакет, используемый для хранения репозитория с резервными копиями

S3 Endpoint

Конечная точка репозитория S3. Конечная точка должна быть валидна для указанного региона

S3 Key

Ключ доступа к репозиторию S3, используемый для доступа к бакету

S3 Key Secret

Секретный ключ доступа к репозиторию S3, используемый для доступа к бакету

Срок хранения бэкапов

Вы можете определить параметры хранения бэкапов. Retention Full type определяет, представляет ли параметр Retention Full период времени (дни) или количество полных бэкапов, которые необходимо сохранить. Доступны следующие значения Retention Full type:

  • count — задается количество бэкапов, которые необходимо сохранить. Значение по умолчанию.

  • time — полные бэкапы старше значения Retention full (в днях) будут удалены из репозитория, если существует хотя бы один бэкап, срок действия которой истекает через количество дней, равное или превышающее Retention full. Например, если Retention full равен 30 (дням) и есть два полных бэкапа: один 25-дневный и один 35-дневный, — бэкапы не будут удалены, поскольку по истечении срока хранения 35-дневного бэкапа будет доступен только 25-дневный бэкап, что нарушит политику хранения, согласно которой по крайней мере один бэкап должен быть создан за 30 дней до истечения срока хранения более старого. По истечении срока хранения полного бэкапа срок действия всех дифференциальных и инкрементных бэкапов, связанных с ним, также истечет.

Вы можете использовать опцию Retention diff, чтобы указать количество сохраняемых дифференциальных бэкапов. По истечении срока хранения дифференциального бэкапа срок хранения всех инкрементных бэкапов, связанных с ним, также истечет. Если этот параметр не указан, все дифференциальные бэкапы будут храниться до тех пор, пока не истечет срок хранения полных бэкапов, от которых они зависят.

Сжатие бэкапов

Чтобы включить сжатие бэкапов, установите флажок Enable compression и укажите параметр Compression type. Используйте одно из следующих значений: bz2, gz, lz4 и zst. Значение по умолчанию — gz.

Вы также можете установить Compress level — уровень сжатия файла (от 0 до 9), используемый, когда Compression type не равен none. Если эта опция не указана, используются следующие уровни на основе значения Compression type:

  • bz2 — 9;

  • gz — 6;

  • lz4 — 1;

  • zst — 3.

Логирование

По умолчанию ADPG размещает лог-файлы pgBackRest по следующему пути: /var/log/adpg16-pgbackrest. Используйте опцию Log path, чтобы изменить каталог для хранения лог-файлов.

Вы также можете установить уровень логирования pgBackRest в поле Log level. Возможные значения: off, error, warn, info, detail, debug и trace. Значение по умолчанию info.

Расширенная конфигурация pgBackRest

ADPG позволяет задавать настройки pgBackRest, недоступные в пользовательском интерфейсе. Для этого установите флажок Use custom config и укажите необходимые настройки в полях Global options и Custom options. В этом случае все настройки pgBackRest кроме Backup stanza применятся из этих полей. Параметры из Global options добавляются в раздел [global] конфигурационного файла pgBackRest. Конфигурационный файл находится по следующему пути: /etc/adpg16-pgbackrest/adpg16-pgbackrest.conf.

ПРИМЕЧАНИЕ
Если вы устанавливаете флаг Use custom config и задаете кастомные настройки pgBackRest, ADPG записывает эти настройки в конфигурационный файл pgBackRest без проверки. В случае некорректных настроек сообщение об ошибке не будет выведено в интерфейсе ADCM. Вам необходимо самостоятельно убедиться, что настройки верные, а папка для хранения бэкапов существует и доступна.

Создание бэкапа

После включения резервного копирования и установки всех необходимых параметров, как описано выше, используйте действие Backup: Start сервиса ADPG, чтобы создать бэкап. При выполнении этого действия ADCM отображает диалоговое окно, в котором можно выбрать тип бэкапа из раскрывающегося списка.

Изменение типа бэкапа
Изменение типа бэкапа

В открывшемся окне выберите тип бэкапа.

Выбор типа бэкапа
Выбор типа бэкапа

По умолчанию pgBackRest создает инкрементные бэкапы. Однако инкрементный бэкап должен основываться на полном бэкапе. Если полного бэкапа (full backup) не существует, pgBackRest создаст полный бэкап независимо от того, какой тип бэкапа выбран.

После выбора типа бэкапа нажмите Run, чтобы подтвердить действие. Резервная копия будет создана в указанном хранилище (Backup repo). Если при создании бэкапа возникают ошибки, информацию о них можно найти на странице Jobs.

Восстановление кластера ADPG

Используйте действие Backup: Restore cluster сервиса ADPG для восстановления кластера из последней резервной копии на всех нодах. Информацию о последнем бэкапе можно найти в выводе действия Backup: Info. Если в ходе операции восстановления возникнут ошибки, информация о них будет отображена на странице Jobs.

ВАЖНО
Действие Backup: Restore cluster восстанавливает состояние кластера на конец архива WAL. Если произошло случайное удаление объектов базы данных, используйте Ручное PITR-восстановление с параметром --target, так как наиболее вероятно, что действие Backup: Restore Cluster восстановит состояние кластера на тот момент, когда объекты базы данных уже были удалены.

Получение списка бэкапов

Выполните действие Backup: Info сервиса ADPG, чтобы получить список созданных резервных копий. Результат операции можно посмотреть на странице Jobs. Для этого кликните строку Backup: Info в списке задач, переключитесь на вкладку Ansible [check], найдите строку Show backups information в конце списка и нажмите на нее, чтобы раскрыть.

Результат действия Backup: Info
Результат действия "Backup: Info"

Если в ходе операции возникнут ошибки, информация о них также будет отображена на странице Jobs.

Ручное PITR-восстановление ADPG-кластера

В автоматическом режиме восстановить кластер можно только из последней резервной копии. Для восстановления состояния кластера на определенный момент времени выполните шаги, описанные ниже:

  1. Убедитесь, что подходящий бэкап существует. Для этого можно использовать действие Backup: Info.

  2. Присвойте переменной ${TIME} значение времени, на которое вам необходимо восстановить кластер:

    $ TIME="2024-04-23 09:00:00+00"

  3. Используйте действие Stop, чтобы остановить сервис ADPG. Убедитесь, что все ADPG-ноды остановлены. Вы можете проверить это на странице Jobs.

  4. Вы можете опционально удалить содержимое каталога /pg_data1/adpg16 на каждой ADPG-ноде и запустить восстановление без опции --delta. Либо запустить восстановление с опцией --delta, как показано ниже, тогда удалять содержимое необязательно, но можно скопировать в другой каталог на случай сбоя при восстановлении из бэкапа.

  5. Удалите ключ кластера /initialize на любой etcd-ноде, используя следующую команду:

    $ /usr/lib/adpg16/usr/bin/etcdctl del --prefix=true "/arenadata/adpg16/<имя_кластера>/<UUID_кластера>/initialize

    Где <UUID_кластера> — UUID кластера (см. Основные конфигурационные параметры → Cluster UUID в статье Настройка кластера), а <имя_кластера> — имя кластера в змеином регистре.

    Например:

    $ /usr/lib/adpg16/usr/bin/etcdctl del --prefix=true "/arenadata/adpg16/test_adpg_cluster_1/81cb4ace-6ee0-4daa-bb5a-d181f7196caa/initialize"

  6. Используйте pgBackRest для восстановления кластера на каждой ADPG-ноде к моменту времени, указанному в переменной ${TIME}:

    $ /usr/lib/adpg16/usr/bin/pgbackrest --config=/etc/adpg16-pgbackrest/adpg16-pgbackrest.conf --stanza=<имя_станзы> --delta --type=time "--target=${TIME}" --target-action=promote restore

    Где <имя_станзы> — параметр Backup stanza с префиксом adpg<version>-.

    Например:

    $ /usr/lib/adpg16/usr/bin/pgbackrest --config=/etc/adpg16-pgbackrest/adpg16-pgbackrest.conf --stanza=adpg16-mystanza --delta --type=time "--target=${TIME}" --target-action=promote restore

  7. Убедитесь, что файлы postgresql.auto.conf и recovery.signal существуют в каталоге /pg_data1/adpg16.

  8. Запустите PostgreSQL на ноде-лидере от имени пользователя postgres, используя следующую команду:

    $ /usr/lib/adpg16/bin/pg_ctl start -D /pg_data1/adpg16

  9. Найдите строку starting point-in-time recovery в лог-файлах ADPG (путь по умолчанию /pg_data1/adpg16/log), чтобы убедиться, что восстановление на момент времени (PITR) запущено. См. Просмотр лог-файлов.

    ...
2024-04-23 14:16:11.478 UTC [25516] LOG: starting point-in-time recovery to 2024-04-23 09:00:00+00
...

  10. Остановите PostgreSQL на ноде-лидере от имени пользователя postgres, используя следующую команду:

    $ /usr/lib/adpg16/bin/pg_ctl stop -D /pg_data1/adpg16

  11. Используйте действие Start, чтобы запустить сервис ADPG.

Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней