Источниками резервируемых данных в терминах Системы являются такие сущности, как физический хост, виртуальная машина, контейнер, среды виртуализации. На этих источниках данные, подлежащие резервному копированию, хранятся в виде файлов или каталогов на файловых системах, баз данных под управлением CУБД, виртуальных машин (для сред виртуализации). Такие данные для Системы являются объектами резервного копирования.
Перед тем, как запускать задачи на резервное копирование или восстановление данных, необходимо зарегистрировать такие объекты в Системе. В данном разделе описывается процедура регистрации для всех поддерживаемых типов объектов и соответствующих им источников.
¶ 4.1. Регистрация объектов для резервного копирования файловых систем
Файловые объекты резервного копирования доступны на таких типах источников, как например физический сервер, виртуальная машина, контейнер. Система поддерживает все типы файловых систем, поддерживаемых на ОС, для которых доступен Агент Системы (см. «Руководство по установке»). Резервное копирование и восстановление данных осуществляется в многопоточном режиме. После установки Агента Системы (см. «Руководство по установке. Программа для ЭВМ Береста» на любой из таких источников, он автоматически регистрируется в Системе. Регистрацию источника можно проверить в WEB-консоли, перейдя в панели навигации на вкладку «Конфигурация» → «Источники данных» → «Агентские». Справа, в открывшейся таблице можно наблюдать перечень всех установленных в домене Системе Агентов, их статус и имя сервера (или виртуальной машины, или контейнера), внутри которых установлен Агент:
Для регистрации файловых объектов для определенного источника необходимо нажать кнопкой мыши на соответствующую строчку, на экране откроется форма свойств выбранного источника данных. Выбрав в панели навигации слева «Файловые системы» и нажав кнопку «Создать» → «Добавить ФС» (справа в окне), можно зарегистрировать новые файловые объекты, чтобы впоследствии запускать для них задачи на резервное копирование и восстановление данных:
Для регистрации нового файлового объекта открывается форма, в которой отображается выбранный источник данных:
Убедитесь, что выбран правильный источник, файловые объекты которого требуется добавить для резервного копирования, и нажмите кнопку «Далее».
Откроется интерфейс удалённого просмотра файловых систем источника, где можно интерактивно или вручную выбрать каталог для регистрации в качестве объекта резервирования. Например, можно выбрать каталог etc, как показано ниже:
Нажмите кнопки «Далее» → «Создать», и в списке зарегистрированных объектов на источнике появится новая запись:
После завершения предыдущего шага зарегистрированный файловый объект становится доступным для выполнения задач резервного копирования и последующего восстановления данных.
При запуске резервного копирования (вручную или по расписанию, связанному с политикой резервного копирования) доступны следующие режимы:
- Блочный Полный (IFULL) – полное резервное копирование с поддержкой создания синтетической полной копии при повторном резервном копировании (инкрементальность на уровне измененных блоков файлов);
- Файловый Полный (WFULL) – полное резервное копирование с поддержкой создания синтетической полной копии при повторном резервном копировании (инкрементальность на уровне измененных файлов);
- Принудительный Полный (FFULL) – полное резервное копирование без поддержки создания синтетической полной копии при повторном резервном копировании (поддерживает режим автоматического деления на потоки).
¶ 4.1.1. Поддержка внешних каталогов
По-умолчанию, в качестве файлового объекта резервного копирования можно указать определенный каталог в единичном экземпляре. При этом для одновременного резервного копирования нескольких каталогов необходимо привязать соответствующие файловые объекты к политике резервного копирования. Однако, в этом случае каждый из файловых объектов будет резервироваться в отдельном задании и для каждого такого задания будут выполнятся pre/post скрипты, назначенные для каждого объекта в отдельности. Для возможности резервного копирования группы каталогов (файловых объектов) одновременно, в одном задании и с единым набором pre/post скриптов, необходимо определить свойство "Внешние каталоги" для корневого файлового объекта.
Например, для резервирования корневого (опорного или родительского) файлового объекта (/pgdata/0652/data/) и одновременного резервирования каталогов (/pgtable1,/pgtable2,/pgtable3), создайте файловый объект (/pgdata/0652/data/) и в форме редактирования его свойств - поле "Внешние каталоги" добавьте дочерние каталоги (/pgtable1,/pgtable2,/pgtable3) - используйте клавишу Enter после добавления каждой записи:
Дополнительно, вы можете определить значения для "Директории восстановления" - этот параметр задает корневой каталог восстановления по-умолчанию. Например, для каталогов из примера выше, при восстановлении со значением (/restore) для "Директории восстановления" все файловые объекты восстановятся внутри каталога (/restore):
- /restore/pgdata/0652/data/
- /restore/pgtable1
- /restore/pgtable2
- /restore/pgtable3
Проверьте правильное назначение внешних каталогов в списке файловых объектов (столбец "Внешние каталоги"):
¶ 4.2. Регистрация объектов для резервного копирования БД Postgresql
Данные под управлением СУБД Postgresql, подлежащие резервному копированию, доступны на следующих типах источников: физический сервер, виртуальная машина, контейнер. После установки Агента Системы (см. «Руководство по установке. Программа для ЭВМ "Береста"») на любой из перечисленных источников он автоматически регистрируется в Системе.
Система поддерживает следующие типы СУБД:
- Postgresql Vanilla 11-17;
- PostgresPro Standard 11-17;
- PostgresPro Enterprise 11-17;
- Proxima DB – всех версий;
- Platform V Pangolin 6.4.x, 6.5.x (включая версии cve);
- Любой дистрибутив на базе Postgresql Vanilla 11-17.
Агент для СУБД на базе Postgresql поставляется в двух версиях - v2 и v3. Версия v3 базируется на библиотеке libpgprobackup от компании Postgres Pro и поддерживает дополнительные режимы резервного копирования и восстановления данных (BASE, DIRECT, PRO). Данные режимы в первую очередь поддерживаются для экземпляров на базе PostgresPro Standard и Enterprise. Для ванильных версий Postgresql доступны режимы BASE и DIRECT начиная с Postgresql 14.
Статус регистрации источника можно проверить в веб-консоли, перейдя в раздел «Конфигурация» → «Источники данных». В открывшейся таблице отображается перечень всех агентов, зарегистрированных в домене Системы, с указанием их статуса и имени сервера (виртуальной машины или контейнера), на котором установлен Агент.
Если для источника требуется резервное копирование как файлов, так и баз данных, он регистрируется в Системе единожды. Различие заключается только в типах объектов (файлы или БД), выбираемых для резервирования.
¶ 4.2.1. Предварительные настройки Postgresql
Для того, чтобы Агент, установленный на сервере БД смог подключиться к экземпляру БД необходимо выполнить следующие настройки в файле pg_hba.conf:
local all all trust или peer или md5 или scram256sha
local replication all trust или peer или md5 или scram256sha
Данные настройки позволяют подключение к БД только для локальных процессов сервера через Unix Domain socket. Для методов trust и peer подключение осуществляется без пароля.
Выберите нужный источник в таблице и перейдите в раздел «Базы данных» в левой панели навигации. В открывшейся форме отобразятся все базы данных поддерживаемого типа, доступные для резервного копирования на выбранном источнике.
В отличие от файловых данных, объекты типа Базы Данных регистрируются в Системе автоматически с автоопределением типа, версии СУБД, домашнего каталога с данными, режима архивации и т.п. (Индивидуально для каждого типа СУБД).
Если вы видите запись об объекте БД на выбранном источнике, новый зарегистрированный объект с типом «База данных» становится доступным для запуска задач на резервное копирование и последующего восстановления данных.
¶ 4.2.2. Переключение режима передачи WAL-файлов для СУБД на базе Postgresql
После автоматической регистрации объекта БД с типом Postgresql (в зависимости от редакции Postgresql тип может отличаться), резервное копирование БД и передача WAL-файлов возможна в режиме STREAM — при запуске ручного или автоматического резервирования, опция «Режим Archive» отключена
Для того, чтобы настроить возможность передачи WAL-файлов в режиме Archive, а также активировать функцию «непрерывного архивирования WAL» необходимо выполнить следующие настройки в файле конфигурации postgresql.conf или postgresql.auto.conf (в зависимости от того, какой используется для приоритетных настроек):
- archive_mode (выставить on или always);
(требует перезапуска БД)
- archive_command (выставить значение
/opt/beresta/brst-agent/bin/wal_archive_command -p %p -f %f )
(достаточно выполнить reload конфигурации);
Для проверки передачи WAL файлов используйте SQL-запрос
select from pg_switch_wal();
Список заархивированных WAL доступен в меню «Информация по Резервным Копиям»:
¶ 4.2.3. Поддержка инкрементального бэкапа для СУБД на базе Postgresql
Для инкрементального резервного копирования БД на базе Postgresql поддерживаются три режима инкрементального резервирования:
- PAGE (требует archive_mode и archive_command и доступен только при передаче WAL в режиме Archive для опорного полного бэкапа. Если для полного бэкапа WAL передается в режиме STREAM, автоматически переключается в режим DELTA);
- DELTA (доступен для любого режима передачи WAL);
- PTRACK (для Postgresql 11 и других, где не поддерживается PTRACK 2.0, автоматически переключается в режим DELTA).
Выбор режима доступен при запуске задания на резервное копирование:
¶ 4.2.4. Поддержка многопоточности и компрессии для СУБД на базе Postgresql
Многопотоковая передача данных поддерживается как для резервного копирования, так и для восстановления данных Postgresql. По умолчанию используется автоматический метод расчета кол-ва потоков (количество потоков равно количеству CPU ядер на клиенте). Для резервного копирования и восстановления данных можно принудительно выбрать кол-во потоков, с которым будет осуществляться передача данных.
Агент для Postgresql поддерживает (для PostgresPro Enterprise) резервное копирование табличных пространств с включенной компрессией (CFS). CFS поддерживается при использовании агента v2, а таже при использовании агента v3 в режиме Pro. Дополнительных настроек для поддержки этого функционала выполнять не требуется.
Дополнительно, агент поддерживает следующие алгоритмы компресии на хосте СУБД при формировании потоков резервного копирования: ZLIB,LZ4,ZSTD. Алгоритмы LZ4 и ZSTD являются наиболее оптимальными.
¶ 4.3. Регистрация объектов для резервного копирования виртуальных машин
Резервное копирование виртуальных машин реализовано за счет функционала, встроенного в Силовой сервер. Поддерживаются следующие типы платформ виртуализации:
- oVirt (любая версия);
- zVirt (версии 3.x и 4.x);
- Ред Виртуализация (версии 7.x);
- ROSA (версия 3.0);
- RHEV (версии 3.x, 4.x);
- VK Cloud (OpenStack);
- OpenStack (версии Victoria и выше);
- SpaceVM (версии 6.5.x и выше);
- Базис.DynamiX Enterprise (версии 4.х и выше).
Для подключения к платформе виртуализации и автоматической регистрации объектов резервного копирования (виртуальных машин) необходимо добавить «безагентский» источник данных. Резервное копирование и восстановление объектов инфраструктуры виртуализации не требует установки промежуточных агентов или создания служебных виртуальных машин. Перейдите в панели навигации на вкладку «Конфигурация» → «Источники данных» → «Безагентские» → кнопка «Добавить источник»:
Выберите тип виртуализации, для которого вы настраиваете резервное копирование, укажите произвольное наименование и нажмите «Далее».
¶ 4.3.1. Регистрация источника oVirt
Для систем виртуализации на базе oVirt:
- Укажите имя хоста, на котором доступен Engine сервис zVirt, RedVirt, oVirt и т.п.;
- Укажите имя пользователя платформы виртуализации с административными правами, а также порт (443).
Сертификат с сервера управления виртуализацией подгружается автоматически.
¶ 4.3.2. Регистрация источника Openstack
Для систем виртуализации на базе OpenStack:
- Укажите имя хоста и порт (обычно 5000), на котором доступен сервис Keystone;
- Задайте способ подключения (для SECURE_HTTPS потребуется загрузить корневой сертификат OpenStack инсталляции);
- Укажите тип аутентификации (пользователем или токеном). Указанный пользователь или токен должен обладать правами администратора;
- Загрузите корневой сертификат (если выбран способ подключения SECURE_HTTPS) и заполните остальные поля (имя проекта, имя домена проекта и прочее). В форме приводятся значения, которые обычно используются по умолчанию;
- Завершите добавление безагентского источника. Для систем виртуализации на базе OpenStack необходимо дополнительно настроить сервис Cinder Backup на гипервизорах или выделенных хостах;
- Также необходимо настроить Cinder Backup Driver (NFS – если планируете перемещать резервные копии на долгосрочное хранения, S3 – если планируете хранить резервные копии только на S3). Для настройки Cinder Backup и Cinder Backup Driver используйте документацию от поставщика OpenStack.
¶ 4.3.3. Регистрация источника Базис.Dynamix
Для систем виртуализации на базе Базис.DynamiX необходимо получить:
- Учетные данные (Client ID, Client key) пользователя Dynamix с доступом уровня "Администратор" к объектам account Dynamix, в которых созданы ВМ, подлежащие резервному копированию, и, в которых планируется восстановление ВМ;
- Цепочку сертификатов корневого центра сертификации, удостоверяющего сертифкат интерфейса портала Dynamix;
- Цепочку сертификатов корневого центра сертификации, удостоверяющего сертифкат интерфейса портала Dynamix SSO.
В визарде добавления источника указываются Client ID и Client key учетной записи Dynamix:
Затем указываются URL портала Dynamix и тело цепочки сертификатов корневого центра сертификации:
Затем указываются URL портала Dynamix SSO и тело цепочки сертификатов корневого центра сертификации:
После добавления источника нужного типа он становится доступен в списке Безагентских источников.
¶ 4.3.4. Обнаружение ВМ
Обнаружение виртуальных машин и обновление информации о них выполняются автоматически через заданные интервалы времени. Обнаружение осуществляется только ВМ ассоциированных с объектами account Dynamix, к которым настроен доступ пользователя Dynamix, указанного в источнике Бересты.
В процессе обнаружения:
- в базу данных «Бересты» добавляются новые виртуальные машины (ВМ);
- удаляются ВМ, которые отсутствуют в системе виртуализации и не имеют резервных копий;
- актуализируются данные о существующих ВМ;
- обновляется членство ВМ в динамических политиках резервного копирования.
Процесс обнаружения также можно запустить вручную для добавленного источника. Для этого:
- Перейдите на страницу списка источников: «Источники данных» - «Безагентские»;
- Наведите курсор на строку нужного источника;
- Нажмите кнопку с иконкой лупы:
Нажмите кнопку «Обнаружить ВМ», чтобы запустить обнаружение виртуальных машин. В случае успешного подключения и достаточного кол-ва прав в списке объектов появится список виртуальных машин:
Результаты выполнения задания обнаружения ВМ отображаются на странице служебных заданий. Чтобы открыть страницу:
- Перейдите в раздел «Монитор заданий»;
- Нажмите кнопку с иконкой шестерёнки:
Если в результате обнаружения ВМ выяснилось, что ВМ отсуствует в системе виртуализации, но ее резервные копии остались, то атрибут ВМ is_autodiscovered в базе Бересты изменяется с значения True на значение False.
Любая из обнаруженных виртуальных машин автоматически становится доступной для запуска задач на резервное копирование и последующее восстановления данных (кнопки «РК» и «ВД»). Вы можете изменить свойства (срок хранения, хранилище РК, кол-во потоков и др.).
Для этого выберите «троеточие» справа каждого объекта и запустите форму «Редактировать».
Внимание! Перед запуском резервного копирования ВМ oVirt на Силовой сервер (серверы) необходимо установить пакет qemu-utils (поставляется в комплекте дистрибутива Силового сервера).
Нажмите «РК» для ручного запуска задания на резервное копирования. Доступны следующие режимы:
- VMFULL – Полное резервное копирование;
- VMINCREMENTAL – Инкрементальное резервное копирование на базе измененных блоков.
Для постановки на регулярное резервное копирование необходимо создать политику и расписание, привязанные к нужным объектам резервного копирования.
¶ 4.4. Резервное копирование и восстановление данных CommuniGate PRO
Резервное копирование системы корпоративной почты на базе CommuniGate Pro реализовано за счет возможностей потокового файлового резервного копирования и восстановления данных встроенного в Агент Системы Береста. Поддерживаемые версии:
- CommuniGate Pro 6.x.x;
Использование потокового файлового режима для резервного копирования и восстановления данных CommuniGate Pro обеспечивает следующие преимущества:
- Поддержка любых типов устройств хранения резервных копий (файловые, потоковые, работающие через SDK. Например: Tatlin.Backup и EMC DataDomain);
- Автоматическое распределение данных по потокам (обеспечивает существенный прирост производительности при копировании данных почтовых ящиков пользователей);
- Многопоточное резервное копирование и восстановление данных;
- Возможность динамического развертывания Агентов Бересты для динамических кластеров CommuniGate Pro.
¶ 4.4.1. Настройка резервного копирования CommuniGate Pro
Для настройки резервного копирования выполните следующие шаги:
-
Установите Агента на backend-серверы с помошью пакетного установщика локально или с помощью Ansible Playbook удаленно;
-
Убедитесь, что установленные Агенты активны в списке Источники данных - Агентские;
-
Для каждого Агента перейдите в контекст Агента (значок "лупа") и добавьте следующие файловые объекты:
- Settings (настройки модулей и компонентов ядра) – по-умолч. /var/CommuniGate/Settings/
- SystemLogs (журналы сервера CommuniGate Pro) - по-умолч. /var/CommuniGate/SystemLogs/
- Directory (файлы центрального Справочника) - по-умолч. /var/CommuniGate/Directory/
- Accounts (данные пользователей) - по-умолч. /var/CommuniGate/Accounts/
- Domains (данные доменов) - по-умолч. /var/CommuniGate/Domains/
-
Создайте новую политику, добавьте в её объекты все файловые объекты, созданные ранее. В качестве хранилища резервных копий выберите любое доступное устройство хранения;
-
Создайте новое расписание, укажите тип копии "Потоковый Полный (авто-деление) на потоки". Привяжите расписание к созданной политике;
-
Сделайте проверку, выполнив "Ручной запуск" для созданной политики.
Внимание! Для получения консистентной копии данных воспользуйтесь командными сценариями Системы Береста. В качестве pre-exec (до резервного копирования) сценария могут использоваться API вызовы для "Приостановки" домена/-ов и CLI вызовы KillAccountSessions для отключения пользователей перед резервированием объекта Accounts. Проконсультируйтесь с производителем ПО CommuniGate Pro для реализации правильных (актуальных) вызовов для вашей версии ПО CommuniGate Pro.
¶ 4.4.2. Восстановление данных CommuniGate Pro
Полное или гранулярное восстановление данных CommuniGate Pro не отличается от восстановления из потоковой файловой резервной копии (см. п.7.3). Гранулярное восстановление позволяет восстановить любой отдельный файл данных пользователей (Accounts) или других объектов CommuniGate Pro, доступных в резервной копии в виде отдельных файлов.
¶ 4.5. Командные сценарии до и после резервного копирования
Система поддерживает централизованное управление, хранение и использование командных сценариев для всех компонентов при выполнении заданий на резервное копирование данных. Создание сценариев осуществляется централизованно через консоль управления → панель «Конфигурация» → «Настройки» → «Командные сценарии».
Нажмите кнопку «Создать», чтобы добавить пользовательский сценарий. Сценарий можно привязать к любому зарегистрированному объекту данных и запускать до или после операции резервного копирования.
Система поддерживает назначение сценариев как на агентах, так и на силовых серверах. Для одного задания резервного копирования выполняется следующая цепочка сценариев:
- Старт задания на резервное копирование;
- Запуск пре-скрипта на Силовом сервере;
- Запуск пре-сценария на Агенте;
- Передача данных;
- Запуск пост-сценария на Агенте;
- Запуск пост -сценария на Силовом сервере.
Назначение исполнения для сценариев осуществляется при редактировании свойства объекта на шагах Агент (Сценарии), Силовой сервер (Сценарии).
Для любого типа сценариев Система предоставляет возможность использования встроенных переменных (названия переменных с примерами значений ниже):
BRST_UPLOAD_BYTES=165481
BRST_STORAGE_PATH=storage40gb
BRST_JOB_INDEX=1
BRST_AGENT_ID=16
BRST_EDITION=1
BRST_VALIDATE_MODE=ON
BRST_BACKUP_DIR_PATH=storage40gbpgagent_016S8NLRF
BRST_USER=postgres
BRST_PGDATA_PATH=rootBeresta_APIdbpgdata-local
BRST_DOWNLOAD_BYTES=475818083
BRST_BACKUP_MODE=FULL
BRST_RES=
BRST_BACKUP_DIR=S8NLRF
BRST_PG_DB_LIST=analyzer, empty, postgres, template0, template1
BRST_DBVERSION=14
BRST_DBPORT=5432
BRST_JOB_NAME=Задание 5c7c9bec-5852-4205-8973-dd7dff4e91fa agent_01601
BRST_PREV_BACKUP_DIR=1707591179
BRST_UPLOAD_BYTES=109
BRST_STORAGE_PATH=rootBeresta_APIstorage
BRST_JOB_INDEX=1
BRST_AGENT_ID=16
BRST_BACKUP_DIR_PATH=rootBeresta_APIstoragefsagent_016_etc_1707591408
BRST_DOWNLOAD_BYTES=850
BRST_EXCLUDE_LIST=
BRST_BACKUP_DIR=1707591408
BRST_INCLUDE_LIST=.conf
BRST_SOURCE_DIR=etc
¶ 4.6. Резервное копирование Platform V Pangolin с помощью Platform V CopyWala
Система поддерживает резервное копирование и восстановление данных СУБД Platform V Pangolin c использованием ПО Platform V CopyWala.
¶ 4.6.1. Предварительные настройки
Для настройки резервного копирования Platform V Pangolin с помощью Platform V CopyWala, выполните следующие предварительные настройки (следуйте инструкциям производителя - АО "СберТех" для установки и настройки компонент Platform V CopyWala):
- Установите клиентскую часть Platform V CopyWala (достаточно пакета copywala-xxx.rpm) на все серверы СУБД Pangolin, данные которых подлежат резервному копированию;
- Установите сервисы хранения Platform V CopyWala (достаточно пакета storage-service-xxx.rpm) на все Силовые серверы Бересты, которые планируется использовать для хранения резервных копий СУБД Pangolin;
- Настройте клиентскую часть Platform V CopyWala на подключение к резервируемой СУБД Pangolin, заполнив секцию target_db: в файле конфигурации /etc/pbr/copywala.yaml. Дополнительно, создайте и пропишите пути к файлам сертификатов для работы с TLS, если необходимо. Пример файла конфигурации ниже (перед началом использования, параметр backup_destination_uri: должен быть прописан в нотации как в примере - "s2://произвольное_имя_хоста:порт" по умолчанию используйте порт 29509 в настройках клиентской части и сервиса хранения Platform V CopyWala). При запуске заданий со стороны ПО "Береста" параметры клиентской части CopyWala динамически изменяются:
backup_destination_uri: s2://vm-sblx-93.example.corp:29509
log:
compress_backups: false
max_age: 90
max_backups: 10
max_size: 100
path: /var/log/pbr/copywala.log
use_local_time: true
restore_data_path: local-fs:///pgdata/06/data
restore_instance_name: test_0199582f-463f-71a6-a431-8ef8afc0d2ad
retrier:
delay_period: 1s
retries: 5
timeout: 10s
target_db:
database: postgres
host: localhost
password: *******
port: 5436
query_params: search_path=public
user: cwuser
wal_destination_uri: s2://vm-sblx-93.example.corp:29509
- Убедитесь, что клиентская часть Platform V CopyWala получает информацию о резервируемой СУБД Pangolin, выполнив команду:
copywala db info
Пример корректного вывода:
dbuser: cwuser
dbname: postgres
version: "15.5"
db_list: analyzer, pbra, postgres, template0, template1
edition: Platform V Pangolin 6.4.2
system_id: "7542451671015303412"
instance_name: test_0199582f-463f-71a6-a431-8ef8afc0d2ad
replication: standalone
replication_partners: ""
home: /pgdata/0642cve2/data
archive_mode: "off"
archive_command: (disabled)
user: root
status: stopped
size: 9454651317
port: 5436
- Настройте предварительно развернутые сервисы хранения Platform V CopyWala, заполнив секцию storage_path: (в качестве пути укажите точку монтирования предварительно созданного устройства хранения в ПО "Береста" с типами "FS или ZFS или NFS или TBFS или TBOOST", добавьте права на чтения и запись на точку монтирования storage_path: для пользователя, из под которого запущен сервис хранения CopyWala) в файле конфигурации /etc/pbr/storage-service.yaml. Дополнительно создайте и пропишите пути к файлам сертификатов для работы с TLS, если необходимо и заполните секцию grpс - используйте порт 29509 на всех сервисах хранения по-умолчанию;
- Для проверки запустите вручную команду copywala create-backup при корректно заполненном параметре backup_destination_uri:. Команда должна отрабатывать без ошибок;
- Если сервис агента ПО "Береста" будет запущен на серверах СУБД Pangolin не из под пользователя root, пропишите в файле sudoers разрешение для этого пользователя на запуск бинарного файла copywala.
¶ 4.6.2. Авто-обнаружение экземпляров Platform V Pangolin
В интеграции с Platform V CopyWala, агенты ПО "Береста" автоматически обнаруживают экземпляры Pangolin, которые настроены в качестве target_db: в конфигурации клиентской части Platform V CopyWala. Для проверки корректного обнаружения экземпляров Pangolin, в консоли Береста, перейдите в "Источники данных" → "Агентские" → перейдите в контекста агента, нажав на иконку "лупа". Выберите раздел "Базы данных" слева в панели навигации. Для экземпляра, к которому подключена клиентская часть Platform V CopyWala должны быть корректно заполнены значения всех полей: редакцию, порт, объем и т.д.:
Обратите внимание на значение полей "Хранилище" и "Инструмент РК". В качестве хранилища в свойстве объекта необходимо задать любое, предварительно созданное устройство с типом FS, ZFS или POOL. При запуске заданий РК Pangolin, система по заданным алгоритмам для типа POOL будет динамически выбирать наилучший Силовой сервер (сервис хранения Platform V CopyWala) и отправлять на него резервные копии Pangolin. При корректной работе клиентской части Platform V CopyWala, значение поля "Инструмент РК" автоматически переключится в "cw":
¶ 4.6.3. Запуск заданий на резервное копирование и восстановление данных
Запуск заданий резервного копирования и восстановления данных при интеграции с Platform V CopyWala не отличается от работы с другими типами объектов:
- Воспользуйтесь ручным запуском при помощи кнопок "РК" и "ВД" на уровне объекта;
- Для автоматического запуска добавьте объекты в политику статично или динамически, используйте возможности REST API для автоматизации запуска заданий на резервного копирования и восстановления данных;
- При запуске заданий на восстановление данных используйте опцию "восстановить данные не удостоверенные цифровой подписью".
Если в исходной БД Pangolin были созданы внешние табличные пространства (tablespaces), восстановление из резервной копии по умолчанию восстанавливает исходный маппинг табличных пространств на каталоги их размещения (восстановление в этом случае возможно, если исходные каталоги пустые и имеют разрешение на создание в них файлов от имени пользователя postgres — по умолчанию).
Если вам необходимо восстановить всю структуру данных — pgdata и каталоги размещения табличных пространств — в новый каталог, в свойствах объекта БД Pangolin в консоли «Бересты» назначьте «Каталог восстановления по умолчанию», например: /png_restore_path (владельцем этого каталога должен быть пользователь postgres). Запустите мастер восстановления, и система автоматически восстановит содержимое резервной копии в этот каталог с сохранением структуры папок для табличных пространств. Эти папки создаются автоматически при данном варианте восстановления.
¶ 4.6.4. Хранение метаданных о резервных копиях
После каждого задания на резервное копирование Pangolin c использованием Platform V CopyWala, система сохраняет метаданные для возможности восстановления из любой созданной резервной копии. Информация о резервных копиях (метаданные) доступны стандартным образом — через меню "Каталог РК" или по кнопке "ВД". Среди прочих полей, в метаданных системы сохраняются значения "Archive URI" и "Instance name":
¶ 4.7 Резервное копирование и восстановление ВМ Базис.Dynamix
ПО Береста осуществляет резервное копирование и восстановление конфигурации ВМ Dynamix и данных на дисках ВМ.
¶ 4.7.1. Резервное копирование ВМ Базис.Dynamix
Для резервного копирования ВМ Dynamix необходимо на гипервизорах, где может работать ВМ, настроить доступ к дисковому пространству для хранения резервных копий. Для этого на каждом гипервизоре необходимо монтировать файловую систему и создать объект конфигурации Dynamix BackupPath, связанный с ней. Перед началом резервного копирования ВМ ПО Береста проверяет наличие настроенных объектов Dynamix BackupPath.
Значение Dynamix BackupPath, идентификаторы дисков, подлежащих или не подлежащих РК, глубину хранения копий ВМ можно задать в свойствах ВМ. Для этого на странице со списком ВМ выберите чекбоксы напротив одной или нескольких ВМ и нажмите кнопку "Редактировать":
На странице визарда "Параметры" в окне "Путь резервной копии" введите название ранее сконфигурированного параметра Dynamix BackupPath. В окне "Глубина хранения в днях" введите значение глубины хранения и нажмите кнопку "Далее":
На странице визарда "Включения" в окнах "Включения" или "Исключения" введите идентификаторы дисков, которые необходимо включить в РК или исключить из РК, и нажмите кнопку "Далее":
На странице визарда "Обновление" нажмите кнопку "Обновить":
В результате для ВМ будут настроены выбранные параметры и они будут использованны для резервного копирования.
Резервное копирование ВМ осуществляется периодически согласно настройкам политики и расписаний.
Для начала резервного копирования вручную необходимо на странице со списком ВМ, доступной при выборе пунктов меню навигации: «Источники данных» → «Безагентские» → Ранее созданный источник данных Базис.DynamiX → «Виртуальные машины», нажмите на кнопку «РК» на строке соответсвующей ВМ:
На первой странице визарда восстановления нажмите кнопку "Далее":
На странице визарда "Параметры" (если параметр BackupPath уже задан для ВМ и не нужно его изменять) нажмите кнопку "Далее". Если параметр нужно задать или переопределить, то в окне "Путь резервной копии" введите название ранее сконфигурированного параметра Dynamix BackupPath и нажмите кнопку "Далее":
На странице визарда "Включения" (если параметр включения или исключения уже заданы для ВМ и не нужно их изменять) нажмите кнопку "Далее". Если параметр нужно задать или переопределить, то в окнах "Включения" или "Исключения" введите идентификаторы дисков, которые необходимо включить в РК или исключить из РК, и нажмите кнопку "Далее":
На странице визарда "Подтверждение" нажмите кнопку "Подтвердить":
Результат выполнения задания резервного копирования можно посмотреть, нажав на пункт, соответствующий заданию в списке заданий:
¶ 4.7.2. Восстановление ВМ Базис.Dynamix
В ПО «Береста» реализовано восстановление данных на диски ВМ и полное восстановление виртуальных машин.
Логика процесса восстановления:
- Система проверяет наличие ВМ в системе виртуализации;
- Если ВМ существует — данные восстанавливаются на её диски;
- Если ВМ не найдена — создаётся новая виртуальная машина с параметрами, идентичными исходной ВМ на момент создания резервной копии:
- создается новая ВМ,
- создаются новые диски м подключаются к ВМ,
- восстанавливаются данные на новые диски,
- создаются интерфесы типов VINS и EXTNET,
- восстанавливается членство в Floating IP group,
- восстанавливатются Port Forwarding Rules,
- восстанавливаются Antiaffinity и Affinity Rules,
- восстанавливаются процессоры GPU,
- восстанавливаются PCI устройства,
- настраивается очередность устройств загрузки,
- настраивается привязка к гипервизору,
- настраиваются tag.
Восстановленная ВМ не включается.
В случае создания новой ВМ в результате восстановления, новая ВМ не будет включена в политики резервного копирования, в которые была включена оригинальная ВМ.
Перед восстановлением существующей ВМ:
- производится попытка выключения ВМ;
- проверяется наличие дисков, указанные в информации о резервной копии.
Для начала восстановления необходимо на странице со списком РК, доступной при выборе пунктов меню навигации: «Источники данных» → «Безагентские» → Ранее созданный источник данных Базис.DynamiX → «Каталог РК», нажать на кнопку «ВД» на строке соостветсвующей РК:
В визарде настроек восстановления нажать кнопку восстановить:
Результат выполнения задания по восстановления можно посмотреть, нажав на пункт, соответствующий заданию в списке заданий:
¶ 4.8. Резервное копирование и восстановление БД Oracle
Резервное копирование данных под управлением СУБД Oracle реализуется посредством установки Агента Системы на хост БД. Процесс резервного копирования и восстановления данных БД Oracle реализован несколькими способами в зависимости от типа размещения данных в БД Oracle (ФС, ASM).
В любом случае, передача потоков резервного копирования и восстановления данных выполняется в нескольких параллельных потоках - многопоточно с автоматическим делением исходных данных на потоки, что существенно сокращает время резервного копирования и восстановления данных.
Выделение дополнительных дисковых ресурсов для промежуточных дампов не требуется.
Система поддерживает следующие редакции и версии СУБД Oracle (поддерживаются конфигурации с размещением данных БД на файловой системе и под управлением Oracle ASM):
- Oracle Standard Edition 8.x, 9.x, 10x, 11x, 12x, 19x, 21x;
- Oracle Enterprise Edition 8.x, 9.x, 10x, 11x, 12x, 19x, 21x;
¶ 4.8.1. Настройка резервного копирования БД Oracle
Для настройки резервного копирования БД Oracle, с файлами БД, размещенными на файловой системе (не ASM или RAW) выполните следующие шаги:
- Установите Агента Cистемы на сервер БД Oracle с помошью пакетного установщика локально или с помощью Ansible Playbook удаленно;
- Убедитесь, что установленный Агент активен в списке Источники данных - Агентские;
- В меню "Настройки" -> "Командные сценарии" отредактируйте готовые шаблоны сценариев "pre-oracle-begin-backup" и "post-oracle-end-backup" указав переменные ORACLE_* для резервируемого экземпляра Oracle c параметрами подключения к БД;
- Для установленного Агента перейдите в контекст Агента (значок "лупа") и добавьте следующие файловые объекты:
- Каталог, в котором размещены файлы БД Oracle – например /oradata;
- В свойствах добавленного файлового объекта (/oradata) отредактируйте (по "троеточию" на объекте) поле "Внешние каталоги", добавив туда каталоги, в которых хранятся архивные Редо-логи, файлы конфигурации и дампы контрольных файлов;
- Дополнительно, в свойствах добавленного файлового объекта (/oradata) отредактируйте сценарии (Агент) выбрав в качестве сценария "Перед РК" - "pre-oracle-begin-backup" и "После РК" - "post-oracle-end-backup";
- Создайте новую политику, добавьте в её объекты все файловые объекты, созданные ранее. В качестве хранилища резервных копий выберите любое доступное устройство хранения;
- Создайте новое расписание, укажите тип копии "Потоковый Полный (авто-деление) на потоки". Инкрементальное резервное копирование в этом случае возможно за счет отдельной политики для резервного копирования архивных Редо-логов. Привяжите расписание к созданной политике;
- Сделайте проверку, выполнив "Ручной запуск" для созданной политики.
Для настройки резервного копирования БД Oracle с данными под управлением Oracle ASM, выполните следующие шаги:
- Установите Агента Cистемы на сервер БД Oracle с помошью пакетного установщика локально или с помощью Ansible Playbook удаленно;
- Убедитесь, что установленный Агент активен в списке Источники данных - Агентские;
- В меню "Настройки" -> "Командные сценарии" отредактируйте готовые шаблоны сценариев "pre-oracle-rman-backup" и "post-oracle-rman-backup" указав переменные ORACLE_* для резервируемого экземпляра Oracle c параметрами подключения к БД и RMAN;
- Дополнительно, отредактируйте готовые шаблоны сценариев "pre-pp-export-nfs" и "post-pp-export-nfs";
- Для установленного Агента перейдите в контекст Агента (значок "лупа") и добавьте следующие файловые объекты:
- Каталог, в котором размещен временный дамп резервной копии БД Oracle (переменная $BRST_BUFFER_PATH в сценарии "pre-oracle-rman-backup") – например /backup;
- В свойствах добавленного файлового объекта (/oradata) отредактируйте (по "троеточию" на объекте) поле "Внешние каталоги", добавив туда каталоги, в которых хранятся архивные Редо-логи, файлы конфигурации и дампы контрольных файлов;
- Дополнительно, в свойствах добавленного файлового объекта (/backup) отредактируйте сценарии (Агент) выбрав в качестве сценария "Перед РК" - "pre-oracle-begin-backup" и "После РК" - "post-oracle-end-backup" и сценарии (Силовой сервер) "Перед РК" - "pre-pp-export-nfs" и "После РК" - "post-pp-export-nfs";
- Создайте новую политику, добавьте в её объекты все файловые объекты, созданные ранее. В качестве хранилища резервных копий выберите любое доступное устройство хранения c типами FS,ZFS,TBOOST,TBFS;
- Создайте новое расписание, укажите тип копии "Потоковый Полный (авто-деление) на потоки". Инкрементальное резервное копирование в этом случае возможно за счет отдельной политики для резервного копирования архивных Редо-логов. Привяжите расписание к созданной политике;
- Сделайте проверку, выполнив "Ручной запуск" для созданной политики.
¶ 4.8.2. Восстановление данных БД Oracle
Полное или гранулярное восстановление данных БД Oracle не отличается от восстановления из потоковой файловой резервной копии (см. п.7.3). Гранулярное восстановление позволяет восстановить любой отдельный файл данных или других объектов БД Oracle, доступных в резервной копии в виде отдельных файлов. Для запуска экземпляра БД Oracle на восстановленных данных, обратитесь к администратору БД Oracle, процесс восстановления и запуска БД Oracle не отличается от стандартных методов восстановления из резервных копий.
¶ 4.9. Резервное копирование и восстановление БД MySQL
Резервное копирование данных под управлением СУБД MySQL реализуется посредством установки Агента Системы на хост БД. Ввиду незначительных объемов данных, обычно находящихся под управлением MySQL, специальный агент (интеграция) для РКиВД данного типа СУБД не требуется. Резервное копирование и восстановление поддерживается за счет потокового файлового копирования и восстановления данных с использованием готовых "пре/после" сценариев для обеспечения консистентности данных. Выделение дополнительных дисковых ресурсов для промежуточных дампов не требуется.
Система поддерживает следующие редакции и версии СУБД MySQL:
- MySQL 4.x и выше.
¶ 4.9.1. Настройка резервного копирования БД MySQL
Для настройки полного резервного копирования БД MySQL с помощью LVM-снэпшотов выполните следующие шаги:
- Установите Агента Cистемы на сервер БД MySQL с помошью пакетного установщика локально или с помощью Ansible Playbook удаленно;
- Убедитесь, что установленный Агент активен в списке Источники данных - Агентские;
- В меню "Настройки" -> "Командные сценарии" отредактируйте готовые шаблоны сценариев "pre-mysql-lvm-backup" и "post-mysql-lvm-backup" указав переменные для монтирования LVM-снэпшота и подключения к БД;
- Для установленного Агента перейдите в контекст Агента (значок "лупа") и добавьте следующие файловые объекты:
- Каталог, в котором монтируются данные LVM-снэпшота – например /mysqldata_snap_mount;
- В свойствах добавленного файлового объекта (/mysqldata_snap_mount) отредактируйте (по "троеточию" на объекте) поле "Внешние каталоги", добавив туда каталоги, в которых хранятся файлы конфигурации MySQL или другие данные, подлежащие резервному копированию вместе с файлами БД;
- Дополнительно, в свойствах добавленного файлового объекта (/mysqldata_snap_mount) отредактируйте сценарии (Агент) выбрав в качестве сценария "Перед РК" - "pre-mysql-lvm-backup" и "После РК" - "post-mysql-lvm-backup";
- Создайте новую политику, добавьте в её объекты все файловые объекты, созданные ранее. В качестве хранилища резервных копий выберите любое доступное устройство хранения;
- Создайте новое расписание, укажите тип копии "Потоковый Полный (авто-деление) на потоки". Привяжите расписание к созданной политике;
- Сделайте проверку, выполнив "Ручной запуск" для созданной политики.
Для настройки полного резервного копирования БД MySQL с помощью утилиты mysqldump выполните следующие шаги:
- Установите Агента Cистемы на сервер БД MySQL с помошью пакетного установщика локально или с помощью Ansible Playbook удаленно;
- Убедитесь, что установленный Агент активен в списке Источники данных - Агентские;
- В меню "Настройки" -> "Командные сценарии" отредактируйте готовые шаблоны сценариев "pre-mysql-dump-backup" и "post-mysql-dump-backup", указав переменные для каталога выгрузки дампа и подключения к БД;
- Дополнительно, отредактируйте готовые шаблоны сценариев "pre-pp-export-nfs" и "post-pp-export-nfs";
- Для установленного Агента перейдите в контекст Агента (значок "лупа") и добавьте следующие файловые объекты:
- Каталог, в который выгружается дамп БД – например /mysqldata_dump;
- В свойствах добавленного файлового объекта (/mysqldata_dump) отредактируйте (по "троеточию" на объекте) поле "Внешние каталоги", добавив туда каталоги, в которых хранятся файлы конфигурации MySQL или другие данные, подлежащие резервному копированию вместе с файлами БД;
- Дополнительно, в свойствах добавленного файлового объекта (/mysqldata_dump) отредактируйте сценарии (Агент) выбрав в качестве сценария "Перед РК" - "pre-mysql-dump-backup" и "После РК" - "post-mysql-dump-backup" и сценарии (Силовой сервер) "Перед РК" - "pre-pp-export-nfs" и "После РК" - "post-pp-export-nfs";
- Создайте новую политику, добавьте в её объекты все файловые объекты, созданные ранее. В качестве хранилища резервных копий выберите любое доступное устройство хранения c типами FS,ZFS,TBOOST,TBFS;
- Создайте новое расписание, укажите тип копии "Потоковый Полный (авто-деление) на потоки". Привяжите расписание к созданной политике;
- Сделайте проверку, выполнив "Ручной запуск" для созданной политики.
Для настройки инкрементально резервного копирования БД MySQL с использованием бинарных логов MySQL (Binary Log) дополнительно выполните следующие шаги:
- Убедитесь что binlogs включены в конфигурации Mysql: напр. в фале /etc/my.cnf.d/mysql-server.cnf необходимо добавить запись: log_bin=/var/log/mysql/binlog и перезапустить экземпляр MySQL. Проверка активации логов: mysql -uroot -pxxxxxx -e "SHOW VARIABLES LIKE 'log_bin%';"
- Создайте новый командный сценарий для дампа бинарных логов, включите в сценарий следующую запись (пример): mysqldump -uroot -ppassword- --all-databases --flush-logs --delete-source-logs --single-transaction | gzip > /var/$(date +%d-%m-%Y_%H-%M-%S)-full.gz
- Добавьте файловый объект для регулярного резервного копирования дампа бинарных логов.
¶ 4.9.2. Восстановление данных БД MySQL
Полное или гранулярное восстановление данных БД MySQL из копии на базе LVM-снэпшота не отличается от восстановления из потоковой файловой резервной копии (см. п.7.3). Гранулярное восстановление позволяет восстановить любой отдельный файл данных или других объектов БД MySQL, доступных в резервной копии в виде отдельных файлов.
Для восстановления данных MySQL из резервной копии,выполненной с помощью mysqldump, после восстановления SQL-дампа на хост БД используете команду: mysql -uroot -pxxxxx < backup.sql
Для восстановления бинарных логов из резервной копии, после восстановления и распаковки дампа бинарных на хост БД используете команду: mysqlbinlog mysql-bin.000040 mysql-bin.000059 mysql-bin.000123 | sudo mysql -u root или mysqlbinlog $(ls) | sudo mysql -u root. После завершения импорта необходимо рестартовать MySQL
Для запуска экземпляра БД MySQL на восстановленных данных, обратитесь к администратору БД MySQL, процесс восстановления и запуска БД MySQL не отличается от стандартных методов восстановления из резервных копий.
¶ 4.10. Резервное копирование и восстановление ALD Pro
Резервное копирование данных cлужбы каталогов на базе ALD Pro реализуется посредством установки Агента Системы на хосты ALD Pro. Специальный агент (интеграция) для РКиВД данного типа Приложения не требуется. Резервное копирование и восстановление поддерживается за счет потокового файлового копирования и восстановления данных с использованием готовых "пре/после" сценариев для обеспечения консистентности данных. Процедуры резервного копирования и восстановления данных соответствуют рекомендуемым производителем ПО ALD Pro (см. https://www.aldpro.ru/professional/ALD_Pro_Module_10/ALD_Pro_backup.html)
Система поддерживает следующие редакции и версии ALD Pro:
- ALD Pro 2.x, 3.x и выше.
¶ 4.10.1. Настройка резервного копирования ALD Pro
Для настройки полного резервного копирования ALD Pro выполните следующие шаги:
- Установите Агента Cистемы на серверы ALD Pro с помошью пакетного установщика локально или с помощью Ansible Playbook удаленно;
- Убедитесь, что установленный Агент активен в списке Источники данных - Агентские;
- В меню "Настройки" -> "Командные сценарии" отредактируйте готовые шаблоны сценариев "aldpro-pre" и "aldpro-post" (предоставляются с дистрибутивом ПО "Береста"), указав переменные для каталога выгрузки дампа;
- Для установленного Агента перейдите в контекст Агента (значок "лупа") и добавьте следующие файловые объекты:
- Каталог, в который выгружается дамп ALD Pro – например /var/backups/aldpro/;
- Дополнительно, в свойствах добавленного файлового объекта (/var/backups/aldpro/) отредактируйте сценарии (Агент) выбрав в качестве сценария "Перед РК" - "aldpro-pre" и "После РК" - "aldpro-post"
- Создайте новую политику, добавьте в её объекты все файловые объекты, созданные ранее. В качестве хранилища резервных копий выберите любое доступное устройство хранения c типами FS,ZFS,TBOOST,TBFS;
- Создайте новое расписание, укажите тип копии "Потоковый Полный (авто-деление) на потоки". Привяжите расписание к созданной политике;
- Сделайте проверку, выполнив "Ручной запуск" для созданной политики.
Внимание: для резервного копирования с реплик контроллера ALD Pro можно воспользоваться доступным в ПО "Береста" функционалом автоматического определения роли узлов кластера Приложений. Для этого в панели "Источники данных" -> "Кластеризованные" необходимо добавить кластер (тип "FS), а также задать правила определения текущей роли узлов кластера.
¶ 4.10.2. Восстановление данных ALD Pro
Полное или гранулярное восстановление данных ALD Pro не отличается от восстановления из потоковой файловой резервной копии (см. п.7.3). Гранулярное восстановление позволяет восстановить любой отдельный файл данных или других объектов ALD Pro, доступных в резервной копии в виде отдельных файлов.
После восстановления данных из резервной копии, воспользуйтесь инструкцией на сайте производителя ПО ALD Pro для восстановления работы Приложений из восстановленных данных (см. https://www.aldpro.ru/professional/ALD_Pro_Module_10/ALD_Pro_backup.html)