Veeam Backup 8 и Hyper-V: instant recovery наконец работает на обоих гипервизорах

Есть у нас один клиент - производственное предприятие, исторически выросшее в двух направлениях одновременно. Часть серверов осела на VMware vSphere ещё в 2009-м, когда ESXi стал бесплатным, и с тех пор там живут базы данных и ERP. Другая часть - на Hyper-V, потому что несколько лет назад пришлось быстро развернуть несколько Windows-серверов, а лицензии Server 2012 R2 с правами на виртуализацию уже были куплены.

Итого: гетерогенная среда, два гипервизора в одной серверной, один инженер, который за всем этим следит. До недавнего времени и две разные стратегии резервного копирования - Veeam для VMware и нечто самодельное для Hyper-V.

Проблема с Hyper-V до восьмой версии

Veeam Backup & Replication у нас в работе давно, и для VMware-части всё было отлично. Instant VM recovery - фича, которая позволяет поднять ВМ прямо из бэкапа за несколько минут без предварительного восстановления образа на датастор - работала без нареканий. Упала критичная машина, дежурный запустил instant recovery, пользователи продолжают работать пока идёт нормальное восстановление в фоне. Живая схема.

Для Hyper-V этой возможности в Veeam не было. Бэкапы снимались, но восстановление означало: скачать образ из репозитория, развернуть на хранилище, зарегистрировать ВМ, поднять. При объёме диска в 200-500 гигабайт это несколько часов работы. RTO у клиента по факту выходил в районе четырёх часов на крупные машины.

Четыре часа - это не катастрофа для некритичных систем. Но один из Hyper-V серверов держал файловый сервер и несколько терминальных сессий. Четыре часа простоя там превращаются в очень некомфортный разговор с руководством клиента.

Что появилось в восьмой версии

Veeam Backup & Replication 8 вышел в конце 2014 года, и ключевое изменение для нас - instant VM recovery для Hyper-V. Механика та же, что для VMware: Veeam монтирует бэкап-образ как NFS-шару (или SMB3 в случае Hyper-V), регистрирует ВМ прямо оттуда и запускает её. ВМ работает с диска бэкапа, в фоне идёт миграция данных на нормальное хранилище через Storage vMotion-аналог для Hyper-V.

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

Что реально изменилось по времени восстановления:

• Старая схема - полное восстановление образа: 3,5-4 часа на ВМ с диском 400 гигабайт.
• Instant recovery - ВМ доступна пользователям: 15-20 минут. Это время на обнаружение инцидента, старт процедуры и первый вход пользователя в систему.

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

Единый инструмент для двух гипервизоров

Второй момент, который оказался важным на практике: теперь у нас одна консоль, одна политика резервного копирования, одни репорты для всей среды клиента - и для VMware, и для Hyper-V. Раньше Hyper-V-машины либо бэкапились самописными скриптами через Windows Server Backup, либо нужен был отдельный инструмент. Это означало два набора задач, два места где смотришь на статус, два разных способа восстановления.

Теперь администратор открывает одну консоль Veeam и видит все ВМ. Задачи настраиваются одинаково, restore-wizard для Hyper-V и VMware выглядят практически идентично. Это снижает вероятность ошибки при стрессе: человек действует по привычному сценарию, а не вспоминает в два ночи «как там у нас настроено для Hyper-V».

Что потребовало внимания при настройке

Не всё прошло гладко. Несколько вещей, на которые потратили время:

• SMB3 и права доступа. Instant recovery для Hyper-V работает через SMB3 - Veeam поднимает шару с бэкапом и цепляет к ней Hyper-V-хост. Права на шару должны быть настроены корректно, иначе хост не может смонтировать образ. У нас первые попытки упали именно на этом.

• Версия интеграционных служб. ВМ, которые поднимаются через instant recovery, должны иметь актуальную версию Hyper-V Integration Services. Одна из старых машин клиента, которую никто не трогал года полтора, имела компоненты двухлетней давности и стартовала с предупреждениями. Не критично, но надо проверить перед инцидентом, а не во время.

• Сетевая конфигурация при старте. ВМ после instant recovery нужно вручную подключить к нужному виртуальному свитчу - автоматически Veeam это не делает. Вписали в регламент: первые тридцать секунд после старта - подключить сеть. Мелочь, но если не знать - будешь думать что ВМ не стартовала.

Где мы сейчас

Клиент переведён целиком на managed-сопровождение с единой политикой Veeam для всей среды. Backup job покрывает 100% ВМ обоих гипервизоров, ежемесячно прогоняем тестовое instant recovery по регламенту - поднимаем одну ВМ в изолированной сети и проверяем что она загружается и нужные сервисы работают.

Первое боевое применение уже было - через месяц после перехода на Veeam 8 упал один из Hyper-V хостов из-за проблемы с контроллером. ВМ подняли через instant recovery, пока разбирались с железом. Семнадцать минут от момента алерта до того, как пользователи получили доступ.

Это не магия и не маркетинговые двадцать минут из рекламного буклета - это реальные семнадцать минут с учётом того, что дежурный сначала поставил диагноз (ещё пять минут), а потом запустил процедуру. Для сравнения: по старой схеме мы бы ещё только начинали качать образ с NAS.

Ситуация с гетерогенной виртуализацией у многих клиентов - не исключение, а скорее норма. VMware купили давно, Hyper-V добавили позже потому что дешевле или потому что так легли лицензии. Иметь один инструмент для обоих - это не про красоту архитектуры, это про то, что в три ночи не нужно вспоминать где лежит второй набор скриптов.