Запуск действий в ADBM

Дарья Барышева

Обзор

После создания конфигурации формирование и удаление бэкапов производится автоматически согласно установленным расписаниям. Однако ADBM также позволяет управлять бэкапами вручную с помощью кластерных действий, описанных ниже.

ПРИМЕЧАНИЕ

Если кластер входит в кластерную группу, эти действия доступны только лидеру группы.

Чтобы запустить эти действия, выполните следующие шаги:

  1. Откройте страницу Backup manager в веб-интерфейсе ADB Control.

  2. В секции Clusters открывшейся страницы найдите кластер, для которого требуется запустить действие, и кликните по иконке added actions dark added actions light в табличной строке, соответствующей этому кластеру. Возможные действия доступны в выпадающем списке.

    Запуск действий из секции Clusters
    Запуск действий из секции Clusters
    Запуск действий из секции Clusters
    Запуск действий из секции Clusters

  3. Если требуется работать с определенным кластером, нажмите на его название в таблице, расположенной в секции Clusters. Откроется страница выбранного кластера. Кнопка Backup предназначена для запуска бэкапов. Чтобы открыть меню с другими действиями, нажмите added actions dark added actions light.

    Запуск действий на странице выбранного кластера
    Запуск действий на странице выбранного кластера
    Запуск действий на странице выбранного кластера
    Запуск действий на странице выбранного кластера

Запуск действий является эксклюзивной операцией. Нельзя инициализировать новое действие, не завершив предыдущее (исключение — Terminate). При попытке запуска нескольких действий одновременно возвращается следующая ошибка.

Ошибка при одновременном запуске действий
Ошибка при одновременном запуске действий
Ошибка при одновременном запуске действий
Ошибка при одновременном запуске действий
ВАЖНО

Начиная с версии ADBM 2.3.2 в меню могут отсутствовать некоторые из описанных ниже действий, если они не могут быть выполнены в текущий момент времени. В частности, после обновления кластера, требующего верификации или пересоздания конфигурации бэкапа, в списке отображаются только два действия: Verify и Create configuration. Доступ к другим действиям появляется после запуска одного из них.

Backup

Запуск бэкапов осуществляется автоматически в соответствии с расписаниями, установленными с помощью следующих параметров для текущей версии конфигурации (см. вкладку Configuration → Schedule):

  • Full Backup schedule — полные бэкапы;

  • Differential backup schedule — дифференциальные бэкапы;

  • Incremental backup schedule — инкрементные бэкапы.

Если необходимо сформировать бэкап вне настроенных расписаний, выполните шаги:

  1. Нажмите на кнопку Backup на странице выбранного кластера либо выберите из выпадающего списка действие Backup для одного из кластеров в секции Clusters.

    Переход к действию Backup
    Переход к действию Backup
    Переход к действию Backup
    Переход к действию Backup

    Открывшееся окно содержит следующую информацию:

    • Restore point — автоматически сгенерированное имя для новой точки восстановления.

    • Type — тип бэкапа. Возможные значения:

      • Full — полный;

      • Incr — инкрементный;

      • Diff — дифференциальный.

    • Configuration — версия конфигурации, которая будет применена. Можно нажать на название, чтобы просмотреть и при необходимости изменить параметры конфигурации в списке конфигураций.

    • Date — текущие дата и время.

    • Delta — флаг, указывающий на необходимость использования контрольных сумм (checksum) при создании бэкапа с типом Incr или Diff. Не оказывает влияния на формирование бэкапов с типом Full.

    • Fail on low space — флаг, при включении которого формирование бэкапа не будет запущено, если хранилище имеет статус Critical. Значение флага не учитывается, если в настройках хранилища выключен флаг Check free space.

    • Preserve table metadata — флаг, включающий сбор метаданных (таких как имена таблиц, схемы и внутренние идентификаторы кластеров, бэкапов и точек восстановления) для всех пользовательских таблиц во время выполнения действия. Метаданные хранятся в ADBM (в таблице adbm.rp_table_metadata) и в репозитории бэкапов (в файле table_metadata.json).

      Точку восстановления с метаданными можно выбрать при выполнении частичного восстановления — это позволит ADBM проверить существование выбранных таблиц до запуска операции восстановления.

      ВАЖНО

      Полная консистентность между сохраненными метаданными и фактическими данными таблиц не гарантируется, если во время создания точки восстановления выполнялись DDL-операции. Рекомендуется создавать точки восстановления с флагом Preserve table metadata, когда DDL-операции не выполняются.
      Форма действия Backup
      Форма действия Backup
      Форма действия Backup
      Форма действия Backup

  2. Выберите тип бэкапа в поле Type. Измените название точки восстановления в поле Restore point, если необходимо.

  3. Нажмите Run.

  4. В результате запускается действие Backup. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

  5. После успешного применения всех действий бэкап становится доступен в списке бэкапов на вкладке Backups.

    Созданный бэкап доступен на вкладке Backups
    Созданный бэкап доступен на вкладке Backups
    Созданный бэкап доступен на вкладке Backups
    Созданный бэкап доступен на вкладке Backups

