Привет, Хабр! Сегодня я хочу рассказать о том, как решаются вопросы резервного копирования в случаях работы с агентами или без них. В этом посте мы обсудим, какие преимущества даёт безагентная СРК (на примере Кибер Бэкап), поговорим о том, как она работает, а также рассмотрим ситуации, когда Илюха Курякин (см. «Агенты А.Н.К.Л.» ) всё-таки нужен.
![](https://habrastorage.org/getpro/habr/upload_files/afb/8e1/a5c/afb8e1a5caa27969f1e0848864ad7e20.jpeg)
Когда СРК защищает отдельно взятый компьютер, всё работает достаточно просто - специальная служба следит за изменениями вашей файловой системы и согласно заданным правилам создает резервные копии в выбранном месте. Резервные копии могут передаваться по локальной сети или в облако, сохраняются на внешние накопители, а также в сетевые СХД и программно-определяемые хранилища (например, в Кибер Инфраструктуру - и эта тема заслуживает отдельного поста), в том числе и по схеме 3-2-1. В подобных случаях никакого дополнительного агента не требуется — все компоненты устанавливаются вместе и работают как единый комплекс ПО.
Но при развертывании системы резервного копирования в организации, где необходимо защитить десятки (а может и сотни) физических и виртуальных серверов и рабочих станций, обычно на каждый защищаемый объект устанавливается агент, который отвечает за выполнение задач резервного копирования. Агенты могут работать в различных режимах, создавать локальные или сетевые резервные копии. Управление агентами происходит из центральной консоли Кибер Бэкап.
![](https://habrastorage.org/getpro/habr/upload_files/978/23d/77f/97823d77faa1deeec75bc76a0e962bbf.png)
Существуют различные механизмы развертывания агентов. Их можно устанавливать вручную на каждую машину (например, если количество серверов и рабочих станций невелико и практически не меняется) или через групповые политики — для этого можно настроить установку агентов на новые рабочие места, вычислительные узлы или серверы.
Схема без агентов
Когда речь идет о виртуальных машинах, можно поступить иначе. Напомним, что нам доступен гипервизор - управляющее ПО с которым мы можем общаться напрямую и поручать ему создание резервных копий и восстановление данных.
Это становится возможным за счет использования API гипервизоров, через которые сервер резервного копирования может передавать команды/задачи.
Простейшая схема такого резервного копирования выглядит следующим образом:
Кибер Бэкап посылает запрос на создание моментального снимка ВМ;
Гипервизор создает снапшот и передаёт путь к нему Кибер Бэкапу;
Кибер Бэкап перерабатывает получившийся файл в резервную копию формата Кибер Бэкап (или ее инкрементное обновление) и помещает в хранилище резервных копий.
Восстановление происходит по той же простой схеме. Например, если требуется восстановление ВМ целиком, выполняются следующие шаги:
Кибер Бэкап получает запрос на восстановление определённой ВМ от администратора;
Кибер Бэкап копирует образ ВМ на нужный носитель;
Кибер Бэкап даёт гипервизору команду создать новую ВМ из образа.
Конечно, в реальных сценариях при работе с гипервизором учитывается множество дополнительных факторов - проблемы доступа к различным видам хранилищ, механика перемещения данных и формирование инкрементной резервной копии, гарантии сохранения работоспособности ВМ во время сбора снапшотов и так далее.
![](https://habrastorage.org/getpro/habr/upload_files/6a7/a6b/2ac/6a7a6b2ace089e565f2bbc66bd3e8d07.png)
За все эти операции отвечает виртуальное устройство, которое устанавливается в кластере для взаимодействия с СРК. Такой “безагентный бэкап” (хотя формально, виртуальное устройство тоже можно называть “агентом”) решает широкий круг задач. Бэкап без агентов оказывается выгодным как с точки зрения распределения ресурсов, так и для пользователей ВМ и задач, которые на этих ВМ выполняются:
Работает быстрее - используется ресурс гипервизора, а не отдельно взятой виртуальной машины. Это позволяет достаточно быстро выполнить бэкап даже большого объема данных.
Не мешает пользователям - использует не только ресурсы ВМ, на которой в этот момент вы как раз пытаетесь запустить важную рабочую задачу, но и опирается на ресурсы сети, вычислительные возможности и хранилище кластера в целом.
Разгружает админов - не требуется настройка для каждой отдельно взятой виртуальной машины. Можно обеспечить защиту всего кластера с заданными параметрами RTO и RPO - для этого нужно просто установить единые политики резервного копирования и аварийного восстановления. Настройки будут актуальны как для существующих, так и для новых виртуальных машин.
Что же делать агенту?
После сказанного выше может показаться что агенты уже и не нужны. Но в случае с Кибер Бэкапом это не так. Все дело в том, что большинство развертываний нашего решения происходит на различных инфраструктурах, а агенты устанавливается на физические серверы и рабочие станции.
Помимо этого, агенты бывают полезны и в системах виртуализации. Агентный бэкап позволяет особенно тщательно защищать наиболее критичные ресурсы в кластере - об этом рассказывали на Хабре коллеги, которые активно используют Кибер Бэкап в своих проектах.,
Например, если у вас в виртуальной среде или облаке работает важная СУБД, к ней можно добавить агента, который будет обеспечивать резервное копирование ценных для бизнеса данных с минимальным разумным интервалом (обычно - это раз в 15 минут, хотя можно и меньше) и это никак не противоречит наличию безагентного бэкапа для кластера в целом или для какой-то его части.
Режимы с агентом (agent-based) и без него (agent-less) часто комбинируют, когда снимок ВМ выполняется один раз в день, а агент внутри машины создает резервную копию важных данных (например, данных приложений 1С) раз в час, причем в режиме файлов.
Для Кибер Бэкап такая схема является совершенно нормальной. Её настройка и управление происходит из той же самой консоли.
![](https://habrastorage.org/getpro/habr/upload_files/8e1/aef/6db/8e1aef6dbbe0abf8ab4099aacd0ad278.png)
При настройке плана резервного копирования вы можете выбрать схему защиты определенных виртуальных машин, резервные копии которых создаются без агентов, а также определить периодичность и метод сохранения данных поддерживаемых приложений, если внутри ВМ уже установлен агент Кибер Бэкап.
Поддержка гипервизоров
Если честно, нам, как разработчикам, было бы проще, если бы все использовали агентов - они работают одинаково на любых платформах как физических, так и виртуальных. Но именно безагентный бэкап (а точнее комбинация агентного и безагентного) позволяет создать сервис резервного копирования на уровне облака или системы виртуализации, а значит — лучше защитить данные разного типа.
Проекты интеграции с гипервизорами идут долго и требуют глубокого погружения. Мы уже рассказывали, с какими сложностями пришлось столкнуться при включении безагентного резервного копирования для платформы ECP Veil. Однако, судя по отзывам заказчиков, такая возможность оказывается действительно востребованной, и сейчас мы поддерживаем безагентный бэкап для таких гипервизоров, как Кибер Инфраструктура, ECP VeiL, zVirt, ROSA Virtualization, РЕД Виртуализация, Hyper-V, VMware, и ряда других.
Lasitus
было бы полезным описать те функции и доп настройки ОС и СУБД позволяющие сделать консистентный бэкап.