В этом посте я расскажу о новых функциональных возможностях, которые вы сможете задействовать, обновив вашу версию Veeam Backup & Replication до 9.0. Среди разнообразия новинок, признаюсь, у меня есть несколько любимцев — и хотя с виду они могут показаться малоприметными, но они приносят большую пользу, за что и ценю. Конечно, всю массу в рамках одного поста не опишешь, поэтому сразу дам ссылочку на полный обзор новинок на официальном сайте: What’s New in Veeam Backup & Replication v9.

Вот что ждет вас под катом:

• Консоль для удаленного управления
• Новые возможности репозиториев
• Новые возможности хранения данных
• Оптимизация работы с гостевыми ОС
• Настройка копирования полного бэкапа в задании переноса

(На картинке — эксклюзивный набор пирожных, которыми мы угощались в день релиза. Спасибо TheRealGostev — успел сфотографировать, пока все не расхватали.)

Консоль для удаленного управления

В прошлом посте уже был обзор этого нового компонента. Напоминаю, что консоль позволяет подключаться к удаленным серверам Veeam backup; ее можно поставить отдельным сетапом, есть также и автоматическая установка (см. описание в User Guide). Таким образом, теперь Veeam поддерживает полностью распределенную архитектуру. В прошлых версиях компоненты Veeam.Backup.Service.exe и VeeamShell.exe вели исключительно совместное существование, а в v9 усилиями наших инженеров их взаимозависимость удалось, наконец, победить — то есть, как выразился TheRealGostev, «разделить сиамских близнецов».

Новые возможности репозиториев

В работе с репозиториями резервных копий появились новые возможности.

Во-первых, теперь любому репозиторию можно назначить сервер подключения (mount server). Это Windows-сервер, выполняющий определенную роль в инфраструктуре резервного копирования — при восстановлении на уровне файлов (FLR, file-level restore) такой сервер выполняет монтирование файлов ВМ прямо из бэкапа на свою файловую систему, как бы «подключая» их к себе. Сервер подключения можно задать на соответствующем шаге (Mount Server) мастера настройки репозитория.


Есть разные варианты задействования операции монтирования:

• Так, для восстановления файлов или объектов приложения сначала выполняется монтирование на машину, где работает консоль — чтобы пользователь мог просмотреть содержимое бэкапа и выбрать нужные для восстановления файлы/объекты, ведь инструменты для просмотра запускаются из консоли (неважно, автономной или совмещенной с сервером), будь то Veeam Backup Browser или любой из инструментов Veeam Explorers.
• После того, как будет дана команда на восстановление выбранных файлов/объектов (как правило, на машину в продакшене), с репозиторием начнет работать уже сервер подключения, и трафик пойдет между ним и целевой машиной. Это позволит ускорить восстановление в распределенных инфраструктурах.
• Если же восстановление выполнять с помощью Enterprise Manager и делать это для машин, у которых файлы гостевой ОС индексировались при бэкапе, то будет задействовано только одно подключение (как для просмотра, так и для восстановления), так что в таком варианте трафик будет всегда идти между сервером подключения и целевой ВМ.

Для владельцев лицензий Enterprise и Enterprise Plus есть возможность создавать масштабируемый репозиторий. Об этом достаточно подробно рассказывалось в статье на Хабре «о “бесконечно” масштабируемом репозитории резервных копий». Таким репозиторием проще управлять (поскольку автоматизирована рутинная задача выбора целевого хранилища из пула), вдобавок оптимизируется расход топлива места на СХД в пуле, и улучшается производительность, ибо по умолчанию включен режим «раскладывать цепочки бэкапов по машинам» (per-VM backup chains).


Для обычных репозиториев также предлагается опция хранения резервных копий «по машинам» (per-VM backup files). При использовании этой опции поток записи будет сформирован для каждой ВМ (а не для каждого задания). В результате увеличивается глубина очереди, что улучшает производительность, поскольку обслуживание одного-единственного потока (глубина очереди = 1) является для большинства СХД фактором, ограничивающим производительность. Создание же нескольких потоков (глубина очереди ~= N, то есть числу задач на репозитории) очень даже помогает делу.


Кроме того, стало возможным создавать задания большего объема без оговорок насчет трудностей с контролем над большими бэкапами. С выходом v9 наши системные архитекторы готовятся пересмотреть рекомендации о количестве ВМ, включаемых в одно задание — например, доведя его до 250-300. Во всяком случае, наше собственное тестирование подтвердило возможность обработки заданий, содержащих 5 000 виртуальных машин.

Разумеется, при планировании и настройке заданий резервного копирования нужно помнить, что ряд операций — например, создание синтетического бэкапа, задания Backup Copy Jobs (перенос бэкапа на резервную площадку) и др. — будут ожидать, когда отработает бэкап всех ВМ. По этой причине гигантские задания создавать не рекомендуется.

Важно! После того, как вы выбрали опцию хранения бэкапов Use per VM-backup files, ее нужно активировать, выполнив операцию создания активной полной резервной копии (Active Full) либо в ручном режиме, либо дождавшись срабатывания по расписанию.

Еще пара моментов: помним, что дедупликация на стороне источника никуда не денется. И второе — при создании новых репозиториев на СХД EMC DataDomain (с DDBoost), HP StoreOnce (с Catalyst) и ExaGrid (с Accelerated Data Mover) данная опция включается по умолчанию, но на всякий случай рекомендуется это проверить, равно как и другие рекомендуемые для этих СХД настройки.

Новые возможности хранения данных