Начиная с версии ADBM 2.4.0 справа от имени бэкапа в столбце Description отображается индикатор времени выполнения бэкапа (в % от рассчитанной продолжительности операции на всех сегментах кластера). Обратите внимание, что расчет прогресса выполнения бэкапа осуществляется только для этапа физического резервирования кластера и не включает в себя остальные действия.

Create restore point

ПРИМЕЧАНИЕ

  • Действие Create restore point доступно при условии наличия хотя бы одного бэкапа в статусе Done.

  • Действие Create restore point недоступно для кластера, на котором есть проблемы, обнаруженные скриптом pgbackrest_wrapper.

Точки восстановления создаются автоматически в соответствии с расписанием, установленным с помощью параметра Restore point creation schedule для текущей версии конфигурации (см. вкладку Configuration → Schedule).

Если необходимо добавить restore point вне настроенного расписания, выполните шаги:

  1. Выберите действие Create restore point на странице выбранного кластера или в секции Clusters.

    Переход к действию Create restore point
    Переход к действию Create restore point
    Переход к действию Create restore point
    Переход к действию Create restore point

    Открывшееся окно содержит следующую информацию:

    • Restore point — автоматически сгенерированное имя для новой точки восстановления.

    • Configuration — версия конфигурации, которая будет применена. Можно нажать на название, чтобы просмотреть и при необходимости изменить параметры конфигурации в списке конфигураций.

    • Date — текущие дата и время.

    • Preserve table metadata — флаг, включающий сбор метаданных (таких как имена таблиц, схемы и внутренние идентификаторы кластеров, бэкапов и точек восстановления) для всех пользовательских таблиц во время выполнения действия. Метаданные хранятся в ADBM (в таблице adbm.rp_table_metadata) и в репозитории бэкапов (в файле table_metadata.json).

      Точку восстановления с метаданными можно выбрать при выполнении частичного восстановления — это позволит ADBM проверить существование выбранных таблиц до запуска операции восстановления.

      ВАЖНО

      Полная консистентность между сохраненными метаданными и фактическими данными таблиц не гарантируется, если во время создания точки восстановления выполнялись DDL-операции. Рекомендуется создавать точки восстановления с флагом Preserve table metadata, когда DDL-операции не выполняются.
      Форма действия Create restore point
      Форма действия "Create restore point"
      Форма действия Create restore point
      Форма действия "Create restore point"

  2. Измените название точки восстановления в поле Restore point, если необходимо.

  3. Нажмите Run.

  4. В результате запускается действие Create restore point. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

  5. После успешного применения всех действий новая точка восстановления становится доступной. В этом можно убедиться при следующем запуске действия Common restore, Partial restore или Cleanup.

    Новая точка восстановления доступна
    Новая точка восстановления доступна
    Новая точка восстановления доступна
    Новая точка восстановления доступна

Common restore

