Привет всем, кто заботится о данных и не собирается их терять. Сегодня мы рассмотрим тему бэкапа виртуальных машин (ВМ) на платформе виртуализации Basis.DynamiX (далее — DynamiX). Для этого будем использовать систему резервного копирования (СРК) RuBackup.

В статье расскажу, как установить, настроить и использовать RuBackup для создания резервных копий (РК) ВМ на платформе DynamiX, а также разберу некоторые сложности, которые могут возникнуть в процессе работы.

В первую очередь статья будет полезна для администраторов платформы виртуализации DynamiX, которым необходимо настроить в системе резервное копирование. Также статья подойдет для новичков, которые хотят разобраться, как в целом работает RuBackup.

Не забудьте про ссылки в конце статьи, они будут полезны!

Настройка RuBackup для работы с системой виртуализации DynamiX

Начнем с обзора основной архитектуры RuBackup и возможностей, которые эта система предоставляет для резервного копирования виртуальных машин в DynamiX (версии 3.8.8 - 4.0.0). В этой же части предлагаю обсудить некоторые технические особенности процесса.

Как работает RuBackup

Для понимания вопроса рассмотрим общую архитектуру RuBackup вне контекста работы с DynamiX.

В упрощенном виде RuBackup работает по следующей схеме: на виртуальной (или физической) машине устанавливаются основной сервер (медиасервер), клиент и необходимые пользователю модули (в нашем случае — rb_module_dynamix).

Сервер взаимодействует с клиентами, координирует задания СРК и хранит резервные копии на доступных ему ресурсах: файловых системах, блочных устройствах, картриджах ленточных библиотек и облачных сервисах.

Клиент отвечает за резервное копирование ресурсов (например, ВМ DynamiX) и передачу их на сервер в хранилища.

Хранение данных резервных копий (архивов) реализовано в виде хранилищ, где каждое хранилище входит в определенный пул. Пул — это логическое объединение однотипных устройств хранения резервных копий. Каждый пул принадлежит определенному медиасерверу.

При нормальной работе сервер и клиент RuBackup запускаются на хосте как фоновые процессы (демоны).

RuBackup поддерживает полное, инкрементальное и дифференциальное резервное копирование.

Полное резервное копирование — это создание резервной копии всех данных из исходного набора, независимо от того, изменялись ли данные с момента выполнения последней полной резервной копии.

Инкрементальное резервное копирование сохраняет только данные, измененные со времени выполнения предыдущей инкрементальной резервной копии, а при отсутствии таковой — со времени выполнения последней полной резервной копии.

Дифференциальное (разностное) резервное копирование сохраняет только данные, измененные со времени выполнения предыдущего полного резервного копирования.

На рисунке 1 представлена архитектура RuBackup.

Более подробное описание ключевых понятий, архитектуры и в целом работы RuBackup можно найти в технической документации [1].

Установка RuBackup и модуля DynamiX

Прежде всего стоит подчеркнуть философию команды RuBackup: мы стремимся сделать процесс резервного копирования доступным и удобным для всех. Именно поэтому было принято решение предоставить пробную лицензию, которая позволяет бесплатно резервировать данные объемом до 1 ТБ. Это дает возможность пользователям познакомиться с продуктом и оценить его возможности на практике. Попробовать RuBackup можно по ссылке [2].

Наиболее подробно процесс установки и первичной настройки RuBackup описан тут [3], процесс установки модуля DynamiX — тут [4]. Там же можно найти информацию о поддерживаемых операционных системах.

Для работы RuBackup серверу требуется PostgreSQL с определёнными настройками, а также дополнительные пакеты (например, mailutils, libcurl и т. д.), корректная настройка файла “.bashrc” и открытие нужных портов. Подробная информация о поддерживаемых версиях PostgreSQL и список необходимых пакетов представлен тут [2].

Для установки необходимо получить шесть пакетов:

• rubackup-common_<version>_amd64_signed.deb — общие библиотеки RuBackup;

• rubackup-client_<version>_amd64_signed.deb — клиент RuBackup;

• rubackup-dynamix_<version>_amd64_signed.deb — модуль для работы с DynamiX;

• rubackup-server_<version>_amd64_signed.deb — сервер RuBackup;

• rubackup-common-gui_<version>_amd64_signed.deb — общие графические библиотеки RuBackup;

