Commvault часть 1. Основы и архитектура
1. Ключевые компоненты системы
Прежде чем рассматривать архитектуру целиком, нужно познакомиться с основными «кирпичами», из которых она состоит.
| Компонент | Роль |
|---|---|
| CommServe | Центральный сервер управления. Хранит конфигурацию, политики, базу данных CommCell. Без него система не работает. |
| MediaAgent | Перемещает данные между клиентом и хранилищем. Управляет процессом записи/чтения. |
| Client (агент) | Программа-агент на защищаемом сервере. Знает, какие данные отправлять и куда. |
| Storage | Физическое место хранения копий: диск, лента, облако. |
| Command Center | Веб-интерфейс для управления всем CommCell через браузер. |
1.1 CommServe — центр управления
CommServe — это единственный обязательный сервер в любой Commvault-среде. На нём работают два ключевых процесса:
- CommServe Services — основные сервисы Commvault, которые принимают задания, отслеживают их выполнение, управляют расписанием
- CommServe Database (SQL Server) — база данных, в которой хранится ВСЁ: список защищаемых серверов, политики резервного копирования, история заданий, информация о местонахождении каждой копии данных
Важно: если CommServe недоступен, новые задания не запускаются, но уже запущенные могут продолжаться. Если CommServe и его БД безвозвратно утеряны — восстановить среду «как было» без DR-backup CommServe будет очень сложно.
1.2 MediaAgent — транспортный уровень
MediaAgent — это сервер (или несколько серверов), который выполняет фактическую работу по перемещению данных. Именно MediaAgent:
- Читает данные с клиентского сервера через агент
- Дедуплицирует и сжимает поток данных
- Записывает данные в хранилище (диск, лента, облако)
- Управляет Deduplication Database (DDB) — базой дедупликации
В маленьких средах CommServe и MediaAgent могут жить на одном сервере. В больших — MediaAgent выносят отдельно или разворачивают несколько для балансировки нагрузки.
1.3 Client и агенты — что защищаем
Клиент в терминологии Commvault — это любой сервер или рабочая станция, на которой установлен агент (iDA — intelligent Data Agent) и данные которой нужно защищать.
Типы агентов:
- File System Agent — для резервного копирования файлов и папок (Windows/Linux)
- SQL Server Agent — бэкап Microsoft SQL Server
- Oracle Agent — бэкап Oracle Database
- Exchange Agent — бэкап почтовых ящиков Microsoft Exchange
- Virtual Server Agent (VSA) — защита виртуальных машин VMware и Hyper-V
- Cloud Apps Agent — Office 365, SharePoint Online, Teams и другие облачные сервисы
Application-aware агенты (SQL, Oracle, Exchange) умеют делать резервную копию «на живую», не останавливая работу приложения, и позволяют восстанавливать отдельные объекты — например, одно письмо из почтового ящика.
1.4 Storage — где хранятся данные
Commvault умеет работать с разными типами хранилищ:
- Disk Library — обычный сетевой или локальный диск (NFS, CIFS, iSCSI)
- Cloud Storage — Azure Blob Storage, Amazon S3, Google Cloud Storage, объектные хранилища совместимые с S3
- Tape Library — ленточные библиотеки
- Deduplication Storage Pool — специальный тип хранилища с дедупликацией
Начиная с версии 11.20+, хранилищами управляют через Storage Pools и Plans — старое понятие Storage Policy устарело, хотя ещё встречается в документации.
1.5 DDB — как работает дедупликация
Deduplication Database (DDB) — это специальная база данных, которая хранит хэши всех уникальных блоков данных, которые MediaAgent когда-либо записал в хранилище. Когда MediaAgent получает новый блок данных, он сначала ищет его хэш в DDB — и если такой блок уже есть, не записывает его повторно, а просто делает ссылку на уже существующий.
Как DDB связана с Disk Library. DDB и Disk Library — два разных места на диске, но работают вместе как единое целое:
- Disk Library — хранилище самих данных: сюда записываются фактические блоки бэкапа
- DDB — индекс этих блоков: хранит хэши и метаданные, но не сами данные
На практике они чаще всего живут на одном физическом диске/разделе, но технически это отдельные структуры. DDB управляется MediaAgent-ом и физически живёт на том сервере, где запущен MediaAgent.
Как это работает пошагово:
- Агент на клиенте разбивает данные на блоки и отправляет их на MediaAgent
- MediaAgent вычисляет хэш каждого блока
- Ищет этот хэш в DDB — если блок уже есть, просто сохраняет ссылку на него
- Если блока нет — записывает его в Disk Library и добавляет хэш в DDB
- Метаданные о том, где какой блок лежит, передаются в CommServe DB
Важные практические моменты:
- Где физически живёт DDB. На диске MediaAgent-а — не в Disk Library и не на CommServe. Рекомендуется выносить на отдельный быстрый диск (SSD), потому что при каждом бэкапе идёт интенсивное чтение/запись в DDB.
- Каждая Disk Library имеет свою DDB. Если хранилищ три — DDB тоже три. Дедупликация работает только в пределах одной DDB.
- DDB Reconstruction. Если DDB повреждена — Commvault умеет пересобрать её из данных в Disk Library, но это долгий процесс. Поэтому DDB рекомендуют бэкапить отдельно (через DDB Backup в свойствах Storage Pool).
- Что будет если DDB недоступна. MediaAgent не сможет записывать новые данные — бэкапы будут падать с ошибкой. Восстановление из уже существующих копий при этом возможно, если сами данные в Disk Library целые.
1.6 Chunk — минимальная единица хранения
Commvault записывает данные в Disk Library не отдельными файлами, а чанками (Chunks) — блоками фиксированного размера, по умолчанию 512 MB каждый. Именно поэтому, если заглянуть в папку Disk Library на диске, там не будет привычных файлов бэкапа — только большие непонятные куски с именами V_1_0_1724 и папки с числовыми именами.
Что важно знать про чанки:
- Один чанк может содержать данные от разных клиентов и разных заданий
- Чанк считается «запечатанным» (sealed) после заполнения — новые данные пишутся в следующий
- При удалении устаревших копий (Data Aging) Commvault не удаляет чанки целиком — он помечает блоки внутри как свободные и постепенно дефрагментирует чанки
- Размер чанка влияет на производительность: маленькие чанки = больше файлов на диске = медленнее
Никогда не удаляй чанки вручную — только через Commvault. Иначе данные станут невосстановимы.
1.7 Index (SIDB) — как работает Browse & Restore
Index — это отдельная база данных, которая хранит каталог всех защищённых файлов и объектов с их метаданными: имя файла, путь, дата изменения, к какому бэкап-заданию относится. Именно благодаря индексу работает функция Browse & Restore — когда администратор открывает восстановление и видит дерево файлов на любую дату в прошлом.
Как индекс связан с остальными компонентами:
- MediaAgent строит и обновляет индекс во время каждого бэкапа
- Физически индекс хранится на диске MediaAgent-а (отдельно от DDB и Disk Library)
- CommServe DB знает, где находится индекс для каждого клиента, и обращается к нему при запросе восстановления
Почему это важно знать на практике:
- Если индекс повреждён — Browse & Restore не работает, хотя сами данные в Disk Library целы. Индекс можно пересобрать (Index Reconstruction), но это занимает время
- Индекс растёт со временем и занимает место на диске MediaAgent-а — за этим нужно следить
- При первом обращении к старому индексу Commvault может подгружать его с диска, что замедляет начало восстановления — это нормальное поведение
1.8 DR Backup — бэкап самого CommServe
DR Backup (Disaster Recovery Backup) — это резервная копия не пользовательских данных, а самого CommServe: его базы данных, конфигурации, политик, информации обо всех клиентах и хранилищах. Проще говоря — это бэкап «мозга» системы.
Почему это критично: если CommServe физически сломается и у тебя нет DR Backup — ты потеряешь всю конфигурацию среды. Сами данные в Disk Library при этом остаются целыми, но без CommServe DB Commvault не знает, что где лежит.
DR Backup включает:
- CommServe DB — основная база данных CommCell
- CommServe DR folder — набор XML-файлов с конфигурацией, которые позволяют восстановить CommServe даже без полного бекапа базы данных
- Encryption keys — если используется шифрование данных, ключи также включаются в DR Backup
DR Backup рекомендуется хранить в месте, физически отдельном от CommServe (другой диск, сетевая папка, облако).
2. Архитектура CommCell
Совокупность всех компонентов Commvault в рамках одной среды называется CommCell. У каждого CommCell есть уникальный идентификатор — CommCell ID, и он управляется одним CommServe.
2.1 Как данные движутся при бэкапе
Последовательность событий при запуске задания резервного копирования:
- CommServe запускает задание по расписанию (или вручную) и отправляет команду агенту на клиентском сервере
- Агент на клиенте читает данные (файлы, базу данных) и отправляет поток данных на MediaAgent
- MediaAgent получает поток, выполняет дедупликацию и компрессию, записывает данные в хранилище
- По завершении MediaAgent сообщает CommServe о результате — какие данные, куда записаны, в каком объёме
- CommServe обновляет свою базу данных: теперь он знает, что данные за эту дату лежат там-то
2.2 Как данные движутся при восстановлении
При восстановлении данных поток идёт в обратном направлении:
- Администратор через Command Center выбирает данные для восстановления и момент времени
- CommServe находит в своей БД, на каком MediaAgent и в каком хранилище лежат нужные данные
- MediaAgent читает данные из хранилища, распаковывает и передаёт агенту
- Агент записывает данные на клиент — в исходное или новое место
3. Plans — сердце конфигурации
Plan — это ключевая концепция современного Commvault. Plan объединяет в себе всё, что нужно знать системе о защите данных:
- Расписание — как часто делать бэкап (каждый день в 22:00, каждый час, по событию)
- Retention — сколько хранить копии (30 дней, 1 год, бессрочно)
- Хранилище — куда писать (диск, облако, лента, комбинация)
- Тип копии — Full, Incremental, Differential, Synthetic Full
Принцип работы с Plans:
- Создаёшь один Plan — например «Ежедневный бэкап, хранить 30 дней»
- Назначаешь этот Plan нескольким клиентам и серверам
- Всё — Commvault сам знает, что, когда и куда
До версии 11.20 вместо Plans использовались Storage Policy, Schedule Policy и Subclient Policy — три отдельных объекта. Plans заменили их все одним. В старой документации ты ещё можно встретить термин «Storage Policy» — это устаревший эквивалент Plans.
4. Интерфейсы управления
4.1 Command Center — основной интерфейс
Command Center — это веб-интерфейс Commvault, доступный через браузер
Command Center появился в Commvault 11 как замена старому Java-клиенту и сейчас является полноценным основным инструментом управления. В нём доступно:
- Просмотр и управление всеми джобами (Jobs)
- Настройка Plans, Storage, клиентов
- Мониторинг состояния среды
- Запуск восстановления (Restore)
- Управление лицензированием
- Обновление компонентов (Maintenance)
4.2 CommCell Console — Java-клиент
CommCell Console — это старый графический интерфейс на Java. Он ещё присутствует, но активно выводится из употребления. Некоторые специфические настройки, которые ещё не перенесли в Command Center, пока доступны только через него.
5. Лицензирование
5.1 Две модели покупки
Self-managed (on-premise software) — классический вариант: ты сам устанавливаешь CommServe, MediaAgent, управляешь инфраструктурой. Лицензия покупается через партнёра/реселлера, публичного прайса нет — цена всегда договорная.
Commvault Cloud (SaaS) — облачный вариант: Commvault берёт на себя инфраструктуру, ты платишь помесячно по открытым тарифам (за TB, за VM или за пользователя). Подходит для защиты Microsoft 365, Salesforce и облачных рабочих нагрузок.
5.2 Метрики лицензирования
За что именно ты платишь, зависит от типа защищаемых данных:
| Тип данных | Метрика |
|---|---|
| Серверы, NAS, виртуальные машины, облачные VM | Front-End TB — объём исходных данных до дедупликации |
| Виртуальные машины (альтернатива) | Per VM или Per socket |
| Пользовательские данные (Exchange, OneDrive, Teams) | Per user |
| Endpoint (ноутбуки, рабочие станции) | Per user |
Front-End TB — ключевое понятие. Это объём данных на источнике, который ты защищаешь, измеренный до того, как Commvault применит дедупликацию и компрессию. Например, если на сервере 10 TB данных — лицензия нужна на 10 FETB, даже если после дедупликации в хранилище займёт всего 2 TB.
5.3 Продуктовые пакеты
- Commvault Backup & Recovery — базовый пакет. Резервное копирование и восстановление для всех типов данных, дедупликация, шифрование, архивирование, IntelliSnap (снапшоты).
- Commvault Complete Backup & Recovery — расширенный пакет. Добавляет репликацию, более продвинутые DR-сценарии и дополнительные возможности управления данными.
- Commvault Unstructured Backup & Recovery — специализированный пакет только для файловых данных (File System, NAS, Object Storage).
- Auto Recovery (Disaster Recovery) — отдельный продукт для orchestrated failover: репликация рабочих нагрузок на резервную площадку и управляемое переключение при аварии.
5.4 Subscription vs Perpetual
Subscription (подписка) — покупается на 1, 2 или 3 года. По истечении срока без продления ПО перестаёт работать. Включает обновления и поддержку в течение срока подписки.
Perpetual (бессрочная) — покупается один раз, ПО остаётся навсегда. Однако ежегодно нужно платить за Maintenance & Support (~20% от стоимости лицензии) — без него не будет доступа к обновлениям и технической поддержке.
5.5 Evaluation-лицензия
При установке CommServe автоматически активируется evaluation-лицензия. Она даёт полный функционал на ограниченный период — обычно 30–90 дней. После истечения:
- Новые задания резервного копирования перестают запускаться
- Ранее созданные копии данных остаются доступными для восстановления
- Интерфейс начинает показывать предупреждения об истечении лицензии
На этом обзорная часть закончена, в следующей части мы перейдём к разбору процессу установки компонентов Commvault.