Действие Common restore позволяет восстановить базы данных на момент создания одной из существующих restore points. Это единственное из действий, которое можно применить как к запущенному, так и к остановленному кластеру ADB. Логика выполнения действия будет зависеть от статуса кластера:

  • Кластер запущен (отмечен статусом Up в UI ADBM). В этом случае до запуска восстановления автоматически проводятся дополнительные проверки на возможность применения выбранного бэкапа к кластеру:

    • Происходит сверка топологий — сохраненной в бэкапе и полученной из кластера ADB (из системной таблицы gp_segment_configuration).

    • Происходит проверка метаданных бэкапа (см. Verify ниже).

    Если проверки проходят успешно, кластер автоматически останавливается. Кроме этого, если в процессе восстановления фиксируется ошибка, то можно выполнить Restore retry — это перезапуск последнего упавшего процесса восстановления уже без выполнения дополнительных проверок.

  • Кластер остановлен (отмечен статусом Down в UI ADBM). В этом случае валидация пропускается. Однако процесс восстановления запустить возможно. Данным способом рекомендуется пользоваться исключительно в случае фатальных проблем с кластером, когда он не запускается.

ПРИМЕЧАНИЕ

В ADBM 2.5.0 добавлена дополнительная возможность восстановления данных в остановленном кластере — путем создания data flow с типом Copy.

Для запуска восстановления БД выполните шаги:

  1. Выберите действие Common restore на странице выбранного кластера или в секции Clusters.

    Переход к действию Common restore
    Переход к действию Common restore
    Переход к действию Common restore
    Переход к действию Common restore

    Открывшееся окно содержит следующую информацию:

    • Time period — временной диапазон, используемый для поиска нужной restore point. По умолчанию установлена текущая дата.

    • Select restore point — точка восстановления, на момент создания которой требуется восстановить БД.

    • Databases — базы данных, которые можно восстановить на момент выбранной restore point.

    • Processes — максимальное количество процессов для восстановления одного сегмента.

    • Restore mirrors — выпадающий список, значение которого определяет, восстанавливать ли данные для зеркал (mirror) и standby при их наличии в кластере:

      • No — не восстанавливать зеркала.

      • Parallel — восстанавливать зеркала параллельно с primary-сегментами.

      • Sequential — восстанавливать зеркала после того, как все primary-сегменты восстановлены.

    • Override files — определяет, как процесс восстановления обрабатывает существующие файлы в каталогах данных и табличных пространств. Доступны три варианта:

      • All files — полностью перезаписывает существующие файлы в целевых каталогах. Соответствует опции --force команды pgbackrest restore.

      • Compare using time and size — сравнивает существующие файлы с файлами из резервной копии по времени изменения и размеру, и перезаписывает только те, которые отличаются. Соответствует опциям --force --delta команды pgbackrest restore.

      • Compare using checksums — сравнивает существующие файлы с файлами из резервной копии по контрольным суммам, и перезаписывает только те, которые отличаются. Соответствует опции --delta команды pgbackrest restore.

    • Verify — флаг, указывающий на необходимость проверки данных бэкапа перед их восстановлением.

    ВАЖНО

    • Параметр Override files доступен начиная с ADBM 2.14.0 и заменяет флаги Delta и Force.

    • Сравнение по времени и размеру выполняется быстрее, но обеспечивает меньшую гарантию целостности по сравнению с проверкой по контрольным суммам.

    После нажатия кнопки Details отображаются поля с дополнительной информацией:

    • Date created — время создания выбранной restore point.

    • Backup date — время формирования последнего бэкапа перед добавлением выбранной restore point.

    • Backup type — тип последнего бэкапа, сформированного перед добавлением выбранной restore point.

    • Configuration — версия конфигурации, использованная при создании выбранной restore point. Можно нажать на название, чтобы просмотреть параметры конфигурации в списке конфигураций.

      Форма действия Common restore
      Форма действия Common restore
      Форма действия Common restore
      Форма действия Common restore

  2. Заполните необходимые поля:

    • Выберите точку восстановления в выпадающем списке Select restore point. Используйте фильтр Time period, если необходимо.

    • Выберите базы данных, требующие восстановления, в выпадающем списке Databases.

    • Выберите значение из списка Restore mirrors.

  3. Нажмите Run.

  4. В результате запускается действие Restore. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

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

Для запущенных кластеров ADB (со статусом UP) существует возможность повторного запуска последнего действия Common restore, завершившегося с ошибкой. Для этого требуется повторно выбрать действие Common restore (см. шаг 1 выше) и нажать Retry в открывшемся окне. Если необходимо выполнить действие Common restore заново (со всеми проверками), нажмите New restore.

Попытка повторного выполнения последнего действия Common restore
Попытка повторного выполнения последнего действия Common restore
Попытка повторного выполнения последнего действия Common restore
Попытка повторного выполнения последнего действия Common restore

Partial restore

ПРИМЕЧАНИЕ
Действие Partial restore доступно начиная с версии ADBM 2.2.2.

Действие Partial restore позволяет восстановить выбранные таблицы на момент создания одной из существующих точек восстановления без остановки кластера ADB.

Поскольку процесс выполняется на активном кластере, прямая перезапись файлов данных невозможна. ADBM использует многоэтапную фильтрацию системных каталогов и WAL-файлов, чтобы выбрать только записи, которые относятся к выбранным восстанавливаемым таблицам. Поэтому выполнение Partial restore может занимать значительно больше времени, чем полное восстановление всего кластера.

ВАЖНО

  • В процессе выполнения частичного восстановления данные в целевых таблицах находятся в неконсистентном состоянии. Запросы к ним могут возвращать ошибки или неполные данные.

  • Данная операция оправдана только в тех случаях, когда недопустима остановка всего кластера ради восстановления отдельных объектов.

Действие Partial restore рекомендуется использовать:

  • Для восстановления небольшого количества таблиц или схем, если простой кластера для полного восстановления недопустим по требованиям доступности (SLA).

  • В периоды минимальной нагрузки на восстанавливаемые объекты, чтобы минимизировать влияние их неконсистентного состояния на пользователей.

Действие Partial restore не рекомендуется использовать для срочного восстановления большого объема данных. В этом случае полное восстановление (действие Common restore) с остановкой кластера будет выполнено значительно быстрее и безопаснее.

Начиная с версии 2.14.0 ADBM может собирать метаданные таблиц во время выполнения действий Backup и Create restore point. Без метаданных ADBM восстанавливает системные каталоги на каждом сегменте и сканирует их для поиска нужных таблиц, что требует дополнительного дискового пространства и времени. Использование метаданных исключает этот шаг и ускоряет проверку таблиц перед восстановлением. Если выбранная точка восстановления содержит метаданные, то в диалоговом окне действия Partial restore будут показаны таблицы, которые соответствуют выбранному фильтру и существуют в бэкапе.