После обновления новые возможности Veeam Backup & Replication по умолчанию будут отключены. Чтобы начать их использовать, вам следует перенастроить существующие задания резервного копирования. Замечу, что первые две опции из списка ниже были ранее доступны только для заданий переноса резервных копий (Backup Copy Jobs). Теперь же их можно использовать и при создании других типов заданий. Вот эти новые возможности:

Дефрагментация и сжатие. Использование этой опции будет полезно, если ваше задание резервного копирования не включает периодическое создание полного бэкапа (active full backup), и при этом политика хранения данных предполагает периодическое объединение файла полной копии с ближайшей инкрементальной копией. Такая трансформация приводит к тому, что файл бэкапа становится фрагментированным и в нем образуются «пустоты». Пустоты образуются также и в том случае, когда из задания резервного копирования была удалена часть ВМ (после их удаления из бэкапа сам файл не становится меньше). Чтобы уменьшить размер файла, а также несколько увеличить скорость работы с ним вы можете включить опцию Defragment and compact full backup file. Она работает следующим образом: в указанное время Veeam Backup & Replication будет создавать пустой файл VBK и копировать туда только нужные блоки из файла бэкапа, полученного в результате трансформаций. Для этой опции есть ограничения, которые описаны в User Guide.

Проверка работоспособности и самовосстановление. Чтобы быть уверенным в том, что резервные копии не повреждены, в дополнение к SureBackup вы можете активировать опцию Perform backup files health check. В этом случае при создании каждой резервной копии Veeam Backup & Replication будет вычислять хэш и контрольную сумму созданного файла. Затем перед началом следующего резервного копирования Veeam Backup & Replication заново вычислит хэш и контрольную сумму файла и сравнит ее с сохраненными ранее значениями. Если обнаружится, что данные файла были повреждены, Veeam Backup & Replication заменит поврежденные блоки, скопировав требуемые данные из исходной ВМ или из предыдущей резервной копии.


Исключение блоков, помеченных как удаленные. Удаляя файлы в NTFS, вы на самом деле не очищаете блоки данных, которые содержат файл, а помечаете их как удаленные. Поэтому зачастую при создании резервной копии образа ВМ (image-based backup) размер файла резервной копии может сильно превышать размер, отображаемый в файловой системе. До недавнего времени единственным способом избежать копирования «удаленных» данных было использование утилиты sdelete (SysInternals) перед началом резервного копирования. В Veeam Backup & Replication v9 вы можете активировать опцию BitLooker, чтобы перед началом резервного копирования Veeam анализировал раздел MFT и не копировал блоки, помеченные как удаленные.


В статье «Вышла новая версия решения Veeam Backup FREE Edition: краткий обзор» более детально рассказывается, как работает BitLooker. В настоящее время эта технология ожидает получения патента.

Важно! В коммерческой версии Veeam Backup & Replication после апгрейда эта опция отключена по умолчанию — ее удобно активировать с помощью команд PowerShell:
asnp VeeamPSSnapin; Foreach ($job in Get-VBRJob) {
$job.Options.ViSourceOptions.DirtyBlocksNullingEnabled = $true;
$job.SetOptions($job.Options) }


Новые возможности работы с гостевыми ОС

Оптимизация взаимодействия с гостевыми ОС. В инфраструктуре резервного копирования, построенной на базе Veeam Backup & Replication v9, появился новый компонент — Guest Interaction Proxy. Он предназначен для взаимодействия сервера резервного копирования с гостевой ОС (раньше это взаимодействие осуществлялось самим сервером резервного копирования, что сильно увеличивало нагрузку на него). Если вы настроите автоматический выбор машины для роли Guest Interaction Proxy, Veeam выберет менее загруженную машину, находящуюся на той же площадке, что и ВМ, для которой планируется выполнить резервное копирование. Такой подход упрощает резервное копирование в удаленных офисах и филиалах (взаимодействие компонентов происходит быстрее, когда они находятся на одной площадке) и не требует использования VMware VIX.


Исключение ненужных файлов при резервном копировании. Эта возможность является частью технологии BitLooker: при резервном копировании Veeam также анализирует раздел MFT и создает кэш в памяти прокси-сервера, в котором помечает, какие файлы и папки нужно исключить. В ходе резервного копирования чтение данных происходит одновременно с исходной ВМ и из кэша. Важно отметить, что исключение файлов возможно только если вы активировали опцию резервного копирования с учетом состояния приложений (application-aware image processing). При этом исключение множества маленьких файлов обрабатывается медленнее, чем исключение нескольких больших файлов того же размера, ибо обработка исключений увеличивает нагрузку на прокси-сервер. Например, чтобы исключить из резервной копии 100 000 файлов, потребуется 400 МБ памяти на прокси-сервере.

Настройка копирования полного бэкапа в задании переноса

Ну и еще одна операция теперь автоматизирована — раньше для создания полного бэкапа для задания переноса резервной копии (backup copy job) пользователи использовали скрипт PowerShell, а теперь можно просто поставить галочку Read the entire restore point from source backup instead of synthesizing it from increments на шаге Target при настройке задания.


Эта опция полезна для СХД с невысокой производительностью, на которых преобразовывать файлы, синтезируя полный бэкап из инкрементальных, неэффективно, а гораздо удобнее скопировать полный бэкап.

Вместо заключения

Помимо приведенных выше ссылок, рекомендую к прочтению (пока на англ. языке):

• Описание процесса сохранения резервных копий per VM-backup
• Что такое сервер подключения (mount server) и как он работает
• Про оптимизацию работы с гостевыми ОС

Ресурсы на русском языке:

• Видеообзор масштабируемого репозитория
• Видеообзор решения Veeam Availability Suite 9.0