Veeam Backup & Replication V11: агенты

Продолжаем наше знакомство с новой версией Veeam Backup& Replication. И сегодня у нас на очереди будут агенты.

Но прежде чем приступить к самим агентам, поговорим о новом функционале деплоя агентов, который появился в 11 версии. Не всем заказчикам было удобно деплоить агентов с сервера VBR. Да и необходимость указания учётных данных от всех машин — тоже не самый удобный механизм. Установка агента вручную предполагала его ручную настройку, что также усложняло данный процесс. Теперь же появилась возможность подготовить бандл для установки, который помимо прочего включает в себя конфигурационный файл автоматической настройки. Для данного типа группы также изменено и поведение взаимодействия VBR с агентами — теперь не сам сервер VBR стучится к ним, а наоборот агенты сами обращаются к серверу VBR. Veeam называет новый тип группу — Catch-All Protection Group.

Далее мы указываем директорию, в которую сложим дистрибутивы агента и xml с конфигом. Также выбираем для какой операционной системы нам нужны дистрибутивы агента.

Поддерживаются агенты для Windows, Linux и новый агент для MacOS. А вот агенты для Solaris и AIX не поддерживаются, т.к. не управляются сервером VBR. После создания группы, в директории (которую мы указали для выгрузки дистрибутивов) мы можем наблюдать их, файл readme (который содержит информацию по установке) и файл конфигурации.

Файл конфигурации содержит ключ сертификата и адреса нашего VBR сервера, на которые будут пытаться обращаться клиенты.

После этого нужно либо расшарить эту директорию на сервере VBR, либо переложить дистрибутивы куда-то вручную и задеплоить на серверах удобным для вас способом — через AD или ansible, например. После самого деплоя необходимо импортировать конфигурационный файл при помощи команды на сервере с агентом:
veeamconfig mode syncnow
т.к. в данном режиме у нас агент самостоятельно стучится на сервер VBR, необходимо вручную синхронизироваться с сервером со стороны агента, т.к. в автоматическом режиме это происходит раз в 6 часов. После чего наши машины становятся видны в protection группе и мы можем создавать задания на резервное копирование. Появление данного функционала — это расширение гибкости деплоя агентов. Также есть один плюс — в данном режиме VBR не проводит рескан группы (буквально неделю назад у нас в Russian Backup User Group был человек, недовольный постоянным ресканом группы).

Вот так выглядит весь процесс схематично

Linux агент
Ему досталось в этом релизе меньше всего. Он не получил никакого значительного нового функционала. Получил лишь поддержку расширенных аттрибутов (xattr) для файлового бекапа и расширенные возможности при использовании Recovery ISO: поддержка LUKS и LUKS2, расширенные настройки LVM, nmtui и автозапуск ssh. На этом компания Veeam решила ограничиться.

MacOS агент
Вот и новый агент появился у Veeam. Даже в России MacOS в качестве корпоративной ОС становится всё популярнее, особенно у разработчиков и топ-менеджеров. А уж в Европе и подавно. Поэтому вопрос с резервным копированием рабочих мест с MacOS стоит довольно остро. Именно благодаря запросам заказчиков Veeam и разработал новый агент. Если вы следили за жизненным циклов агентов, то скорее всего знаете, что первая версия агента для Windows вышла довольно функциональный по причине того, что была реализована на основе Veeam Endpoint Backup, а вот первая версия Linux агента была довольно простой. Такая же ситуация и с MacOS агентом. Во-первых установить его можно только посредством установки на самой рабочей станции при помощи новой Catch-All Protection Group, о которой я рассказывал в начале статьи. Установить агента напрямую с сервера нет возможности. Во-вторых работает только в режиме Managed by agent, т.е. Veeam просто деплоит на агент настройки, но само задание управляется при помощи агента, а не сервера VBR. По этой причине может быть только одно задание для каждой машины.

Резервное копирование настраивается аналогично Linux агенту — просто указываются пути до необходимых директорий. Со стороны сервера можем контролировать прохождение резервного копирования по расписанию и следить за его ошибками.

Восстановление же файлов мы можем запустить как с сервера VBR через Linux хост или FLR, правда восстановить данные в оригинальное расположение невозможно, только скопировать куда-то ещё, например, на сервер VBR.

Но на самой MacOS через агента восстановить файлы уже можно куда угодно.

Резервные копии можно хранить как в репозитории VBR, в том числе в SOBR и на deduplication appliance, так и отправлять резервные копии на прямую в облако сервис провайдера через CloudConnect и хранить их там. Бекап происходит по аналогии с остальными агентами — используя снепшоты ОС, в данном случае APFS, но если помимо локальных дисков вы бекапи ещё и USB девайс, здесь снепшоты уже не используются.
Поддерживаются версии MacOS начиная с 10.13, Big Sur в том числе.
Подводя итог можно сказать — хорошо, что у нас появился новый агент, плохо пока то, что функциональность его на раннем этапе развития. Очень надеюсь, что его развитие будет очень активным.

Windows  агент
Самое интересное на мой взгляд я оставил на закуску — Windows агент. Вообще Windows агент у Veeam является пожалуй технологическим флагманом в своём роде, т.к. он наиболее функциональный из всех и все новые и интересные функциональные возможности появляются сначала именно в нём. И самое главное, что появилось в новой версии агента — это поддержка снепшотов СХД. Да, об этом давно спрашивали, значит есть такая потребность. Но без ложки дёгтя не обойтись — поддерживается работа только на тех машинах, у которых есть прямой выход в SAN, т.е. это или физические серверы, или виртуальная машина с доступом в SAN, но никаких проброшенных дисков через систему виртуализации — про RDM забываем сразу.
И так, теперь при интеграции Veeam с СХД у нас появилась возможность выбора — для каких целей мы их скрещиваем.

С VMware всё понятно, просто добавился флажок. Насколько мне известно — в механизме работы со снепшотами СХД для VMware ничего «внешне» не изменилось. И, соответственно, у нас появились пункты для NAS бекапа (о нём поговорим отдельно в другой раз) и Агентский бекап.

Поддерживается FC и iSCSI. А вот про поддержку NVMEoF пока не слышно. Вопрос то собственно в этом случае не столько в скорости или времени отклика, сколько в доступности по протоколам.

И теперь в настройках задания у нас так же появилась вкладка Integration, на которой мы можем включить поддержку стораджовых снепшотов и фэиловер на классический метод по сети.
Теперь немного о терминологии. Off-Host Backup Proxy нам уже знаком, если хорошо помнить всю доку или иметь дело с Hyper-V. Там Off-Host Backup Proxy используется уже давно. Тут ограничения в целом те же — это должен быть сервер на Windows, с той же версии или выше, чем установлена на машине с агентом (но не ниже 2012R2).  Но при этом, используется прокси с ролью File Backup, которая появилась у нас в 10 версии для бекапа NAS. Вероятнее всего, роль File Backup Proxy будет к моменту релиза 11-й версии переименована, т.к. теперь подобные записи в логе задания могут немного смущать: Importing snapshot set on off-host backup proxy File Backup Proxy.
Дальше логика работы аналогично механизму на VMware — делаем VSS снепшот, затем делаем снепшот на сторадже, монтируем это на Off-Host и льём данные. Схематично это выглядит вот так.

Локальные для сервера (физические) диски будут копироваться традиционным способом с этого сервера по сети, а те диски, что подключены к серверу с СХД — будут тянуться через File Proxy со снепшотов.

При этом в логе таска нет явного указания на использование стораджового снепшота как это есть сейчас в случае с VMware. Но использование off-host backup proxy как раз говорит нам об этом. Для тех, кто не верит — можно посмотреть лог-файл задания и увидеть работу с NetApp’ом в моём случае

И собственно сам снепшот на СХД

На этом с агентами мы закончим, но не закончим с v11. Продолжение уже скоро!