Чтобы запустить действие Partial restore, выполните следующие шаги:

  1. Выберите действие Partial restore на странице выбранного кластера или в секции Clusters.

    Переход к действию Partial restore
    Переход к действию Partial restore
    Переход к действию Partial restore
    Переход к действию Partial restore

  2. На шаге General settings настройте значения следующих параметров:

    • Time period — временной диапазон, используемый для поиска нужной restore point. По умолчанию установлена текущая дата.

    • Select restore point — точка восстановления, на момент создания которой требуется восстановить таблицы БД. Чтобы показать только точки восстановления с метаданными, установите флаг Show restore points with metadata.

    • Source database — исходная база данных, таблицы которой можно восстановить на момент выбранной restore point.

    • Target database — целевая база данных, в которую требуется восстановить выбранные таблицы. Если поле не заполнено, таблицы будут восстановлены в исходной БД.

    • Processes — максимальное количество параллельных процессов на хост в процессе восстановления. Допускается ввод значений из следующего диапазона: [1,100]. Значение по умолчанию берется из поля Max processes per host в конфигурации бэкапа (см. секцию Workspace в статье Управление конфигурациями в ADBM).

    • Verify — флаг, указывающий на необходимость проверки данных бэкапа перед их восстановлением.

      РЕКОМЕНДАЦИЯ
      Поскольку каждый процесс осуществляет восстановление данных одного сегмента на хосте, в качестве максимума рекомендуется выбирать число, равное количеству primary-сегментов на хосте. При большем значении остальные процессы не будут использоваться, при меньшем — процесс восстановления данных будет дольше, но при этом потреблять ресурсов он будет меньше (за счет ограничения сверху).

      На вкладке Restore point details отображается следующая информация:

    • Date created — время создания выбранной restore point.

    • Backup date — время формирования последнего бэкапа перед добавлением выбранной restore point.

    • Backup type — тип последнего бэкапа, сформированного перед добавлением выбранной restore point.

    • Configuration — версия конфигурации, использованная при создании выбранной restore point. Можно нажать на название, чтобы просмотреть параметры конфигурации в списке конфигураций.

      Форма действия Partial restore. Шаг General settings
      Форма действия Partial restore. Шаг General settings
      Форма действия Partial restore. Шаг General settings
      Форма действия Partial restore. Шаг General settings

  3. На шаге Table filter настройте значения следующих параметров:

    • Table suffix — суффикс, который будет добавлен к именам восстановленных таблиц. Максимальная длина — 32 символа. Если поле не заполнено, будут использованы имена таблиц из исходной БД. В этом случае для успешного восстановления важно, чтобы выбранные таблицы отсутствовали в целевой БД.

    • В списке Method for selecting tables to restore выберите способ указания таблиц для восстановления:

      • Search by pattern — введите маски имен таблиц вручную. Чтобы добавить маску, введите ее в поле Table name masks и нажмите add default dark add default light. Для удаления маски нажмите close default dark close default light. В маске поддерживается формат <schema>/<table_name>. В любой части имени таблицы (<table_name>) допускаются символы подстановки * (соответствуют нулю или более символам по аналогии с SQL-шаблоном %). При отсутствии в шаблоне <schema>/ по умолчанию используется схема public.

      • Upload table list from file — загрузите файл в формате .txt со списком таблиц. Каждая строка в файле должна содержать имя таблицы в формате <schema>/<table_name>. Требования к именам таблиц такие же, как при ручном вводе в параметре Search by pattern.

      Если используется точка восстановления с метаданными, таблицы, подходящие под условия фильтра, будут показаны в этом диалоговом окне. Если используется точка восстановления без метаданных, отобразится сообщение The tables cannot be validated because the selected restore point does not have table metadata saved. В этом случае список восстанавливаемых таблиц не будет показан, и ADBM начнет восстановление без предварительной проверки.

      Форма действия Partial restore. Шаг Table filter
      Форма действия Partial restore. Шаг Table filter
      Форма действия Partial restore. Шаг Table filter
      Форма действия Partial restore. Шаг Table filter
      ВНИМАНИЕ

      • Если поле Table suffix не заполнено и таблица с исходным именем уже существует в целевой БД, в дочернем действии фиксируется ошибка Couldn’t create table <table_name> и восстановление данных этой таблицы не производится (процесс восстановления других таблиц при этом продолжается). Во избежание ошибок используйте суффикс в случае существования восстанавливаемой таблицы.

      • При выборе суффикса Table suffix следует учитывать, что в ADB максимальная длина имени отношения БД (в том числе и партиции) составляет 64 символа. Если общая длина имени с учетом суффикса превышает указанный лимит, имя будет обрезано, что потенциально может привести к пересечению имен отношений.

      • Если метаданные используются и ни одна таблица не соответствует выбранным фильтрам, операцию восстановления невозможно будет запустить. Если метаданные не используются, то проверка таблиц в исходной БД на соответствие фильтрам осуществляется после запуска действия. В этом случае, если указанные таблицы невозможно найти (например, указано имя несуществующей схемы), в дочернем действии фиксируется ошибка No tables were found by provided filter и восстановление данных переводится в статус Failed. Если хотя бы один фильтр валиден, таблицы, соответствующие этому фильтру, восстанавливаются успешно, а неверные фильтры игнорируются. Во избежание ошибок убедитесь, что все выбранные схемы и таблицы присутствуют в исходной БД.

  4. Нажмите Run.

  5. В результате запускается действие Table restore. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

  6. После успешного применения всех действий данные выбранных таблиц восстанавливаются на момент указанной restore point. Если восстановление хотя бы одной таблицы завершается ошибкой, родительское действие Table restore переводится в статус Warning, а статус восстановления каждой таблицы можно увидеть на странице Restores — в деталях выбранного восстановления на вкладке Tables.

