Commvault часть 3. Резервное копирование виртуализации VMware

В этой части рассмотрим защиту виртуальной инфраструктуры VMware: архитектуру решения, типы прокси-серверов и транспортные режимы (HotAdd, SAN, NAS, NBD), интеграцию с аппаратными снапшотами СХД через IntelliSnap, настройку подключения vCenter и группировку виртуальных машин, типы резервных копий и механизм Changed Block Tracking и балансировку нагрузки между несколькими прокси, а также варианты восстановления VM.

Защита виртуальных машин — одна из ключевых задач в большинстве корпоративных сред. Commvault, как и большинство конкурирующих продуктов реализует её через агента, который устанавливается на отдельный прокси-сервер и взаимодействует с VMware vCenter по API, не требуя установки агентов внутрь каждой VM.

Для бэкапа задействованы следующие компоненты:

• vCenter Server — точка входа: Commvault подключается именно к vCenter, а не напрямую к ESXi-хостам
• Прокси-сервер (Access Node) — сервер с установленным агентом Commvault. Именно он выполняет операции бэкапа и восстановления VM, читает данные и передаёт их на MediaAgent. Тип прокси — виртуальный или физический, Windows или Linux — определяет доступные транспортные режимы
• MediaAgent — принимает поток данных от прокси, дедуплицирует и пишет в хранилище
• VADP (vStorage APIs for Data Protection) — VMware API, через который Commvault читает данные VMDK без остановки VM

Прокси-сервер и MediaAgent могут быть совмещены на одном сервере — это типичная конфигурация для небольших сред.

1. Типы прокси и транспортные режимы

Тип прокси-сервера напрямую определяет доступные транспортные режимы — способы, которыми данные читаются из хранилища. Это один из ключевых архитектурных выборов при настройке резервного копирования виртуальных машин.
По умолчанию Commvault выбирает транспортный режим автоматически — но важно понимать, что именно он выбирает и почему.

Виртуальный прокси → HotAdd
Наиболее распространённый вариант. Прокси — обычная VM с установленным агентом, развёрнутая прямо в том же кластере vSphere, что и защищаемые машины.
Транспортный режим — HotAdd: Commvault создаёт VMware-снапшот защищаемой VM, подключает VMDK этого снапшота к прокси-VM как дополнительный диск. Оригинальные диски VM продолжают работать в штатном режиме — прокси читает данные из снапшота, не трогая рабочие VMDK. После завершения бэкапа диск отключается от прокси, а затем снапшот удаляется. Данные не идут по management-сети VMware (как в случае с NBD), а передаются через внутренний сетевой интерфейс прокси-VM — LAN-free бэкап.

Commvault предоставляет готовый OVA-шаблон для такого прокси — Access Node and MediaAgent (FREL) OVA с предустановленным Linux, Virtual Server Agent и MediaAgent. Аббревиатура FREL расшифровывается как File Recovery Enabler for Linux — компонент, который позволяет выполнять гранулярное восстановление отдельных файлов из бэкапов Linux-VM (browse & restore внутри VMDK без восстановления всей машины). Windows-прокси не умеет читать файловые системы Linux (ext4, XFS, LVM), поэтому для гостевого восстановления файлов Linux-VM нужен именно FREL. Таким образом, в одном образе объединены три роли: Access Node (прокси для бэкапа VM), MediaAgent (запись в хранилище) и FREL (восстановление файлов из Linux-VM). При выходе обновлённого OVA Commvault рекомендует вывести старый прокси из эксплуатации и развернуть новый из актуального шаблона, а не обновлять существующий.

Физический прокси с SAN-доступом → SAN (+ IntelliSnap)
Прокси — физический сервер с зонингом/маппингом к SAN-массиву. Он читает данные напрямую с СХД, минуя ESXi-хост и data-сеть. Самый быстрый режим — но требует FC или iSCSI-подключения к той же СХД, где размещаются виртуальные машины.
SAN-режим открывает возможность для интеграции с IntelliSnap — механизмом аппаратных снапшотов СХД. Схема работы:

