Сегодня поговорим об агентах Commvault для защиты серверов и приложений: файловый Windows и Linux через File System Agent, резервное копирование Active Directory с поддержкой гранулярного восстановления, Microsoft SQL Server с транзакционными логами и Point-in-Time восстановлением, Microsoft Exchange с архивированием почты и восстановлением отдельных писем.
1. Software Cache: ограничение при установке агентов с Linux CommServe
Прежде чем переходить к агентам для файловых систем и приложений, разберём одно архитектурное ограничение, с которым сталкивается большинство новых инсталляций Commvault 11.40.
1.1 Что такое Software Cache
Software Cache — локальное хранилище установочных пакетов Commvault на CommServe. Когда запускается удалённая установка агента (Push Install), CommServe берёт нужный пакет из кэша и передаёт его на целевой сервер. Без пакета в кэше установка не запустится.
Кэш заполняется командой Download or copy software в разделе Manage → System → Maintenance.
1.2 Ограничение: Linux CommServe не раздаёт Windows-пакеты
Software Cache на Linux CommServe не может хранить и раздавать Windows-инсталляторы. Это архитектурное ограничение платформы.
При попытке Push Install на Windows-сервер с Linux CommServe появится ошибка:
Installing new Windows client using Linux/Unix CommServe Cache or Remote Cache is currently not supported.
Please associate the Windows client to a Windows Remote Cache and retry the install.Поскольку начиная с версии 11.40 все новые установки CommServe рекомендуется делать на Linux, с этим ограничением столкнётся большинство новых инсталляций при попытке защитить Windows-серверы.
1.3 Два способа обойти ограничение
Вариант 1 — Развернуть Windows Remote Cache
Правильный путь для сред, где планируется много Windows-серверов. Remote Cache — дополнительное хранилище пакетов на отдельном Windows-сервере, которое CommServe использует для установки на Windows-клиенты.
- Выбрать любой существующий Windows-сервер в CommCell (или установить агент на новый локально)
Manage → Servers→ выбрать этот сервер → настроить его как Remote software cache, указав путь для хранения пакетов- Скачать в этот кэш Windows-пакеты через
Download or copy software, выбрав Windows-платформы - Привязать целевые Windows-клиенты к этому Remote Cache
- Повторить Push Install
Вариант 2 — Локальная установка на клиенте
Проще и быстрее, если нужно добавить один-два Windows-сервера:
- Скачать Windows-инсталлятор Commvault (через
Download centerв Command Center) - Скопировать на целевой Windows-сервер
- Запустить
Setup.exeлокально - Выбрать New Installation → указать hostname CommServe
- Выбрать нужные компоненты (File System Agent, SQL Server Agent, Active Directory Agent и т.д.)
- Установщик автоматически зарегистрирует клиента в CommCell
2. Резервное копирование файловых систем: File System Agent для Windows и Linux
2.1 Что защищает File System Agent
File System Agent (FSA) — базовый агент Commvault для защиты файлов и папок на физических и виртуальных серверах Windows и Linux. Устанавливается непосредственно в ОС сервера.
FSA защищает:
- Файлы и папки (с сохранением прав доступа, ACL, атрибутов)
- System State (Windows) — реестр, системные файлы, необходимые для восстановления ОС
- Тома целиком (Volume-level backup)
2.2 Subclient — что бэкапится
Subclient — это единица настройки внутри агента: набор правил о том, что включать и исключать из бэкапа.
По умолчанию создаётся Default subclient, который защищает все локальные диски сервера. Его можно переопределить:
- Добавить конкретные папки (
C:\Data,/var/www) - Исключить ненужное (
*.tmp,C:\Windows\Temp,pagefile.sys) - Создать несколько subclients с разными расписаниями и хранилищами
К лучшим практикам относится не держать всё в Default subclient. Разделить данные по критичности — например, один subclient для данных приложений (ежечасный бэкап), другой для системных файлов (ежедневный), третий для архивов (еженедельный).
2.3 Настройка File System бэкапа
Manage → Servers→ выбрать нужный сервер- Вкладка Configuration → раздел File system
- Нажать
Add subclientили открыть Default - Указать содержимое (Content): папки и диски
- Указать исключения (Exclusions): типы файлов, папки
- Назначить Plan
- Сохранить
2.4 System State Backup (Windows)
System State включает компоненты, необходимые для восстановления работоспособности Windows:
- Registry (реестр)
- COM+ Class Registration Database
- Boot files
- Active Directory (на Domain Controllers)
- Certificate Services
Включается отдельно в настройках subclient: Backup → System state → Enable.
System State бэкап на Domain Controller — обязателен. Без него невозможно восстановить AD в случае катастрофы.
3. Резервное копирование Microsoft Active Directory: System State, GPO и Granular Recovery
3.1 Почему AD требует отдельного внимания
Active Directory — критическая инфраструктура любой Windows-среды. Её потеря или повреждение означает невозможность аутентификации пользователей, применения групповых политик и работы большинства корпоративных сервисов. Стандартный File System бэкап не подходит для восстановления AD — нужен специализированный агент.
Commvault защищает Active Directory через Active Directory Agent, который работает в связке с System State Backup.
3.2 Что включает AD-бэкап
- System State на DC — реестр, SYSVOL (папка с групповыми политиками и скриптами), файлы базы данных AD (ntds.dit), загрузочные файлы
- Group Policy Objects (GPO) — Commvault поддерживает бэкап и гранулярное восстановление отдельных GPO
- AD-объекты — пользователи, группы, компьютеры, организационные единицы (OU)
3.3 Типы восстановления
Non-Authoritative Restore — стандартное восстановление DC. После перезагрузки DC синхронизируется с другими DC в домене и получает актуальные данные. Используется когда нужно восстановить только «железо» DC, а данные AD актуальны на других DC.
Authoritative Restore — восстановление с пометкой объектов как «авторитетных». Используется когда нужно откатить изменения в AD (например, случайное массовое удаление объектов) — восстановленные объекты заменят актуальные данные на других DC при репликации. Требует загрузки DC в Directory Services Restore Mode (DSRM).
Гранулярное восстановление — восстановление отдельных пользователей, групп или OU без перезагрузки DC и без влияния на остальную инфраструктуру. Самый частый сценарий: случайно удалили пользователя или группу.
Отдельно поддерживается восстановление групповых политик (GPO): в дереве восстановления можно раскрыть CN=Policies и выбрать конкретную политику для точечного восстановления — например, Default Domain Policy.
4. Резервное копирование Microsoft SQL Server: Transaction Log и Point-in-Time Recovery
4.1 Как работает SQL Server Agent
SQL Server Agent — application-aware агент, который взаимодействует напрямую с SQL Server через SQL API. Это даёт три важных преимущества перед файловым бэкапом:
- Консистентность: бэкап снимается в согласованном состоянии — база готова к восстановлению без «доката» транзакций вручную
- Гранулярное восстановление: можно восстановить конкретную базу данных, не поднимая весь сервер
- Transaction log backup: бэкап журналов транзакций позволяет восстановить базу на любой момент времени с точностью до секунды (Point-in-Time Recovery)
4.2 Механика бэкапа — VDI и виртуальные устройства
Механика бэкапа SQL пригодится при диагностике сбоев. В стандартном (потоковом) режиме агент использует официальный интерфейс Microsoft — SQL Server Virtual Device Interface (VDI):
- Агент создаёт виртуальные устройства по спецификации VDI. Количество устройств равно числу потоков (streams), заданных в subclient (по умолчанию 2)
- Commvault отдаёт SQL Server команду
BACKUP DATABASE(илиBACKUP LOG) с аргументомTO VIRTUAL DEVICE - С точки зрения самого SQL Server это обычный бэкап — он даже записывается в историю бэкапов в
msdb - Вместо записи в файл SQL пишет данные в виртуальное устройство, откуда агент забирает поток, сжимает, дедуплицирует и отправляет на MediaAgent
Именно поэтому SQL Server Agent требует прав sysadmin в SQL и прав администратора Windows — VDI работает только с такими привилегиями.
4.3 Типы бэкапа
- Full backup — полная копия базы данных
- Differential — изменения с последнего Full-бэкапа
- Transaction Log (Incremental) — журналы транзакций, накапливают изменения между Full-бэкапами и позволяют восстановление на точку во времени
Типовая стратегия для продуктивного SQL: Full раз в неделю + Differential раз в день + Transaction Log каждые несколько минут.
Для бэкапа Transaction Log база данных должна работать в Full Recovery Model (не Simple). В Simple Recovery Model журналы транзакций автоматически очищаются — их бэкапить невозможно.
Автоматическая обработка «неудобных» баз. Начиная с новых версий Commvault по умолчанию:
- Пропускает базы в Simple Recovery Model при Transaction Log бэкапе
- Пропускает read-only базы при transaction log и differential бэкапах
- Пропускает базы, которые сейчас не в состоянии online — чтобы не создавать ложных ошибок задания
4.4 Три метода бэкапа: Streaming, IntelliSnap, Block-Level
Commvault предлагает три подхода к бэкапу SQL, каждый под свой сценарий:
Streaming (потоковый) — классический метод через VDI, описанный выше. Универсален, работает с любым хранилищем. Для больших баз может быть медленным, так как все данные читаются и передаются через агент.
IntelliSnap — аппаратный снапшот СХД. Для больших баз это самый быстрый вариант: создаётся снепшот на СХД, а затем Backup Copy переносит данные из снапшота, полностью на стороне MediaAgent — без нагрузки на продуктивный SQL-сервер.
Block-Level — блочный бэкап через VSS с возможностью многопоточности. Компромисс между streaming и IntelliSnap: умеет многопоточность, но всё равно требует потоковой передачи данных через VSS Shadow.
Почему для больших баз выбирают именно IntelliSnap. У streaming-метода есть фундаментальное ограничение: все данные физически читаются с продуктивного SQL-сервера и передаются через агент. Для базы на несколько терабайт это означает часы чтения и заметную нагрузку на диски и CPU сервера в момент бэкапа. Block-Level эту проблему не решает — он тоже читает данные потоком, просто эффективнее. IntelliSnap же перекладывает тяжёлую работу на СХД: массив создаёт снапшот за секунды (аппаратная операция, не зависящая от объёма), а последующий перенос данных (Backup Copy) выполняется MediaAgent-ом — продуктивный сервер в этом уже не участвует. Streaming остаётся оправданным для небольших баз и сред без поддерживаемой СХД, где разворачивать IntelliSnap избыточно.
4.5 Варианты восстановления SQL
Commvault поддерживает несколько сценариев восстановления:
Restore in place — восстановление базы на тот же инстанс с перезаписью. Стандартный сценарий при повреждении или потере данных.
Out-of-place restore — восстановление под другим именем или на другой SQL-инстанс. Полезно для создания копии продуктивной базы на тестовом сервере или для проверки бэкапа.
Point-in-Time Recovery — восстановление на конкретный момент времени. Commvault автоматически применяет нужную цепочку: последний Full до указанной точки + Differential + все Transaction Log вплоть до заданной секунды. Классический сценарий: «в 14:32 удалили важную таблицу — восстанавливаем базу на состояние 14:31».
Restore to Disk (в .bak файлы) — вместо восстановления в SQL данные выгружаются как файлы бэкапа .bak, которые потом DBA может восстановить через SQL Management Studio или другими инструментами. Полезно, когда нужно передать бэкап команде DBA или восстановить на сервере без агента Commvault. Число .bak файлов равно числу потоков, которыми снимался бэкап.
Table-Level Recovery — восстановление отдельных таблиц из базы без восстановления всей базы. Работает через Recovery Point (мгновенно смонтированную и подключённую копию). Доступно для block-level, application-aware и IntelliSnap бэкапов.
Нюанс Restore to Disk для IntelliSnap/VSS-бэкапов: если имя целевой базы совпадает с исходной, при выгрузке на диск база не подключится автоматически к целевому инстансу. Чтобы этого избежать, нужно либо задать другое имя, либо вручную отсоединить (detach) базу на целевом инстансе перед восстановлением.
4.6 Особенности защиты SQL
- AlwaysOn Availability Groups — Commvault поддерживает бэкап групп доступности, автоматически выбирая нужную реплику (обычно вторичную, чтобы не нагружать первичную)
- Instance-level protection — можно защитить весь SQL-инстанс целиком, включая автообнаружение новых баз: создал DBA новую базу — она автоматически попадёт под защиту без ручной настройки subclient
- Multi-streaming — распараллеливание бэкапа и восстановления на несколько потоков для ускорения работы с большими базами
5. Резервное копирование Microsoft Exchange: Database Backup и Granular Recovery
5.1 Что защищает Exchange Agent
Exchange Agent обеспечивает защиту почтовых ящиков Exchange на уровне баз данных и отдельных объектов:
- Database backup — резервная копия всей базы данных Exchange (EDB)
- Mailbox-level restore — восстановление отдельного почтового ящика
- Item-level restore — восстановление конкретного письма, папки или контакта
5.2 Что входит в Exchange subclient
При настройке Exchange бэкапа в Commvault администратор определяет, что защищать. Типовой набор:
- Primary mailbox — основные почтовые ящики пользователей
- Archive mailbox — архивные ящики (In-Place Archive)
- Mailbox associated with disabled user — ящики отключённых пользователей (позволяет не терять данные после увольнения сотрудника)
Каждый из этих типов можно включить или отключить независимо в настройках Exchange Plan.
5.3 Архивирование Exchange (Stubbing)
Помимо резервного копирования, Exchange Mailbox Agent умеет архивировать почту — переносить старые письма из продуктивного Exchange в хранилище Commvault, освобождая место на почтовых серверах.
Как работает stubbing
Ключевая фишка — так называемые stubs (заглушки). Процесс состоит из двух отдельных операций:
- Archiving job — копирует письма, соответствующие правилам (например, старше 90 дней или больше определённого размера), в хранилище Commvault. На этом этапе письма ещё остаются в почтовом ящике.
- Cleanup job — заменяет оригинальные письма в почтовом ящике на stub’ы. Stub выглядит для пользователя как обычное письмо (с темой, отправителем, датой), но само тело и вложения физически перенесены в хранилище резервных копий.
Когда пользователь открывает stub в Outlook или OWA, письмо прозрачно восстанавливается из архива Commvault — без обращения к администратору.
Варианты cleanup-политики
Cleanup-политика Exchange определяет, что происходит с письмом после архивирования:
- Заменить на stub — письмо остаётся видимым, но тело и вложения выгружены в архив (экономия места с сохранением доступа)
- Удалить только вложения — само письмо остаётся в ящике, но тяжёлые вложения заменяются stub’ом
- Удалить без stub — письмо полностью удаляется с Exchange-сервера после архивирования; восстановление только через администратора
Зачем это нужно
- Резко снижает размер продуктивных почтовых баз Exchange — можно задать пользователям маленькие квоты (например, 100 MB), при этом вся история переписки остаётся доступной через архив
- Ускоряет бэкап Exchange — меньше активных данных на сервере
Archiving и Backup — разные операции. Backup создаёт копию для восстановления, оставляя оригинал нетронутым. Archiving переносит данные в хранилище и (при cleanup) удаляет их из источника, освобождая место. Обе задачи Exchange Mailbox Agent выполняет в рамках одного решения.
6. Поддерживаемые приложения и базы данных в Commvault 11.40
В этой статье мы подробно разобрали наиболее распространённые агенты: File System, Active Directory, SQL Server и Exchange. Но Commvault поддерживает намного больше приложений — описывать каждое так же подробно слишком объёмно, к тому же большинство работает по схожей логике: агент устанавливается на сервер, взаимодействует с приложением через его API или VSS, делает application-consistent бэкап и поддерживает гранулярное восстановление.
Ниже — полный список приложений и баз данных, которые Commvault поддерживает в версии 11.40:
Базы данных:
| Приложение | Особенности |
|---|---|
| Oracle / Oracle RAC | RMAN-интеграция, бэкап tablespace и архивных логов, Oracle Exadata, поддержка Oracle Wallet (шифрование) |
| MySQL | Бэкап на уровне баз и таблиц, поддержка RDS |
| PostgreSQL | DumpBased и FSBased бэкап, параллельные задания |
| SAP HANA | Бэкап через Backint API, поддержка SAP HANA System Replication |
| SAP for Oracle / SAP for MaxDB | Интеграция через BR*Tools |
| IBM DB2 / DB2 MultiNode / DB2 pureScale | Полный и инкрементальный бэкап, поддержка кластерных конфигураций |
| Sybase (SAP ASE) | Бэкап через Sybase Backup Server API |
| IBM Informix | Онлайн-бэкап через onbar |
| MongoDB | Бэкап через mongodump или снапшоты |
Приложения Microsoft:
| Приложение | Особенности |
|---|---|
| SharePoint Server | Гранулярное восстановление на уровне сайтов, библиотек и документов |
| Microsoft Teams / OneDrive / SharePoint Online | Через Cloud Apps Agent (Microsoft 365) |
| Dynamics 365 | Через Cloud Apps Agent |
Другие приложения:
| Приложение | Особенности |
|---|---|
| IBM Notes (Lotus Notes/Domino) | Бэкап почтовых баз NSF, гранулярное восстановление документов |
| Salesforce | Бэкап объектов и вложений через Salesforce API |
| Documentum | Бэкап репозиториев контента |
| Hadoop (HDFS) | Бэкап распределённой файловой системы |
Если нужного приложения нет в списке — у Commvault есть механизм Pre/Post Scripts: можно запустить скрипт перед бэкапом (например, для создания дампа нестандартной БД) и после (для очистки). Так к расписанию и хранилищу Commvault можно подключить почти любое приложение, даже без нативного агента.
Что нужно запомнить
- Software Cache — первое, что стоит проверить перед установкой Windows-агентов с Linux CommServe. Без Windows Remote Cache или локальной установки Push Install не пройдёт.
- File System Agent защищает не только файлы, но и System State. Для контроллеров домена System State обязателен — иначе AD не восстановить.
- Microsoft Active Directory Agent даёт гранулярное восстановление отдельных пользователей, групп и GPO без перезагрузки DC. Три сценария: Non-Authoritative (обычное), Authoritative (откат изменений), гранулярное (точечное).
- Для Microsoft SQL Server нужен Full Recovery Model, если требуется восстановление на точку во времени. Transaction Log бэкап + Point-in-Time Recovery дают точность до секунды.
- Метод бэкапа Microsoft SQL Server выбирается по размеру базы: streaming для небольших, IntelliSnap для крупных (снимает нагрузку с продуктивного сервера), Block-Level как компромисс.
- Microsoft Exchange умеет и бэкап, и архивирование. Backup для восстановления, Archiving (stubbing) — для разгрузки почтовых серверов. Это разные операции, и путать их нельзя.
- Большинство агентов работают по общей логике: установка на сервер, взаимодействие через API или VSS, application-consistent бэкап, гранулярное восстановление. Для приложений без нативного агента есть Pre/Post Scripts.