Cleanup

Действие Cleanup выполняется автоматически в соответствии с расписанием, установленным с помощью параметра Cleanup schedule для текущей версии конфигурации (см. вкладку Configuration → Schedule). Это действие удаляет:

  • Наиболее старые полные бэкапы — если общее число полных бэкапов превысило значение параметра Number of full backups, установленное для текущей конфигурации.

  • Наиболее старые дифференциальные бэкапы — если общее число дифференциальных бэкапов превысило значение параметра Number of differential backups, установленное для текущей конфигурации.

  • Бэкапы, имеющие следующие статусы: Failed, Invalid.

  • Неактивные версии конфигурации, которые не имеют связанных бэкапов.

ПРИМЕЧАНИЕ

Начиная с версии ADBM 2.12.0, если в секции Schedule конфигурации бэкапа настроена опция Deleted backup TTL, то бэкап переходит в статус Deleted, хотя все его данные при этом удаляются. Информация о бэкапах в статусе Deleted отображается на вкладке Backups.

При ручном запуске действия Cleanup вы выбираете точку восстановления, и ADBM определяет ближайший полный или дифференциальный бэкап, созданный перед ней. Затем удаляются все бэкапы и точки восстановления, связанные с этим бэкапом. Объекты, перечисленные выше, также удаляются. С помощью флага Target only можно исключить эти объекты из очистки и удалить только данные, привязанные к выбранной точке.

Чтобы запустить действие Cleanup вручную, выполните шаги:

  1. Выберите действие Cleanup на странице выбранного кластера или в секции Clusters.

    Переход к действию Cleanup
    Переход к действию Cleanup
    Переход к действию Cleanup
    Переход к действию Cleanup

    Открывшееся окно содержит следующую информацию:

    • Time period — временной диапазон, используемый для поиска нужной restore point. По умолчанию установлена текущая дата.

    • Select restore point — точка восстановления, для которой требуется удалить набор связанных бэкапов и restore points.

    • Configuration — версия конфигурации, использованная при создании выбранной restore point. Можно нажать на название, чтобы просмотреть параметры конфигурации в списке конфигураций.

    • Date created — время создания выбранной restore point.

      Форма действия Cleanup
      Форма действия Cleanup
      Форма действия Cleanup
      Форма действия Cleanup

  2. Настройте параметры очистки данных:

    • Выберите точку восстановления в выпадающем списке Select restore point. Используйте фильтр Time period, если необходимо.

    • С помощью флага Target only выберите, какие данные требуется удалить. Если флаг установлен, удаляются только бэкапы, зависящие от целевой точки восстановления (выбранной в Select restore point). При этом политики хранения, заданные в конфигурации, не учитываются. Если флаг не установлен (по умолчанию), то сначала удаляются бэкапы, зависящие от целевой точки восстановления, а затем данные согласно настройкам хранения.

  3. Нажмите Run.

  4. В результате запускается действие Start cleanup job for Verify backup. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

  5. После успешного применения всех действий бэкапы и restore points удаляются согласно правилам, описанным выше. Чтобы убедиться в этом, можно открыть список бэкапов на вкладке Backups.

    Например, если при наличии в системе двух бэкапов — полного (full) и инкрементного (incremental) — выбрать точку восстановления, созданную после инкрементного, оба бэкапа будут удалены.

    Список бэкапов перед запуском Cleanup
    Список бэкапов перед запуском Cleanup
    Список бэкапов перед запуском Cleanup
    Список бэкапов перед запуском Cleanup
    Список бэкапов после запуска Cleanup
    Список бэкапов после запуска Cleanup
    Список бэкапов после запуска Cleanup
    Список бэкапов после запуска Cleanup

