Что я нашел для себя интересного в Veeam Backup and Replication v12 Beta2

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

Формат статьи – вольный и без структурированного порядка. Добро пожаловать под кат.

Первое, что можно заметить уже при инсталляции VBR 12 – возможность выбрать в качестве базы данных PostgreSQL:

После инсталляции, на сервере с VBR можно обнаружить Postgre с созданной базой VeeamBackup:

Несомненные плюсы – экономия на лицензиях MS SQL, поскольку в инсталляциях чуть выше средних, стандартной БД, идущей в комплекте (MS SQL Express) может не хватить.

Вроде хорошо, но не совсем –  Система мониторинга и отчётности Veeam ONE на текущий момент использует MS SQL, а значит, избавиться от необходимости в использовании данной БД могут только те, у кого не используется VeeamONE.

После установки, оказавшись в консоли VBR в верхней части можно заметить новую кнопку – Best Practices Analyzer:

Как можно сделать вывод из описания – BPA отражает ряд рекомендаций по конфигурации операционной системы, а также самого VBR в области безопасности и доступности.

Для проверки я перевел службу Remote Registry в режим Disabled и запустил проверку BPA с помощью Re-Check:

Статус, ожидаемо, изменился с Violation на Passed.

Поскольку это чистая инсталляция, было бы неплохо добавить репозиторий. Обратим внимание на Object storage:

И сравним с тем, что было в версии 11:

В 12 версии мы можем использовать объектное хранилище в качестве основного репозитория. К сожалению, под рукой у меня его нет, поэтому пока продемонстрировать работу я не могу.

Пройдем дальше, по пути добавления стандартного репозитория. В меню Advanced скрылся интересный флаг, который теперь является значением по-умолчанию:

Да, теперь Use per-machine backup files является основным форматом хранения резервных копий. Для тех, кто его ранее не использовал, поясню – использование данного формата увеличивает скорость выполнения резервных копий за счет использования отдельного файла резервной копии для каждой виртуальной машины, тем самым увеличивая одновременное количество потоков.

Маленький минус данного функционала – снижение показателей дедупликации, которую выполняет Veeam, поскольку дедупликация ограничена рамками файла резервной копии, т.е. одной машины. Однако, в случае использования файловых систем с дедупликацией, например, ReFS, заметной разницы быть не должно.

Для тех, кто и ранее использовал per-machine backup files, будет так же на что обратить внимание. Ранее, файл метаданных для задачи был один общий, при этом у каждой VM был свой файл резервной копии. В версии 12, для каждой виртуальной машины создается свой файл метаданных и называется это True per-machine backup files:

Теперь заглянем в секцию бэкапов. На текущий момент у меня есть несколько резервных копий, находящихся в репозитории, созданном по умолчанию:

Что мы могли сделать здесь в версии 11? – Удалить бэкап с диска, удалить из конфигурации, либо посмотреть его свойства.

Кликнем по нему правой кнопкой в V12:

Три новых возможности.

Move backup – переносит резервные копии из одного репозитория в другой:

После выбора репозитория, открывается окно со статусом перемещения. Я решил перенести бэкапы в только что добавленный репозиторий:

Важный момент – репозиторий в задаче резервного копирования меняется автоматически на тот, куда были перенесены резервные копии:

Copy backups – скопировать бэкапы. Примечательно, что скопировать их можно не только в репозиторий:

 После копирования, бэкап попадает в раздел Imported:

Удалив копию отсюда, она будет так же удалена с диска.

Detach from job – “Отцепить” резервную копию от задачи:

Резервная копия будет перенесена в раздел Backup – Orphaned (копии, которые не относятся ни к одной задаче).

Для выполнения данной операции задачу резервного копирования нужно предварительно перенести в режим Disabled.

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

Прикрепить файлы резервной копии можно обратно с помощью Map backup в настройках задачи резервного копирования:

И не уходя далеко из экрана выше. Теперь можно без каких-либо проблем сменить репозиторий для задачи резервного копирования. Даже если к задаче относятся какие-либо резервные копии.

Достаточно просто указать новый репозиторий в настройках задачи:

Далее будет два варианта – начать новую цепочку резервных копий в указанном репозитории, либо перенести туда существующие, причем в автоматическом режиме.

При начале новой цепочки, существующие копии будут перенесены в секцию Orphaned.

Очень долго я хотел подобный функционал и вот он здесь.

Побродив немного по настройкам задачи резервного копирования, можно встретить Application-Aware Processing для PostgreSQL:

Вернемся к списку задач резервного копирования. Как часто просят сделать резервную копию для одной машины «один разок»?

Сделать это стало значительно проще. Можно выбрать любую машину из задачи и кликом правой кнопкой мыши запустить резервное копирование:

Аналогичным образом – были ошибки при бэкапе? – Сбойные машины можно перезапустить по отдельности:

Как итог, мы получаем рабочий бэкап сбойной машины и дополнительный бэкап, который был выполнен по требованию:

Если кликнуть по резервной копии виртуальной машины, можно увидеть слегка измененное контекстное меню.

Интересный функционал – Export content as virtual disks.

Функционал позволяет экспортировать диск виртуальной машины как VMDK, VHD или VHDX:

В случае с VHD и VHDX их можно сложить на какой-либо диск, в то время как VMDK можно разместить так же на хосте ESXi.

Функционал похож на ранее присутствующий Restore VM Files, но добавляет возможность конвертации дисков в разные форматы.

Через некоторое время после запуска, получаем готовый диск в требуемом формате, размещенный по указанному пути:

Теперь заглянем в главное меню, раздел Users and Roles:

Здесь нас встречают два новых пункта – Двухфакторная аутентификация и автоматическое отключение консоли при бездействии:

При включении auto logoff, в случае бездействия, консоль предупредит, что скоро произойдет автоматическое отключение пользователя:

А дальше просто откроется привычное окно с требованием указать логин\пароль для доступа.

Включение же мультифакторной аутентификации выполняется специальной отметкой:

Далее на свой мобильный телефон нужно установить приложение для двухфакторной аутентификации, например, Google Authenticator.

После входа в консоль VBR, отобразится окно для настройки MFA, где нужно отсканировать QR-код с помощью ранее установленного аутентификатора:

Сканируем код через приложение, после чего аутентификатор начинает генерировать временные пароли через определенные промежутки времени.

В консоли нажимаем Next и вводим пароль, выданный аутентификатором:

После ввода кода, доступ в консоль будет предоставлен.

Ну и закончим на сегодня еще одним пунктом из главного меню – VM Exclusions.

VM Exclusions – список виртуальных машин, которые будут исключены из обработки задачами резервного копирования, либо репликации.

Удобно, когда просят на один день «отключить бэкап» для виртуальной машины по каким-либо причинам.

Выглядит это следующим образом – в список добавляются виртуальные машины (а еще здесь можно оставить примечание, с какой целью машина была исключена):

А после запуска задачи резервного копирования они пропускаются:

Удаляем машины из списка, и они снова обрабатываются.

В качестве заключения:

Конечно же, это лишь малая часть нового функционала, и так получилось, что я осветил в основном даже не функционал, а небольшие «фишки», которое делают жизнь администраторов значительно проще.

Более серьезный функционал явно требует отдельных статей и они, скорее всего, будут позже.