1. Commvault через vStorage API создаёт кратковременный VMware-снапшот VM — он фиксирует консистентное состояние в нужный момент
2. Немедленно после этого Commvault даёт команду СХД создать снапшот LUN
3. VMware-снапшот сразу удаляется — redo-лог минимален, нагрузка на VM практически нулевая
4. Аппаратный снапшот СХД остаётся как точка восстановления и используется для Backup Copy
5. Физический прокси монтирует снапшот СХД и передаёт данные на MediaAgent для записи в долгосрочное хранилище
6. После завершения Backup Copy снапшот размонтируется, но остаётся на СХД как persistent recovery point. Это позволяет восстанавливать VM напрямую с массива — быстро и без обращения к Backup Copy. Снапшот удаляется позже механизмом Data Aging, когда истекает retention snap copy (по умолчанию Commvault удерживает 8 snap recovery points — при создании девятого самый старый удаляется)

Ключевое преимущество: VMware-снапшот живёт секунды, а не часы. Это критично для высоконагруженных VM — чем дольше живёт снапшот, тем больше растёт redo-лог и тем дольше ESXi сливает его обратно после удаления.
Ограничения IntelliSnap:

• Датасторы должны быть созданы из LUN внешней СХД — локальные диски не поддерживаются
• VM с дисками на датасторах от разных вендоров не поддерживаются в одном subclient
• vSphere-теги не сохраняются при IntelliSnap-бэкапах
• Требует отдельной лицензии IntelliSnap

Физический прокси или Linux VM с NFS-доступом → NAS
Для VM на NFS-датасторах. Прокси читает данные напрямую с NFS-сервера, минуя ESXi-хост.
Доступность NAS-транспорта зависит от типа прокси:

• Windows VM прокси — NAS-транспорт недоступен. Commvault автоматически переключается на HotAdd, так как он производительнее
• Windows физический прокси — NAS-транспорт доступен (физический сервер с NFS-доступом к датастору)
• Linux прокси (физический или VM) — NAS-транспорт доступен, читает NFS напрямую через libnfs без монтирования через ESXi-хост

IntelliSnap для NAS-датасторов поддерживается, но поведение операции Backup Copy зависит от вендора СХД и версии протокола: для NetApp NFSv3 Backup Copy выполняется без монтирования снапшота на ESXi-хост — данные читаются напрямую по NFS. Для NetApp NFSv4 и других NFS-вендоров Backup Copy монтирует снапшот датастора на ESXi-хост — и уже с этого примонтированного датастора данные читаются: Windows access node читает с ESXi-хоста через NBD (поскольку данные теперь доступны через ESXi, а не напрямую по NFS), Linux access node — через NAS-транспорт напрямую.

Любой прокси → NBD / NBDSSL
Данные передаются через management-сеть ESXi-хоста к прокси-серверу по протоколу NBD (Network Block Device). NBDSSL — то же самое, но с шифрованием. Работает везде и с любым типом прокси — но нагружает management-интерфейс ESXi-хоста: VMware намеренно троттлит трафик через management VMkernel, и реальная пропускная способность составляет лишь около 40% от физической скорости NIC. Универсальный fallback, если HotAdd или SAN недоступны — работает везде, но с ограничениями по пропускной способности.

Сводная таблица

Тип прокси	Транспорт	Скорость	Требования
VM в кластере	HotAdd	Высокая	Общий кластер с защищаемыми VM
Физический, SAN-доступ	SAN	Максимальная	FC/iSCSI-зонинг к хранилищу
Физический или Linux VM, NFS-доступ	NAS	Высокая	NFS-датастор
Любой	NBD/NBDSSL	Средняя	Только сеть (management)

2. Настройка бэкапа VMware через Command Center: подключение vCenter и создание VM Group

Шаг 1 — Добавить Hypervisor (vCenter)