• rubackup-rbm_<version>_amd64_signed.deb — графический менеджер RuBackup (RBM).

Примечание: хотя RuBackup можно использовать без графического интерфейса, далее демонстрация функционала будет показана на примере использования графического менеджера RBM.

После установки пакетов с помощью утилиты «dpkg» необходимо запустить утилиту «rb_init» для настройки RuBackup. Без этой настройки система не будет работать, поэтому важно выполнить её корректно. В руководстве по установке описан простой сценарий установки — «Все в одном», когда сервер и клиент RuBackup находятся на одном хосте.

Начиная с версии 2.1, возможна работа с RuBackup через REST API, что также детально описано в руководстве по установке [3] и администрированию [1].

Настройка модуля DynamiX

Почти каждый модуль в RuBackup требует дополнительной настройки, и модуль для DynamiX не исключение. Для корректной работы нужно заполнить конфигурационный файл rb_module_dynamix.config, который появляется в каталоге /opt/rubackup/etc после установки пакета rubackup-dynamix_<version>_amd64_signed.deb. Подробнее о параметрах модуля DynamiX описано тут [4].

Основные параметры модуля:

• url — WEB URL DynamiX (он же REST API URL);

• login_url — URL для авторизации внутри DynamiX;

• client_id — «ID Приложения» из login_url;

• client_secret — «API Ключ» из login_url;

• hypervisor_backup_path — путь дисков для бэкапа на гипервизоре DynamiX;

• local_backup_path — путь дисков для бэкапа на RuBackup-клиенте;

• backup_disk_timeout, restore_disk_timeout — тайм-ауты бэкапа и восстановления дисков в минутах;

• allow_work_with_incompatible_versions — параметр yes/no для попытки работы с неподдерживаемыми версиями DynamiX.

