Используем Veeam agent бекап для перезда от одного облачного провайдера к другому

Veeam Windows и Linux агенты были разработаны для той части ресурсов, которые не могли быть по тем или иным причинам виртуализованы. Компания Veeam года 3 назад призналась в том, что была неправа относительно того, что все мощности можно виртуализировать и начала разработку агентов. Но сегодня разговор не о самих агентах, а о том, как с их помощью можно выполнить переезд виртуальных машин от одного облачного провайдера к другому, если у вас нет доступа к управлению виртуальными машинами.

Ситуация довольно проста — есть облачный провайдер X, который предоставляет заказчику виртуальные мощности, при этом у заказчика нет доступа к управлению этими ресурсами, а только внутрь самих виртуальных машин. Владелец ресурсов решил сменить облачного провайдера и возник вопрос — каким образом, с минимальными потерями можно осуществить эту задумку. Одним из решений и стало использования Veeam Windows Agent для решения поставленной задачи, процесс которой я сегодня и опишу.
Предварительно на стороне провайдера Y был развёрнут в виртуальной машине сервер VBR, на который предполагалось заливать бекапы. На все клиентские машины были установлены агенты и настроен бекап на сервер VBR провайдера Y. Далее у нас может быть несколько путей:

1. Залить и на лету сконвертировать бекап в файлы виртуальных машин и положить их на датастор. Проблем в том, что у вас должен быть доступ к этому датастору посредствам NFS.
2. Сконвертировать бекапы в файлы виртуальных машин вручную и залить на датастор средствами SCP.

В обоих случаях одна и та же проблема — ни один сервис провайдер не даст заказчику доступа до своих серверов. Конечно в некоторых случаях можно передать файлы сервис провайдеру, чтобы они залили их сами, но это усложняет последовательность действий и растягивает время переезда, а, как и при любом переезде IT ресурсов, время и время простоя для нас главное.
Остаётся последний вариант — восстанавливать виртуальные машины также при помощи Veeam Windows Agent, как вы бы это делали, если бы восстанавливали физический сервер.
Для начала нам необходимо сделать Recovery Media, с которого мы будем загружать наши виртуальные машины. В случае с физическими сервера, пришлось бы делать для каждого отдельный загрузочный диск (если у вас все серверы не в единой конфигурации) что бы получить в комплекте все необходимые для работы всей периферии драйверы.

В случае же с виртуальными машинами у нас идентичные конфигурации оборудования, за исключением памяти/процессоров, так что для нашей задачи хватит одного образа под каждый тип ОС. Предварительно создаём виртуальные машины в необходимой конфигурации и загружаемся с этого образа. Далее при помощи мастера, по сети, с сервера VBR указываем бекап, который мы собираемся развернуть на данной машине и запускаем процесс восстановления.
Из минусов тут можно отметить то, что восстановление дисков проходит в один поток, поэтому если у вас виртуальная машина с несколькими большими дисками, то для ускорения процесса восстановления можно пойти другим путём: предварительно развернуть несколько машин и установить на них ОС и агентов. Каждой машине создать по одному диску от нашей большой ВМки необходимого размера и на каждой из них запустить восстановление отдельного диска, а уже после восстановления дисков собрать их в одну директорию и привязать к необходимой целевой ВМ. Это позволит восстанавливать диски в несколько поток и сократить время восстановления.

Когда я изначально задумывал описать данный кейс, мне казалось, что материал будет более “остросюжетный”. Но возможно этот небольшой мануал кому то поможет в будущем.