Здравствуйте, Хабровчане! Сегодня возвращаемся к ещё одной доброночной теме - бэкапу отечественной виртуализации. Возвращаемся с конкретным решением вопроса, в частности – представляем российскую систему резервного копирования RuBackup, которая интегрирована с российской системой виртуализации АИСТ.
В этой статье разберем общую архитектуру Rubackup и конкретные сценарии применения для гипервизора АИСТ. А еще более глубоко копнём эту тему на нашем очередном вебинаре «ОколоИТ», гостем которого будет основатель и генеральный директор компании RuBackup Андрей Кузнецов. Зарегистрироваться на вебинар можно по ссылке.
Архитектура и ключевые термины
Система резервного копирования (СРК) RuBackup интегрирована с системой виртуализацией АИСТ с помощью нашего RestFul API. С помощью него также с АИСТом интегрированы и другие партнерские решения, такие как VDI Termidesk, СЗИ Аккорд, а также opensource мониторинг Grafana.
Теперь давайте разберемся с архитектурой и ключевыми понятиями СРК RuBackup.
Серверная группировка RuBackup состоит из основного сервера РК, необязательного резервного сервера РК и, возможно, дополнительных медиасерверов. В простейшем случае медиасервером является основной сервер резервного копирования (а также резервный сервер, при наличии). Хранение данных резервных копий (архивов) реализовано в виде хранилищ (storage). Каждое хранилище входит в определённый пул. Пул с точки зрения RuBackup - это логическое объединение однотипных устройств хранения резервных копий. Каждый пул принадлежит определённому медиасерверу. Таким образом, получаем логическую цепочку: медиасервер > Пул > Хранилище
Метаданные резервных копий хранятся в репозитории. Непосредственно резервные копии располагаются в хранилищах резервных копий, которые ассоциированы с пулами хранения резервных копий. Хранилища бывают следующих типов: файловая система, ленточная библиотека, блочное устройство и облако. Блочное устройство является хранилищем для дедуплицированных резервных копий.
Клиент системы резервного копирования – это фоновый процесс (сервис) в операционной системе, на которой установлено клиентское ПО RuBackup для выполнения резервного копирования. В случае с Aerodisk АИСТ клиент RuBackup может устанавливаться на один или на несколько гипервизоров. Клиенты могут быть объединены в группы клиентов, а если необходимо, чтобы задачи резервного копирования выполнялись в инфраструктурном кластере даже при выключении одного из клиентов, то группу можно сделать кластерной. В этом случае задача будет выполнена на первом доступном клиенте, входящим в группу.
На программном уровне сервером RuBackup называется также фоновый процесс (сервис) на сервере РК. Все действия СРК реализованы в виде задач, которые создаются в очереди задач. Периодические задания резервного копирования и восстановления данных реализованы в виде правил, которые входят в глобальное расписание резервного копирования. Множественные действия над группами ресурсов реализованы в виде стратегий, которые создают задачи резервного копирования в соответствии с расписаниями для всех ресурсов и клиентов, которые их касаются.
Система уведомлений RuBackup использует пользователей и группы пользователей RuBackup для уведомления о событиях системы резервного копирования.
В итоге в случае системы виртуализации АИСТ имеем следующие роли:
Сервер РК, который может быть в виде виртуальной машины АИСТ или внешним сервером. В простом случае сервер СРК один, в серьезном случае – это кластер из двух серверов СРК. В случае отказа основного сервера, резервный сервер поддержит функционал основного сервера RuBackup, а клиенты системы резервного копирования автоматически подключатся к резервному серверу. После восстановления функционирования основного сервера клиенты подключатся обратно к основному серверу. Взаимодействие между системой резервного копирования и её клиентами обеспечивает основной сервер резервного копирования RuBackup, либо резервный сервер, если он функционирует в режиме замещения основного сервера.
Медиасервер – это роль, которую могут выполнять как серверы РК (и основной, и резервный), так и выделенные серверы (ВМ или физические). Медиасервер предназначен для хранения резервных копий, получения их от клиентов и передачи клиентам файлов резервных копий по запросу. При увеличении количества клиентов, а также при увеличении количества ресурсов, на которых предполагается хранить резервные копии, могут возникнуть задачи распределения нагрузки. В этом случае в серверную группировку могут быть добавлены дополнительные медиасерверы, с помощью которых можно перераспределить задачи резервного копирования на несколько серверов РК или построить иерархическую систему хранения резервных копий. В RuBackup 1.9 доступен функционал динамических групп пулов, который обеспечивает автоматическое распределение нагрузки между разными пулами и медиа-серверами.
Клиент RuBackup, установленный на гипервизоре. Клиент RuBackup, который предустановлен в любом дистрибутиве АИСТа, начиная с версии 3.6.0, и включен по умолчанию. Для более старых версий клиент можно получить в виде штатного обновления АИСТа до указанной версии. С помощью клиента гипервизора выполняются задачи по безагентному бэкапу виртуальных машин АИСТ. Клиент обслуживает все виртуальные машины комплекса независимо от того, на каком гипервизоре ВМ физически функционирует.
Клиент гостевой ОС. Тот же клиент Rubackup, но в его задачи входит классическое резервное копирование данных и приложений изнутри гостевой ОС, когда это необходимо. Устанавливается вручную внутри ОС виртуальной машины.
Визуально настоящая конструкция выглядит следующим образом.
![Архитектура СРК RuBackup Архитектура СРК RuBackup](https://habrastorage.org/getpro/habr/upload_files/6b1/fa4/22c/6b1fa422cbd333c59d569349e6cbfbe4.png)
Функциональность
Функциональность СРК RuBackup можно смело причислять к Enterprise-уровню. Уже сейчас (версия 1.9) ПО поддерживает следующие функции:
Полное, инкрементальное и дифференциальное резервное копирование.
Поддержка безагентных бэкапов ВМ систем виртуализации Брест, АИСТ, Proxmox, OpenNebula, KVM.
Поддержка популярных ОС Linux (Astra Linux, Alt Linux, Rosa, RedOS, Oracle Linux, Ubuntu и др.).
Поддержка СУБД Oracle, MySQL, MariaDB, Redis, PostgreSQL 9.6, 10, 11, 12, Jatoba, PostgresPro.
Поддержка хранилищ на базе внешних СХД, ленточных библиотек и облачного хранилища S3.
Поддержка отказоустойчивости и удаленной непрерывной репликации.
Управление устройствами хранения резервных копий, возможность распределения резервных копий по разным устройствам хранения в зависимости от политики резервного копирования.
Поточная глобальная дедупликация и сжатие резервных копий.
Автоматическая верификация сделанных резервных копий (размер файлов, md5 сумма, электронная подпись).
Стратегии резервного копирования, позволяющие выполнять автоматические групповые операции над клиентами СРК.
Консолидированная отчетность.
Ролевая модель доступа к СРК.
Автоматическая балансировка создаваемых задач между медиа-серверами.
Автоматическое перемещение резервных копий на другие носители и удаление устаревших копий.
Поддержка графического управления и управления из командной строки.
Это далеко не весь функционал, а только сама важная, на наш взгляд, его часть. Подробнее обо всех возможностях СРК можно узнать на сайте разработчика.
Примеры использования
Установка компонентов системы СРК
Как было сказано ранее, модули резервного копирования включены в дистрибутив АИСТ и идут уже предустановленные. Модули в системе находятся по пути: /opt/rubackup. Настройки авторизации к API хранятся в файле /opt/rubackup/etc/rb_module_aerodisk-vm.conf, и этот файл нужно изменить на всех узлах кластера. Структура файла следующая:
url http://you.url/
username admin
password secret_pass
timeout 2
Изменения делаются через адаптированный CLI.
Если настройки сделаны верно, то при старте агента в лог файле /opt/rubackup/log/RuBackup.log появятся записи следующего вида:
![](https://habrastorage.org/getpro/habr/upload_files/85e/ded/46e/85eded46e4a5ea6130644ca4ab0c57e1.png)
Установка самого сервера РК в виде ВМ или на физический сервер происходит так же, как и для любой другой инфраструктуры. И эта информация может быть легко найдена на официальном сайте RuBackup. Также на этом этапе необходимо настроить места хранения резервных копий.
После установки сервера управления резервным копированием необходимо добавить и авторизовать в него клиентов РК, в качестве которых будут выступать гипервизоры – АИСТ. На примере ниже так добавлен и уже авторизован один гипервизор с именем NODE-0001.
![](https://habrastorage.org/getpro/habr/upload_files/ec7/6f9/69e/ec76f969e1b59673c508aae3c8b34907.png)
Безагентное резервное копирование
Для того, чтобы выполнить безагентное резервное копирование ВМ, нужно сделать следующее:
Выберите клиента и добавьте правило резервного копирования. В качестве клиента выступает гипервизор.
Выберите тип ресурса: “Aerodisk AIST”.
![](https://habrastorage.org/getpro/habr/upload_files/2a9/62b/e70/2a962be702a35e7843b52549cb57cc57.png)
Выберите ресурс (в нашем случае ВМ), нажав кнопку «Выбрать».
![](https://habrastorage.org/getpro/habr/upload_files/663/22a/f42/66322af42fe3b4233c7fa340560d6897.png)
Установите настройки правила: название правила, пул хранения данных, максимальный объём для резервных копий правила (в ГБ), тип резервного копирования, расписание резервного копирования, срок хранения и необязательный временной промежуток проверки резервной копии.
Далее можно выполнить дополнительные настройки этого задания, в том числе выполнение pre и post скриптов. Настроенное резервное задание будет выполняться по заданному расписанию или же его можно вызвать в любой момент вручную в случае необходимости.
Безагентное восстановление
Для того, чтобы выполнить безагентное восстановление ВМ, нужно сделать следующее:
Выбрать ресурс, который необходимо восстановить, кликнуть по нему правой кнопкой мыши и выбрать «Восстановить».
![](https://habrastorage.org/getpro/habr/upload_files/615/96a/969/61596a969130f06e381482a998c0d525.png)
В окне централизованного восстановления можно увидеть основные параметры резервной копии и, если это применимо, определить место восстановления резервной копии. В случае восстановления виртуальной машины из резервной копии будет выполнена проверка наличия в среде виртуализации виртуальной машины с таким же именем. Если такой виртуальной машины нет, то будет произведено восстановление с оригинальным именем. Если виртуальная машина с таким именем уже есть, то к имени виртуальной машины будет добавлен цифровой постфикс.
![](https://habrastorage.org/getpro/habr/upload_files/95f/72c/521/95f72c52162cc786f45ed2f48f7107ec.png)
Проверить ход выполнения восстановления резервной копии можно в окне “Главная очередь задач” (начало восстановления).
![](https://habrastorage.org/getpro/habr/upload_files/a48/ee0/bdf/a48ee0bdf427449d83dc14c894f97498.png)
Проверить ход выполнения восстановления резервной копии можно в окне “Главная очередь задач” (завершение восстановления).
![](https://habrastorage.org/getpro/habr/upload_files/436/e89/f7f/436e89f7f9aea72603352d20f8372abd.png)
Бэкап и восстановление настраиваются аналогично, независимо от того, где хранится сама резервная копия.
Для резервного копирования на ленточную библиотеку нужно просто выбрать пул хранения резервных копий, который принадлежит ленточной библиотеке. Далее система все сделает сама: загрузит необходимый картридж в магнитофон, запишет резервную копию или несколько резервных копий, выгрузит картридж обратно в слот ленточной библиотеки.
В случае необходимости хранить резервную копию в облаке S3 также необходимо выбрать соответствующий пул хранения резервных копий, который ассоциирован с облаком S3.
Резервное копирование с агентом
В заключение давайте рассмотрим сценарий резервного копирования с помощью агента для СУБД Postgre. Вот так выглядит клиент GUI RBC (RuBackup Client), в нем можно увидеть список резервных копий для СУБД PostgreSQL.
![](https://habrastorage.org/getpro/habr/upload_files/8ec/3c7/d4a/8ec3c7d4a7ae4a5a9680cfd0ad9d05dd.png)
Данный пример демонстрирует применение универсального модуля для резервного копирования СУБД PostgreSQL версий новее 9.6. Модуль pg_superb рассчитан на то, что PostgreSQL располагается на томах LVM. Это позволяет использовать функционал моментальных снимков LVM, обеспечивает возможность делать base backup, в качестве инкрементальных резервных копий забирать архивные WAL. Все это дает возможность выполнять эффективное быстрое резервное копирование данной СУБД и восстановление на нужную точку во времени или на нужную транзакцию. Кроме того, данная схема обеспечивает использование глобальной дедупликации. Среди отечественных систем резервного копирования такого функционала нет ни у кого, кроме RuBackup.
С помощью RBC клиент может сделать запрос администратору СРК на добавление новых правил глобального расписания:
![](https://habrastorage.org/getpro/habr/upload_files/430/1a8/1a7/4301a81a7bbe705aa0ad2fc3677bed6f.png)
Запрос будет добавлен на ревью и администратор СРК может его увидеть через центральную консоль управления RBM.
![](https://habrastorage.org/getpro/habr/upload_files/7a2/0b0/a42/7a20b0a42383b8c7c4682fbb9bd75920.png)
![](https://habrastorage.org/getpro/habr/upload_files/ce4/86f/72e/ce486f72ee5b52be4372eb2ac1084613.png)
В том случае, если администратор СРК разрешил клиенту использовать локальное расписание и управлять резервным копированием самостоятельно, можно создать нужные правила самому:
![](https://habrastorage.org/getpro/habr/upload_files/041/d45/8c0/041d458c0744ef862a57c4a76f82b371.png)
Модель поставки и техническая поддержка
СРК Rubackup поставляется по OEM модели в составе дистрибутива ПО АИСТ или ПАК АЭРОДИСК Machine-V. Есть два варианта: бесплатный и платный. Бесплатная версия Rubackup не имеет никаких функциональных ограничений, ограничен только объем резервных копий в 1 ТБ. Поэтому ничего не мешает попробовать его функциональность на небольших объемах данных.
Платные лицензии Rubackup для АИСТ поставляются АЭРОДИСК-ом с отдельными продуктовыми номерами. Техническая поддержка Rubackup-а в рамках функционирования АИСТ-а (если приобретена OEM-лицензия АЭРОДИСК) также осуществляет АЭРОДИСК как работает тех. поддержка см. предыдущий пост.
Заключение
Итак, мы разобрали как работает российская СРК Rubackup в целом и для системы виртуализации АИСТ в частности. Чтобы погрузиться глубже, мы делаем следующую серию нашего вебинара «ОколоИТ», который пройдет 31 мая 2022 в 14 00. Зарегистрироваться на вебинар можно по ссылке.
Всем спасибо, ждем тяжелых вопросов и радикальной критики.