Veeam 7 и Sure Backup: первый раз бэкап проверяет себя сам
Переводим VMware-клиентов на Veeam Backup & Replication 7.0: Sure Backup в изолированной среде и WAN-репликация в DR-сайт как новый стандарт защиты виртуалок.
Veeam Backup & Replication 7.0 в 2013 году закрепился как стандарт резервного копирования виртуальных машин.
Ноябрьское учение по DR у одного из клиентов показало неприятную вещь: бэкапы были, реплики были, а уверенности в том, что они рабочие, не было никакой. Зелёные галочки в консоли Veeam - это не то же самое, что «ВМ поднимется». После той истории мы начали смотреть на Sure Backup плотнее, и в итоге декабрь превращается в волну переводов клиентов на Veeam 7 с нормально настроенной автоматической проверкой.
Veeam Backup & Replication у нас в работе не первый год, но до седьмой версии Sure Backup воспринимался как интересная фича, которую «надо бы настроить». Настраивали редко - вручную, под конкретный запрос, забывали. Veeam 7 вышел в августе, и в нём проверка резервных копий стала достаточно удобной, чтобы включать её по умолчанию для всех новых политик.
Как работает Sure Backup
Механика простая, но именно поэтому надёжная. Veeam поднимает ВМ прямо из бэкапа в изолированной виртуальной сети - так называемый Virtual Lab. Эта сеть никуда не маршрутизируется, внутри неё крутятся поднятые машины, снаружи видит их только сам Veeam через специальный appliance. Внутри лаба Veeam гоняет тесты: пингует ВМ, проверяет, что запустились нужные сервисы, опционально - запускает кастомные скрипты.
После теста ВМ выключается, лаб сворачивается, результат пишется в отчёт. Никакого влияния на production. Занимает несколько минут на машину, запускается по расписанию автоматически.
Что мы проверяем в базовом профиле:
- ping и heartbeat - ВМ вообще загрузилась и отзывается
- сервисы Windows - список критичных сервисов поднялся (AD, DNS, SQL, что там у конкретного клиента)
- прикладной тест - для контроллеров домена скрипт проверяет, что sysvol расшарен и NETLOGON отзывается; для SQL - что база монтируется и простой SELECT проходит
Кастомные скрипты пишем под клиента по мере необходимости - это обычный PowerShell или bat, ничего сложного.
WAN-репликация в DR-сайт
Параллельно с Sure Backup у нескольких клиентов запускаем репликацию в резервную площадку по WAN. Veeam 7 умеет встроенную WAN-акселерацию - дедупликация и компрессия трафика прямо в процессе репликации, без отдельного железа. На практике это означает, что канал в 10-15 мегабит перестаёт быть ограничением для репликации средней ВМ раз в ночь.
Схема, которую мы сейчас раскатываем:
- Основная площадка - VMware vSphere 5.1/5.5, Veeam делает бэкапы на локальный NAS и реплицирует критичные ВМ в DR-сайт
- DR-сайт - у нас либо арендованный хост у партнёра, либо secondary серверная самого клиента; там стоит ESXi и Veeam Replication Target
- RPO - для большинства клиентов договариваемся на реплику раз в ночь, для критичного SQL - каждые 4 часа
Важный нюанс с WAN-акселерацией: она работает через пару «source proxy - target proxy». На каждой стороне должен стоять Veeam WAN Accelerator, и лицензируется это отдельно. Для клиентов с небольшим объёмом (десяток ВМ, несколько сотен гигабайт изменений в сутки) разница с обычной репликацией по WAN ощутимая - трафик съёживается в разы. Для клиентов с медленным каналом это вообще меняет картину с «невозможно» на «нормально работает».
Что получаем в итоге
До этого года типичная схема у клиентов выглядела так: бэкап на тейп или NAS, проверка - «ну мы же видим, что задача прошла зелёной». Восстановление - в лучшем случае раз в год вручную, обычно вообще никогда до первого реального инцидента. Что там внутри бэкапа - загадка.
Sure Backup меняет это принципиально. Каждую ночь после окончания бэкапа система сама поднимает ВМ, проверяет, что она живая и сервисы работают, и присылает отчёт. Если что-то пошло не так - утром письмо с конкретным описанием: какая ВМ, какой тест, что именно упало. Администратор получает проблему до инцидента, а не во время.
Из неприятных находок, которые уже всплыли на первой волне клиентов: у двух заказчиков бэкапы AD-контроллеров создавались без VSS-снапшота AD (нужен флаг в настройках задачи), и база Active Directory внутри бэкапа была в inconsistent state. Снаружи - зелёная галочка, внутри - мусор. Sure Backup поймал это в первый же прогон.
Managed-сопровождение включает проверку этих отчётов в рамках регулярного мониторинга - не просто «настроили и забыли».
Из того, что пока остаётся за скобками: Sure Backup не покрывает Linux-ВМ тестами так же плотно, как Windows - там только ping и heartbeat через VMware Tools, кастомные скрипты нужно писать самостоятельно и аккуратнее. Для клиентов со смешанной инфраструктурой это важно помнить.
Но главное, что изменилось: бэкап перестал быть актом веры. Теперь это верифицируемый факт, и разница между этими двумя состояниями хорошо видна в четыре утра, когда что-то падает в production.