1. Protect → Virtualization
2. Нажать Add hypervisor
3. Выбрать VMware
4. Указать FQDN vCenter, учётные данные сервисной учётки
5. Выбрать прокси-сервер (Access node) — сервер с установленным агентом Commvault

Шаг 2 — Создать VM Group
После подключения vCenter Commvault автоматически обнаруживает все VM. Нужно создать VM Group — набор правил, какие VM защищать.

1. В списке Hypervisors нажать на добавленный vCenter
2. Add VM group
3. Указать имя группы
4. Выбрать содержимое (подробнее — в следующем разделе)
5. Назначить Plan
6. Сохранить

3. Как правильно группировать VM: правила автообнаружения и теги vSphere
Это один из вопросов, который чаще всего вызывает замешательство при первой настройке — мастер создания VM Group создаёт впечатление, что нужно добавить все VM кластера в одну группу. Это не так, и Commvault прямо указывает в документации: не создавай отдельный subclient для каждой VM, но и не сваливай все VM в одну группу — создавай группы для VM со схожими требованиями к защите.
Почему одна большая группа — плохая идея

• Все VM в группе бэкапятся одним заданием с одним расписанием и одним Retention. Если одним VM нужен бэкап каждый час, а другим раз в день — придётся делать несколько групп
• Одно задание на 500 VM — это огромный job, который сложно мониторить и диагностировать при ошибках
• Параллельность ограничена числом потоков: разделив VM по нескольким группам, можно запускать задания параллельно и вписываться в узкое backup-окно

Принципы группировки
Наиболее полезная стратегия — разные subclients для разных датасторов. Это позволяет запускать задания параллельно для лучшей производительности при бэкапе большого числа VM.
Commvault рекомендует группировать VM по следующим критериям:

• По классу критичности: продуктивные VM (частый бэкап, долгий Retention), тестовые/dev (реже, короче), архивные (раз в неделю)
• По типу нагрузки: VM с БД (SQL, Oracle) отдельно — у них transaction log бэкап и другое расписание; обычные файловые серверы отдельно
• По датастору или кластеру: небольшое число групп, каждая из которых включает похожие классы VM из разных датасторов. Такой подход даёт лучшую масштабируемость и упрощает администрирование. Отдельно стоит вынести высоконагруженные VM (high transaction) — им нужен свой датастор и своя группа
• По требованиям к восстановлению (SLA/RTO): VM с жёстким RTO (2 часа) в отдельную группу с более частым бэкапом
• По географии: VM на разных площадках или в разных VLAN — в разные группы с разными прокси

Правила автообнаружения вместо ручного выбора
Вместо того чтобы добавлять VM вручную, лучше использовать правила (rules). Это особенно важно для динамичных сред, где VM создаются и удаляются регулярно.
Доступные критерии для правил:

• Тег vSphere (рекомендуется) — например, тег backup-tier=gold для критичных VM
• Имя VM — по паттерну или регулярному выражению (prod-*, *-db-*)
• Датастор — все VM на конкретном датасторе
• Кластер или хост — все VM на конкретном хосте или кластере
• Папка vCenter — все VM в папке Production/Databases
• Гостевая ОС — например, все Windows Server 2022

Правила можно комбинировать: «все VM с тегом tier=gold И размещённые в кластере prod-cluster«. Или: «все VM в папке Production, КРОМЕ тех, у которых тег no-backup«.
Избегай добавлять прокси-VM в содержимое группы, которую этот же прокси обслуживает. Исключи прокси явно через правило-исключение или создай для них отдельную группу с другим прокси.

Пример структуры групп