Чтобы получить значения client_id и client_secret, нужно авторизоваться на login_url (например, https://sso-<dynamix>.ru) и создать ключ доступа. На рисунке 2 представлен интерфейс портала администратора DynamiX.

Здесь показаныполя «ID Приложения» для поля login_url и «API Ключ» для client_secret. Важно, чтобы пользователь, создающий ключи, имел права администратора на платформе DynamiX.

Теперь рассмотрим более детально параметры «hypervisor_backup_path» и «local_backup_path». Клиент RuBackup не располагается на гипервизорах DynamiX, поэтому не имеет прямого доступа к дискам виртуальных машин. Для бэкапа используется NFS-директория, связывающая гипервизоры DynamiX с хостом, на котором работает клиент RuBackup. Это показано на рисунке 3.

«local_backup_path» — это директория на клиенте RuBackup, которая с помощью NFS соединена с директориями «hypervisor_backup_path» на гипервизорах. Пути к этим директориям нужно указать в конфигурационном файле rb_module_dynamix.config. Если гипервизоров несколько, они также должны быть связаны через NFS.

На NFS‑директории должен быть настроен анонимный доступ с полными правами на каталог назначения. В противном случае DynamiX не сможет сохранить диски ВМ в эту директорию, а RuBackup — создать их резервные копии.

Размер NFS‑директории должен соответствовать объему одновременно резервируемых и восстанавливаемых данных. Например, если размер директории составляет 100 ГБ, а одновременно запущены две задачи резервного копирования двух ВМ с дисками по 80 ГБ, одна из задач завершится с ошибкой из-за нехватки места в директории (80 + 80 > 100).

В конфигурационном файле есть ряд обязательных и необязательных параметров. Необязательные параметры закомментированы. Пример заполненного файла приведен на рисунке 4.

Использование RuBackup для бэкапа DynamiX

Итак, настройка завершена. Теперь у нас есть виртуальная машина с установленным клиентом и сервером RuBackup. Клиент связан с гипервизором DynamiX через NFS. Запустим сервер и клиент RuBackup и посмотрим лог-файл "/opt/rubackup/log/RuBackup.log" (рисунок 5).

Если на этом этапе возникла ошибка и модуль недоступен, проверьте правильность настроек конфигурационного файла и убедитесь, что доступ к платформе DynamiX настроен корректно. Чтобы убедится, что модуль настроен корректно, запустите модуль с опцией "-t". После того как убедились, что проверка завершается успешно, необходимо перезапустить сервис клиента RuBackup.

Далее командой «rbm&» на сервере RuBackup откроем RBM, пройдем авторизацию и в окне «Объекты» увидим список клиентов. Нужно выбрать клиента, на который был установлен модуль DynamiX. Если выбрана самая простая настройка с клиентом и сервером на одном хосте, то будет доступен один клиент. На рисунке 6 изображен выбранный клиент.

Как видно, RuBackup поддерживает множество настроек и конфигураций. Сейчас сосредоточимся на простом резервном копировании виртуальной машины. Для этого найдем нужную ВМ в интерфейсе DynamiX, например ВМ, как на рисунке 7.

Для создания резервной копии этой ВМ выберите клиента «rb‑nfs» (имя клиента может быть другим) и нажмите на кнопку со стрелками над клиентом. Поле «Ресурс» заполните ID виртуальной машины. Это можно сделать через список, нажав на иконку с тремя точками справа от поля «Ресурс».

Как видно выше, в интерфейсе Срочного РК также можно выбрать множество различных настроек. Для настройки параметров бэкапа модуля необходимо нажать на иконку с тремя точками справа от поля «Тип ресурса».

Параметры «local_backup_path» и «hypervisor_backup_path» дублируют одноименные параметры из конфигурационного файла rb_module_dynamix.conf, но с условием: если для бэкапа заданы значения для данных параметров, то при выполнении задачи резервного копирования используются они, а не значения из конфигурационного файла. Если параметры не заданы (пусты), то используются значения из конфигурационного файла.

Запустим резервное копирование, нажав кнопку «Применить» в правом верхнем углу интерфейса Срочного РК (рисунок 8). После этого пойдет процесс бэкапа, и во вкладке «Объекты» появится задача.

После удачного завершения задачи на вкладке «Репозиторий» появится РК.

Как видно из рисунка 11, в репозитории резервная копия забэкапленной виртуальной машины имеет ID 46. ID ВМ 2110 отображено в столбце «Ресурс».

Для восстановления РК кликнем ПКМ по РК и нажмем кнопку «Восстановить», как показано на рисунке 12.

Далее откроется окно Централизованного восстановления РК. В нем необходимо указать «Каталог распаковки» и активировать параметр «Восстановить на целевом ресурсе».

В указанном каталоге должно быть 110% места от размера оригинальной ВМ, так как в этот каталог будут распаковываться диски ВМ, текстовые файлы конфигурации и служебная информация.

Активировать параметр «Восстановить на целевом ресурсе» необходимо, чтобы запустился процесс деплоя ВМ на платформу DynamiX. Если параметр будет не активирован, то РК ВМ распакуется в указанной директории. В ней будут находится диски ВМ и текстовый файл с конфигурацией.

Пример окна Централизованного восстановления РК с заполненными полями изображен на рисунке 13.

Далее нужно нажать кнопку «Применить» в правом верхнем углу — в поле «Объекты» отобразится новая задача с типом «Restore». Ждем завершения.

Через некоторое время задача перейдет в статус Done, и на платформе появится новая ВМ, восстановленная из резервной копии.

Как видно из рисунка 14, ВМ восстановилась как полноценная новая ВМ с новым именем (к оригинальному имени добавился префикс “_1”) и с новым ID на платформе. Далее ей можно пользоваться как оригинальной ВМ. Авторизоваться внутри ВМ можно с помощью данных учетной записи из забэкапленной ВМ.

Параметры восстановления модуля DynamiX

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

В процессе восстановления в окне «Централизованное восстановление» после нажатия на иконку с тремя точками напротив поля «Параметры восстановления для модуля» откроется окно:

Если снять метку «Использовать настройки по умолчанию», то параметры можно изменить.

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

Параметры «local_backup_path» и «hypervisor_backup_path», как и в случае настроек параметров бэкапа, дублируют одноименные параметры из конфигурационного файла rb_module_dynamix.conf.

Заключение

В статье я рассмотрел, как использовать систему резервного копирования RuBackup, включая установку и настройку модуля DynamiX. Привел примеры выполнения резервного копирования виртуальной машины.

RuBackup также предлагает множество дополнительных функций и настроек для более детальной конфигурации. Например, можно использовать правила и стратегии резервного копирования, а также выполнять инкрементальные и дифференциальные бэкапы. Эти методы позволяют сократить размер резервных копий и повысить скорость резервного копирования.