Для лучшего понимания логики запускаемого вручную действия Cleanup можно рассмотреть пример, приведенный ниже. Рисунок изображает временную ось с перечнем созданных за указанный период бэкапов различных типов (с именами full*, diff*, incr*) и restore points (с именами rp*). Таблица демонстрирует, какие объекты будут удалены, если на форме действия Cleanup выбрать одну из изображенных точек восстановления. При этом предполагается, что лимиты хранения не превышены или в форме действия Cleanup установлен флаг Target only.

Пример со списком бэкапов и restore points
Пример со списком бэкапов и restore points
Пример со списком бэкапов и restore points
Пример со списком бэкапов и restore points
Логика удаления при ручном запуске Cleanup
Выбранная restore point Объекты, которые будут удалены

rp1

Все бэкапы и restore points за приведенный на рисунке период

rp2

Все бэкапы и restore points за приведенный на рисунке период

rp3

Все бэкапы и restore points за приведенный на рисунке период

rp4

Все бэкапы и restore points за приведенный на рисунке период

rp5

diff1, incr2, rp5 — rp8

rp6

diff1, incr2, rp5 — rp8

rp7

diff1, incr2, rp5 — rp8

rp8

diff1, incr2, rp5 — rp8

Verify

Действие Verify выполняет следующее:

  • Сравнивает метаданные бэкапов, хранимые в ADBM, с метаданными, получаемыми от pgbackrest (т.е. с данными по фактически имеющимся бэкапам).

  • Определяет валидность бэкапов и архивов в репозитории (на момент создания выбранной точки восстановления). При этом выполняются следующие проверки:

    • Наличие файлов бэкапов.

    • Размер файлов бэкапов.

    • Контрольные суммы файлов бэкапов.

    • Валидность архивов WAL, относящихся к бэкапам.

При обнаружении разницы бэкапы переводятся в статус Invalid и не могут быть использованы для восстановления баз данных. Такие бэкапы будут удалены при следующем запуске действия Cleanup.

Перед сравнением метаданных и данных ADBM дополнительно проверяет наличие всех конфигурационных файлов (pgbackrest.conf) для всех существующих timeline на всех сегмент-хостах. Если каких-то из этих файлов нет, то берется последняя имеющаяся версия конфигурации timeline, на ее основе формируется новый конфигурационный файл, который записывается на сегмент-хост для этого timeline. Это необходимо для того, чтобы до проверки метаданных и данных по бэкапам в системе были все необходимые конфигурации.

ПРИМЕЧАНИЕ

  • Если репозиторий недоступен в ходе выполнения действия Verify, бэкапы переводятся в статус Unknown. После того, как репозиторий станет доступен, бэкапы смогут перейти в статус Done в результате запуска действия Verify.

  • Проверка данных бэкапов осуществляется начиная с версии ADBM 2.5.0 с использованием команды pgbackrest verify. До этого действие ограничивалось проверкой метаданных командой pgbackrest info.

  • Рекомендуется установить атрибут immutable для локального каталога монтирования NFS, чтобы обеспечить правильное определение доступности репозитория.

Выполнение действия Verify описано ниже:

  1. Выберите действие Verify на странице выбранного кластера или в секции Clusters.

    Переход к действию Verify
    Переход к действию Verify
    Переход к действию Verify
    Переход к действию Verify

  2. В открывшемся окне выберите точку восстановления (на момент создания которой требуется выполнить проверку данных бэкапов) и подтвердите действие, нажав Run.

    Подтверждение действия Verify
    Подтверждение действия Verify
    Подтверждение действия Verify
    Подтверждение действия Verify

  3. В результате запускается действие Verify backup. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

  4. После успешного применения всех действий некоторые бэкапы могут перейти в статус Invalid или Unknown. Чтобы найти такие бэкапы, можно воспользоваться фильтром Status на вкладке Backups.