VM Group	Содержимое	Plan	Прокси
prod-critical	Тег tier=gold	Full еженедельно, Incremental каждый час, Retention 90 дней	proxy-01, proxy-02
prod-standard	Тег tier=silver	Full еженедельно, Incremental ежедневно, Retention 30 дней	proxy-01, proxy-02
prod-databases	Тег type=db	Full еженедельно, Log каждые 15 мин, Retention 30 дней	proxy-db
dev-test	Папка Dev/*	Full еженедельно, Retention 7 дней	proxy-01
infra-proxies	Сами прокси-VM	Full еженедельно, Retention 14 дней	proxy-02 (другой прокси!)

4. Типы бэкапа для VMware: Full, Incremental и Synthetic Full

Full — полная копия всех VMDK защищаемых VM. Запускается первым и служит базой для последующих инкрементальных копий.
Incremental — копирует только блоки VMDK, которые изменились с последнего бэкапа. Работает через механизм VMware Changed Block Tracking (CBT) — VMware сам отслеживает какие блоки были изменены и передаёт эту информацию Commvault. Очень быстрый и экономичный.

Если CBT недоступен или не работает, Commvault автоматически переключается на резервный механизм — CRC (Cyclic Redundancy Check). В этом режиме прокси читает весь VMDK целиком и сравнивает блоки по контрольным суммам, чтобы определить изменения. Бэкап остаётся инкрементальным по объёму передаваемых данных, но по времени выполнения может быть почти таким же долгим, как Full — потому что весь диск приходится прочитать. Поэтому проблемы с CBT нужно устранять как можно быстрее.

CBT иногда выходит из строя после миграции VM (Storage vMotion), восстановления из снапшота или при некоторых сбоях. Commvault логирует это событие — его видно в Events задания.

Synthetic Full — создаёт «виртуальную» полную копию в хранилище, объединяя последний Full и все Incremental, без чтения данных с ESXi. Позволяет не гонять полный бэкап по сети каждую неделю.
Важная особенность с точки зрения нагрузки: Synthetic Full не использует ресурсы клиента (ESXi-хоста и самих VM) — вся работа происходит на уровне MediaAgent и хранилища. Однако операция требует одновременного чтения и записи на хранилище, что создаёт нагрузку на Disk Library. Commvault рекомендует: если Synthetic Full выполняется слишком долго или нагружает хранилище, можно вместо него использовать обычный Full раз в неделю с ежедневными инкрементальными бэкапами.

5. Application-Aware бэкап VMware: crash-consistent и application-consistent

По умолчанию Commvault делает crash-consistent бэкап — VM фиксируется снапшотом в момент бэкапа. Для большинства VM это нормально: после восстановления система поднимается как после аварийного отключения питания.
Для VM с приложениями и базами данных (SQL Server, Oracle, Exchange и другие) можно включить application-consistent бэкап:

• Без guest agent: Commvault использует VMware Tools для quiescing (заморозки) файловой системы и VSS-снапшота внутри VM. Работает без установки агентов Commvault, но с ограниченными возможностями восстановления.
• С guest agent: внутри VM установлен соответствующий агент Commvault (SQL Server, Oracle, Exchange и другие). Позволяет делать гранулярное восстановление — восстанавливать отдельные базы данных или таблицы прямо из VM-бэкапа.

6. Варианты восстановления VM: Full VM Restore, Guest File Restore и Live VM Browse

Full VM Restore — восстановление всей VM целиком: на тот же датастор/хост, или на другой (out-of-place). Можно восстановить с новым именем, в другую сеть, с другими ресурсами.
Guest File Restore — восстановление отдельных файлов из VMDK без восстановления всей VM. Commvault монтирует VMDK из бэкапа и предоставляет браузер файлов.
Disk Restore — восстановление отдельного VMDK и подключение его к существующей VM.
Live VM Browse — просмотр файлов внутри VM-бэкапа в реальном времени через Command Center без запуска восстановления.

7. Балансировка нагрузки между несколькими прокси: координатор и распределение потоков

В production-средах почти всегда используется несколько прокси — для параллельной обработки большого числа VM и отказоустойчивости. Commvault управляет распределением нагрузки автоматически, но важно понимать как это работает.

Роль координатора
Когда в настройках vCenter-клиента добавлено несколько прокси, первый в списке становится координатором. Именно он:

• Получает задание от CommServe
• Строит очередь VM для бэкапа, расставляя приоритеты
• Распределяет VM и потоки (streams) между доступными прокси
• Отслеживает текущую нагрузку каждого прокси в реальном времени

Если координатор недоступен — задание не запустится, даже если остальные прокси работают. Поэтому координатор стоит делать самым надёжным и ресурсоёмким прокси в группе.
Приоритизация VM
Перед распределением координатор выстраивает очередь VM по приоритету:

1. Новые VM (ещё ни разу не бэкапились) — высший приоритет
2. VM, у которых предыдущий бэкап завершился с ошибкой
3. VM, для которых доступно меньшее число прокси (менее гибкие в распределении)
4. VM с большим числом дисков и объёмом данных

Алгоритм распределения потоков
Координатор назначает потоки по следующей логике: сначала отдать поток каждому свободному прокси, затем — каждому прокси хотя бы по одному потоку, и только после этого назначать дополнительные потоки прокси с наименьшим процентом занятости. Когда прокси достигает лимита — новые потоки ему не назначаются, пока все остальные прокси тоже не достигнут своего лимита.
Проще говоря: сначала нагрузка распределяется равномерно по всем прокси, и лишь потом начинается дозагрузка самых свободных.

Сайзинг прокси
1 CPU прокси поддерживает 10 потоков, и каждый поток требует 100 MB RAM. Координатор использует эти данные для автоматического расчёта лимита потоков каждого прокси. Например, прокси с 8 CPU и 32 GB RAM теоретически может вести до 80 одновременных потоков — на практике рекомендуется закладывать 50–60% от максимума для стабильной работы.

Как добавить прокси в конфигурацию vCenter

1. Protect → Virtualization → выбрать vCenter
2. Нажать редактировать (карандаш) → раздел Access nodes
3. Добавить все прокси в список
4. При необходимости изменить порядок — первый в списке станет координатором
5. Сохранить

После этого Commvault автоматически будет задействовать все прокси из списка при запуске бэкапов.

Привязка прокси к конкретному subclient
Если нужно принудительно использовать конкретные прокси для определённой группы VM (например, прокси на том же ESXi-кластере, что и VM), это настраивается на уровне VM Group:
VM Group → Edit → Access nodes → выбрать конкретные прокси для этой группы.
Это полезно когда прокси находятся в разных датацентрах или имеют доступ к разным датасторам.

Использование Client Groups
Вместо перечисления прокси по одному можно создать Client Group (группу клиентов) и добавить в неё все прокси. Тогда добавление нового прокси в группу автоматически делает его доступным для всех VM Groups, которые эту группу используют — без редактирования каждого subclient вручную.

Практический совет: для типового кластера из 3 прокси рекомендуется: первый прокси — координатор, наиболее мощный; остальные два — рабочие узлы. Создай Client Group «VMware-Proxies» и используй её во всех VM Groups — тогда добавление четвёртого прокси займёт одно действие.

8. Другие поддерживаемые гипервизоры в Commvault 11.40

VMware — наиболее распространённый гипервизор в корпоративных средах, поэтому мы разобрали его подробно. Однако Commvault поддерживает широкий спектр других платформ виртуализации — все они работают по той же принципиальной схеме: прокси-сервер подключается к платформе управления (аналог vCenter), читает данные VM через API гипервизора и передаёт их на MediaAgent.

Платформа	Аналог vCenter	Поддержка IntelliSnap
Microsoft Hyper-V	SCVMM или Hyper-V хост	+
Nutanix AHV	Nutanix Prism	+
Proxmox VE	Proxmox API	—
HPE Morpheus VM Essentials	HPE Morpheus API	—
Red Hat Virtualization (RHV)	RHV Manager	—
Oracle VM	Oracle VM Manager	—
Citrix Hypervisor (XenServer)	Citrix XenCenter	—
OpenStack	OpenStack API	—
VMware vCloud Director	vCloud Director API	—
Huawei FusionCompute	FusionCompute VRM	—