Как в Кибер Бэкапе обеспечивается защита ВМ
Современные виртуализированные инфраструктуры предъявляют жесткие требования к скорости, надежности и автоматизации процессов защиты данных. Традиционные подходы к резервному копированию, основанные на ручных операциях, длительных окнах обслуживания и изолированных скриптах, уже не отвечают потребностям динамичных сред, где простои измеряются минутами, а объемы данных растут экспоненциально. В статье рассмотрим, как Кибер Бэкап может трансформировать защиту виртуальных рабочих нагрузок под управлением около 20 поддерживаемых систем виртуализации.
Каждый новый функциональный уровень поддержки помогает решать все более сложные архитектурные и операционные задачи: от безагентного резервного копирования и миграции V2V до поддержки метаданных (тегов), сокращения окна резервного копирования с помощью CBT и разрешения конфликтов с рабочими нагрузками через LAN-free, интеграции с аппаратными снимками отечественных СХД и технологии мгновенного восстановления. Разберем, как эти возможности сокращают RPO/RTO, снижают нагрузку на продуктивные среды и превращают резервную копию в готовый к немедленному использованию ИТ-актив.
Уровни защиты платформ виртуализации показаны в следующей таблице. Каждый следующий уровень дополняет набор функций предыдущих уровней (за исключением Hyper-V, одной из первых, наряду с VMware, систем виртуализации, для которой мы реализовали защиту на уровне гипервизора).

После того как мы обсудили подход к обеспечению резервного копирования и восстановления ВМ, рассмотрим каждый уровень более подробно. Начнем с современного стандарта резервного копирования — защиты ВМ на уровне гипервизора.
Уровень 1 — Безагентное резервное копирование
В «безагентном» режиме резервное копирование виртуальных машин осуществляется средствами платформы виртуализации, без установки агента в каждую защищаемую виртуальную машину. В этом режиме агент разворачивается в виде специализированной виртуальной машины, называемой «виртуальным устройством» (virtual appliance, VA). Такую виртуальную машину еще называют «агентом уровня гипервизора». К этой виртуальной машине средствами платформы виртуализации подключаются программные моментальные снимки защищаемых виртуальных машин. Из этих снимков агент защиты считывает данные и передает их в виде архива в хранилище резервных копий. Количество развернутых виртуальных устройств зависит от масштаба защищаемой платформы виртуализации.
К преимуществам такого режима можно отнести уже упомянутое отсутствие необходимости устанавливать агенты (и вообще что-нибудь) внутрь виртуальных машин, а также высокую скорость развертывания — всего один агент на хост гипервизора, отсутствие конкуренции за ресурсы с виртуальными машинами и высокую скорость резервного копирования. В состав Кибер Бэкапа входят виртуальные устройства для большинства востребованных на рынке платформ виртуализации — как отечественных, так и зарубежных. Поддерживаемые в этом режиме платформы виртуализации перечислены в таблице выше, а также в документации — см. колонку «Резервное копирование на уровне гипервизора (резервное копирование без агента)».
Параллельное резервное копирование и восстановление
Обратите внимание на возможности Кибер Бэкапа, которые ускоряют работу с виртуальными машинами. Речь идет о параллельном резервном копировании и восстановлении ВМ. Благодаря многозадачности агента он может одновременно выполнять несколько планов защиты при работе с одним типом данных или параллельно создавать резервные копии нескольких ВМ в рамках одного плана. Кроме того, один агент способен параллельно восстанавливать несколько виртуальных машин, что повышает общую скорость восстановления. При параллельных операциях важно контролировать использование вычислительных ресурсов агентом. При необходимости можно увеличить количество виртуальных процессоров и объем памяти для агента (виртуального устройства). Важно: недостаток вычислительных ресурсов может ухудшить работу резервного копирования и восстановления, вплоть до возникновения сбоев.
Миграция V2V
Кибер Бэкап обеспечивает полноценную поддержку всего спектра сценариев миграции рабочих нагрузок между физическими и виртуальными средами, включая классические модели: P2P (физический сервер на физический), P2V (физический на виртуальный), V2V (виртуальный на виртуальный) и V2P (виртуальный на физический). Благодаря такому набору возможностей ИТ-специалисты получают универсальный и гибкий инструментарий, позволяющий эффективно решать сложные инфраструктурные задачи — от плановой модернизации серверного парка и консолидации вычислительных ресурсов до бесшовного переноса сред в случае смены разработчика или перехода в гибридные облака.
Для нашего обзора интересен сценарий миграции Virtual to Virtual (V2V), который предлагает решение задачи переноса ВМ между хостами одной системы виртуализации или сопровождение перехода с зарубежной на импортонезависимую систему виртуализации. Вместо трудоемких и потенциально рискованных ручных операций система предлагает надежный алгоритм: сначала создается полная резервная копия виртуальной машины, фиксирующая не только пользовательские данные, но и все системные конфигурации, сетевые настройки и параметры приложений; затем этот образ разворачивается в целевой виртуальной среде, даже если она архитектурно отличается от исходной. Подобный подход гарантирует сохранность информации, минимизирует время простоя бизнес-сервисов и обеспечивает возможность мгновенного отката к предыдущему состоянию в случае возникновения несовместимостей, делая процесс перехода безопасным, предсказуемым и контролируемым на каждом этапе.

Полный список платформ виртуализации, поддерживающих миграцию V2V, приведен в документации.
Уровень 2 — Поддержка тегов виртуальных машин
Теги виртуальных машин представляют собой произвольные метаданные, организованные в формате «ключ-значение», которые могут назначаться виртуальным машинам в системе виртуализации для их логической классификации и управления жизненным циклом. В отличие от традиционных методов организации, таких как имена машин или вложенные папки, теги обладают высокой гибкостью: они не привязаны к физической или логической иерархии инфраструктуры, не ограничены уровнями вложенности и могут применяться к ресурсам массово, даже если те распределены по разным кластерам, гипервизорам или центрам обработки данных. Поддержка тегов реализована в большинстве современных платформ виртуализации и облачных провайдеров, что позволяет системным администраторам, инженерам по эксплуатации и системам автоматизации (оркестраторам, скриптам, платформам мониторинга) быстро фильтровать, группировать и применять политики к ресурсам, опираясь на их бизнес- и технические атрибуты, а не на физическое размещение или идентификаторы в каталоге. Это особенно ценно в крупных и динамичных средах, где виртуальные машины регулярно создаются, мигрируют, масштабируются или выводятся из эксплуатации.
Возможность резервного копирования и восстановления тегов снимает с администраторов необходимость вручную восстанавливать или заново прописывать эти метаданные после восстановления, клонирования или плановой миграции, радикально сокращая ресурсоемкость операции на ее завершающей стадии. При создании резервной копии теги сохраняются в составе конфигурационных метаданных машины, а при восстановлении автоматически применяются к новым экземплярам, обеспечивая полную преемственность атрибутов.
«Поддержка тегов» в нашей реализации также означает полную интеграцию с системой резервного копирования, позволяющей использовать теги как мощный инструмент управления вплоть до его автоматизации: на их основе можно выполнять поиск виртуальных машин, формировать статические или динамические группы (например, «все машины с тегом Критичность: Высокая»), а также автоматически назначать им соответствующие задания резервного копирования, расписания, политики хранения и уровни SLA. Расширенная поддержка тегов в Кибер Бэкапе существенно снижает трудозатраты и ресурсоемкость настройки заданий, минимизирует вероятность человеческих ошибок при конфигурации, а в ряде сценариев (массовое развертывание, аварийное восстановление, аудит соответствия регуляторным требованиям) полностью исключает ручной ввод данных. В результате инфраструктура становится более предсказуемой, управляемой и готовой к автоматизированному реагированию на изменения без потери исторической или операционной информации.
Уровень 3 — Поддержка CBT и LAN-free
С ростом объемов данных и требований к скорости восстановления традиционные схемы резервного копирования через LAN (Local Area Network) становятся узким местом. Нагрузка на сеть приводит к конфликтам трафика между операциями резервного копирования и рабочими приложениями, увеличивая окно резервного копирования. В ответ на эти вызовы возникли два ключевых подхода, которые мы рассмотрим ниже: CBT (Changed Block Tracking) и LAN-free (резервное копирование без передачи по локальной сети).
Поддержка CBT
CBT — это механизм на уровне гипервизора, который фиксирует, какие именно блоки виртуального диска были изменены с момента последнего резервного копирования. При создании первой резервной копии Кибер Бэкап формирует полную копию ВМ и активирует трекер, который начинает вести учет всех операций записи в виде битовой карты или журнала. Во время последующих сеансов система резервного копирования не сканирует весь диск, а запрашивает у гипервизора только список изменившихся блоков, считывает их и записывает в инкрементный файл. После успешного завершения процесса резервного копирования трекер сбрасывается, начиная отслеживать изменения заново для следующего цикла.

Технология отслеживания измененных блоков данных позволяет существенно сократить окно резервного копирования: изменения содержимого диска постоянно отслеживаются на уровне блоков. При запуске резервного копирования изменения могут быть незамедлительно сохранены в резервную копию. Технология эффективна при использовании инкрементных схем резервного копирования. Она полностью прозрачна для виртуальной машины, поддерживается большинством современных гипервизоров и стандартных решений для защиты данных, обеспечивая оптимальный баланс между скоростью, надежностью и эффективностью использования инфраструктуры.
Резервное копирование в режиме LAN-free
Резервное копирование виртуальных машин в режиме LAN‑free организует передачу данных напрямую от систем хранения к хранилищу резервных копий через выделенную сеть (как правило, SAN на базе Fibre Channel или iSCSI), полностью минуя производственную локальную сеть. В такой схеме прокси-сервер резервного копирования подключается к тому же массиву, что и гипервизоры, и считывает образы дисков ВМ напрямую с хранилища, после чего записывает их на целевой носитель.

Данный режим обладает следующими преимуществами:
- Снижение нагрузки на сеть. Данные передаются через выделенную сеть хранения (SAN), что освобождает пропускную способность локальной сети (LAN) для рабочих нагрузок
- Высокая скорость передачи. Использование высокоскоростных протоколов (например, Fibre Channel, iSCSI) в SAN позволяет быстрее передавать большие объемы данных по сравнению с традиционным Ethernet
- Улучшенная безопасность. Изоляция трафика резервного копирования в SAN снижает риск перехвата данных по сравнению с передачей через общую сеть
При корректном проектировании LAN‑free становится стандартом для средних и крупных виртуализированных сред, где производительность и изоляция потоков резервного копирования являются приоритетными требованиями.
Уровень 4 — Поддержка аппаратных моментальных снимков уровня СХД
В предыдущих версиях Кибер Бэкапа поддержка аппаратных моментальных снимков уровня СХД была реализована для зарубежного оборудования — NetApp SAN и Huawei OceanStor (Dorado), и только для платформы VMware. Тренд на импортозамещение серверного оборудования и платформ виртуализации, а также технологическое партнерство с компаниями YADRO и Orion soft позволили нам реализовать поддержку аппаратных моментальных снимков уровня СХД на полностью отечественном стеке — в качестве СХД выступает YADRO TATLIN.UNIFIED, а платформы виртуализации — zVirt. Использование аппаратных моментальных снимков уровня СХД существенно снижает нагрузку на виртуальную инфраструктуру и позволяет создавать моментальные снимки с высокой частотой, улучшая RPO.
При резервном копировании виртуальных машин на платформе zVirt традиционные методы, особенно длительное использование программных снапшотов гипервизора, создают серьезную нагрузку на дисковую подсистему и процессор, что приводит к падению производительности продуктивных сервисов. Решением проблемы является переход на аппаратные моментальные снимки уровня системы хранения данных, которые создаются практически мгновенно и не занимают дополнительного места. Упомянутая выше связка российских продуктов позволяет сократить время жизни «тяжелого» программного снапшота с часов до секунд, полностью снять нагрузку с гипервизора и реализовать безагентное копирование.
Ключевым элементом архитектуры становится выделенный физический сервер (Side Server) под управлением ОС Linux, который выступает мостом между СХД и системой резервного копирования. Процесс выглядит так: через API zVirt создается программный моментальный снимок ВМ, затем через API СХД мгновенно делаются аппаратные снимки томов хранилища, после чего программный моментальный снимок сразу удаляется. Из аппаратных снимков создаются тома-клоны, которые подключаются к выделенному серверу, где агент Кибер Бэкапа считывает данные и отправляет их в архив, а клоны затем удаляются.
В итоге такое решение обеспечивает высокую скорость и надежность резервного копирования без установки агентов внутрь каждой ВМ, упрощает администрирование крупных инфраструктур и сводит к минимуму влияние процесса резервного копирования на производительность рабочих виртуальных машин. При этом стандартное восстановление из резервных копий выполняется традиционным способом через виртуальное устройство, так как требует интеграции на уровне гипервизора.
Детальному обзору этого сценария мы посвятили отдельную статью — «Резервное копирование виртуальных машин zVirt с помощью аппаратных снимков СХД»
Уровень 5 — Поддержка мгновенного восстановления
Мгновенное восстановление — это запуск виртуальной машины, которая содержит всю машину или все тома, которые необходимы для запуска операционной системы. Эта операция позволяет запустить виртуальный сервер за считанные секунды. Виртуальные диски эмулируются непосредственно с резервной копии и поэтому не занимают место в хранилище данных. Место хранения требуется только для того, чтобы сохранить изменения в виртуальных дисках. Резервная копия может храниться в сетевой папке, на узле хранения или в локальной папке машины, на которой установлен агент для поддерживаемых платформ виртуализации. Сетевая папка должна быть доступной с данной машины. Виртуальную машину невозможно запустить из резервной копии, хранящейся на сервере SFTP, на ленточном устройстве или в зоне безопасности.
Мгновенное восстановление может использоваться в следующих сценариях:
- Аварийное восстановление. Мгновенное восстановление виртуальной машины, на которой произошел сбой
- Тестирование резервного копирования. Запустите машину из резервной копии и убедитесь в том, что гостевая ОС и приложения работают корректно
- Доступ к данным приложения. Когда машина запущена, можно воспользоваться встроенными инструментами управления в приложении, чтобы получить доступ к требуемым данным и извлечь их
В настоящее время мгновенное восстановление поддерживается для платформ VMware и Hyper-V. В планах — расширение поддержки этого способа восстановления на платформу oVirt и системы виртуализации на ее основе.
Заключение
Рассмотренные уровни защиты виртуальных сред в Кибер Бэкапе наглядно демонстрируют зрелую, модульную и технологически независимую архитектуру резервного копирования, которая адаптирована под современные реалии ИТ-ландшафтов, включая гетерогенные инфраструктуры. Каждый из представленных уровней — начиная с логической классификации данных с помощью тегов и заканчивая глубокой аппаратной интеграцией с отечественными системами хранения данных и поддерживаемыми гипервизорами — предназначен для закрытия конкретных болевых точек бизнеса и ИТ-команд.
В частности, такой подход позволяет устранить ручные операции, существенно снизить потребление вычислительных и дисковых ресурсов, обеспечить надежную изоляцию трафика резервного копирования от основной производственной сети и, что критически важно, минимизировать время восстановления (RTO) в случае инцидента или сбоя.