Terminate

Действие Terminate позволяет прерывать некоторые запущенные действия. Это единственный тип действия, для которого берется отдельный распределенный lock по кластеру (в etcd), что позволяет запускать Terminate параллельно с другими типами действий.

ВАЖНО

  • В настоящий момент возможно прерывание действий следующих типов:

  • После успешного применения действия Terminate возможно возобновление последнего прерванного бэкапа с помощью действия Resume.

Ниже приведен пример прерывания действия Backup:

  1. Запустите действие Backup, как показано выше.

  2. Выберите действие Terminate на странице выбранного кластера или в секции Clusters.

    Переход к действию Terminate
    Переход к действию Terminate
    Переход к действию Terminate
    Переход к действию Terminate

  3. Подтвердите действие, нажав в открывшемся окне Run.

    Подтверждение действия Terminate
    Подтверждение действия Terminate
    Подтверждение действия Terminate
    Подтверждение действия Terminate

  4. В результате запускается действие Terminate. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

    Текущий бэкап получает статус Terminating. Статус бэкапа можно проверить в списке бэкапов на вкладке Backups.

    После успешного применения всех действий бэкап переводится в статус Stopped.

    Статус бэкапа изменен на Stopped
    Статус бэкапа изменен на Stopped
    Статус бэкапа изменен на Stopped
    Статус бэкапа изменен на Stopped

Resume

ВАЖНО

  • Начиная с версии ADBM 2.1.2 действие Resume доступно только для бэкапов с типом Full.

  • Файлы в бандлах не могут быть переиспользованы при возобновлении бэкапа. Число файлов, которые могут быть переиспользованы, зависит от значения параметра Bundle limit (задается в секции Storages бэкап-конфигурации): чем выше это значение, тем меньше файлов доступно для переиспользования при возобновлении бэкапа.

Действие Resume позволяет возобновить последний прерванный запуск бэкапа или последний запуск бэкапа, завершившийся ошибкой. Действие становится доступным в списке кластерных действий только после появления бэкапов в статусе Stopped или Failed. Ниже приведен пример возобновления бэкапа, прерывание которого описано в предыдущем разделе:

  1. Выберите действие Resume на странице выбранного кластера или в секции Clusters.

    Переход к действию Resume
    Переход к действию Resume
    Переход к действию Resume
    Переход к действию Resume

    Открывшееся окно содержит следующую информацию:

    • Restore point — автоматически сгенерированное имя для новой точки восстановления.

    • Configuration — версия конфигурации, которая будет применена. Можно нажать на название, чтобы просмотреть параметры конфигурации в списке конфигураций.

    • Date — текущие дата и время.

      Форма действия Resume
      Форма действия Resume
      Форма действия Resume
      Форма действия Resume

  2. Измените название точки восстановления в поле Restore point, если необходимо.

  3. Нажмите Run.

  4. В результате запускается действие Resume backup. Это действие, в свою очередь, порождает несколько дочерних действий (subaction). Просмотреть их можно на вкладке Actions (см. Просмотр действий в ADBM).

    Бэкап приобретает статус Resume. В этом можно убедиться, открыв список бэкапов на вкладке Backups.

    Бэкап в статусе Resume
    Бэкап в статусе Resume
    Бэкап в статусе Resume
    Бэкап в статусе Resume

  5. После успешного применения всех действий бэкап переводится в статус Done.

    Статус бэкапа изменен на Done
    Статус бэкапа изменен на Done
    Статус бэкапа изменен на Done
    Статус бэкапа изменен на Done

Create configuration

ПРИМЕЧАНИЕ
Действие Create configuration доступно начиная с версии ADBM 2.3.2.

Запуск действия Create configuration приводит к открытию вкладки Backup manager → Backup → Cluster → <Имя текущего кластера ADB> → Configuration, на которой можно создать новую конфигурацию для бэкапов на базе одной из существующих.

Переход к действию Create configuration
Переход к действию Create configuration
Переход к действию Create configuration
Переход к действию Create configuration
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней