Привет всем, кто заботится о данных и не собирается их терять. Сегодня мы рассмотрим тему бэкапа виртуальных машин (ВМ) на платформе виртуализации 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 также предлагает множество дополнительных функций и настроек для более детальной конфигурации. Например, можно использовать правила и стратегии резервного копирования, а также выполнять инкрементальные и дифференциальные бэкапы. Эти методы позволяют сократить размер резервных копий и повысить скорость резервного копирования.
Полезные ссылки
-
https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20sysadmin%20guide%202.2.0.pdf — Руководство для системного администратора по работе с RuBackup
-
https://www.rubackup.ru/go/ — Пробная версия RuBackup с ограничением в 1 Тб
-
https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20installation%20guide%202.2.0.pdf — Руководство по установке RuBackup
-
https://www.rubackup.ru/documentation/techdoc/docs/RuBackup%20Dynamix%202.2.0.pdf — Руководство по работе с модулем РК DynamiX
ссылка на оригинал статьи https://habr.com/ru/articles/853554/
Добавить комментарий