Резервное копирование системы виртуализации Basis.DynamiX с помощью RuBackup

от автора

Привет всем, кто заботится о данных и не собирается их терять. Сегодня мы рассмотрим тему бэкапа виртуальных машин (ВМ) на платформе виртуализации 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.

Рисунок 1 — Архитектура 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.

Рисунок 2 — Портал администратора DynamiX

Рисунок 2 — Портал администратора DynamiX

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

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

Рисунок 3 — Связь между гипервизором DynamiX и клиентом RuBackup

Рисунок 3 — Связь между гипервизором DynamiX и клиентом RuBackup

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

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

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

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

Рисунок 4 — Пример заполненного данными конфига

Рисунок 4 — Пример заполненного данными конфига

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

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

Рисунок 5 — Лог при правильной настройке модуля

Рисунок 5 — Лог при правильной настройке модуля

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

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

Рисунок 6 — Клиент RuBackup с модулем DynamiX в интерфейсе RBM

Рисунок 6 — Клиент RuBackup с модулем DynamiX в интерфейсе RBM

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

Рисунок 7 — ВМ на платформе DynamiX

Рисунок 7 — ВМ на платформе DynamiX

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

Рисунок 8 — Интерфейс Срочного РК RuBackup

Рисунок 8 — Интерфейс Срочного РК RuBackup

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

Рисунок 9 — Специальные параметры бэкапа

Рисунок 9 — Специальные параметры бэкапа

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

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

Рисунок 10 — Выполненная задача на РК ВМ 2110

Рисунок 10 — Выполненная задача на РК ВМ 2110

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

Рисунок 11 — РК ВМ 2110 в репозитории

Рисунок 11 — РК ВМ 2110 в репозитории

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

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

Рисунок 12 — Начало восстановления РК

Рисунок 12 — Начало восстановления РК

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

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

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

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

Рисунок 13 — Окно Централизованного восстановления РК

Рисунок 13 — Окно Централизованного восстановления РК

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

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

Рисунок 14 — Восстановленная ВМ на платформе

Рисунок 14 — Восстановленная ВМ на платформе

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

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

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

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

Рисунок 15 — Параметры восстановления модуля

Рисунок 15 — Параметры восстановления модуля

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

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

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

Заключение

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

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

Полезные ссылки

  1. https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20sysadmin%20guide%202.2.0.pdf — Руководство для системного администратора по работе с RuBackup

  2. https://www.rubackup.ru/go/ — Пробная версия RuBackup с ограничением в 1 Тб

  3. https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20installation%20guide%202.2.0.pdf — Руководство по установке RuBackup

  4. https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20Dynamix%202.2.0.pdf — Руководство по работе с модулем РК DynamiX


ссылка на оригинал статьи https://habr.com/ru/articles/853554/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *