Veeam Backup & Replication 3.0: бэкап VM за 2 минуты вместо скриптов

Бэкапы виртуальных машин - это та область, где все примерно знают, что делать, и примерно делают это по-разному. У нас долгое время жил набор скриптов: VCB создаёт snapshot, rsync тащит данные на NAS, cron это всё крутит, ещё один скрипт присылает письмо если что-то пошло не так. Работало. Примерно.

Проблема была не в том, что схема ломалась - она держалась вполне прилично. Проблема в том, что восстановление VM в реальном времени - это процедура с остановками: скопировать файлы обратно, зарегистрировать VM в vCenter, запустить. Час-полтора при нормальном раскладе, больше если что-то не так с данными или с сетью между хранилищами.

В июне вышел Veeam Backup & Replication 3.0 с официальной поддержкой vSphere 4 через VADP. Мы подождали пару недель, убедились что релиз не горит, и поставили на тестовую ферму одного из клиентов.

Почему именно сейчас

Весной, когда поднимали тестовый стенд на vSphere 4, стало понятно, что VADP - это другой уровень работы с дисками виртуальных машин. Без VADP любой бэкап-агент работает через хост: создаёт snapshot, читает данные через гипервизор, удаляет snapshot. С VADP агент получает прямой доступ через транспортный слой - хост не узкое место, stunned snapshot длится доли секунды, а не десятки.

Veeam 3.0 - один из первых продуктов, который это реализовал полноценно, а не в виде бета-фичи с оговорками. Плюс к этому появился Instant VM Recovery - и вот это уже интересно по-настоящему.

Что такое Instant VM Recovery

Суть простая: вместо того чтобы сначала копировать файлы VM из бэкапа на рабочее хранилище и только потом запускать машину, Veeam монтирует бэкапный файл напрямую как хранилище и запускает VM прямо оттуда. Машина поднимается, пока данные по-тихому мигрируют на основной датастор. Для VM это выглядит как обычный старт - она не знает, что читает с NAS через смонтированный бэкап.

На практике это значит: от команды "восстановить" до работающей VM - 2 минуты. Вместо часа.

Есть нюанс производительности: пока VM работает с бэкапного хранилища, IO идёт через NAS, это медленнее. Но для задачи "поднять сервис пока разбираемся" - это ровно то, что нужно. Параллельно Storage vMotion переносит диски на основное хранилище, и VM незаметно переезжает без перезапуска.

Учебная тревога

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

С Veeam 3.0 прогнали учебную тревогу прямо на рабочей инфраструктуре, в изолированном сетевом сегменте который Veeam поднимает сам. Выбрали файловый сервер из вчерашнего бэкапа, запустили Instant VM Recovery, параллельно запустили восстановление в изоляции.

Результат:

• Время до первого пинга VM - 2 минуты с момента клика в консоли. Не до завершения копирования - до работающей виртуалки.
• Доступность файлового ресурса - ещё через полторы минуты. Итого чуть больше 3 минут до работающего сервиса.
• Данные - актуальны на вчерашний вечер, что соответствует расписанию бэкапа.

Клиент посмотрел на хронометраж и спросил "и это всё?". Да, это всё.

Что поменялось в ежедневной работе

Скрипты на VCB ушли полностью. Veeam берёт на себя всё: расписание, создание snapshot через VADP, передачу данных, ротацию, отчёты по почте. Консоль centralized - видно состояние всех заданий сразу, а не разбирать логи с нескольких серверов.

Из того, что понравилось отдельно:

• Changed Block Tracking - Veeam при инкрементальном бэкапе читает только изменённые блоки на уровне VMDK, это не эвристика по меткам файловой системы, а реальные изменённые блоки VMware-уровня. Инкремент занимает ровно столько, сколько реально изменилось.
• Проверка бэкапа - есть задание SureBackup, которое поднимает VM из бэкапа в изоляции и гоняет heartbeat-тест. Автоматически, по расписанию. Мы не проверяли бэкапы системно в предыдущей схеме - руки не доходили. Теперь это делается само.
• Дедупликация и компрессия на уровне самого Veeam - дополнительная экономия места до того, как данные уходят на бэкапный таргет.

Что не так хорошо

Лицензионная модель по-прежнему считается per-socket. Для маленьких конфигураций это дорого: платишь за мощность хоста, независимо от количества VM. Четыре VM на двух хостах - и уже два сокета. Для клиентов с серьёзной виртуализацией цена обоснована, для тех у кого два-три сервера виртуализованы "на пробу" - надо считать.

Консоль требует Windows, что для нас небольшая неудобность - часть инфраструктуры под Linux. Но это ожидаемо для продукта такого класса.

Поддержка ESXi Free (без vCenter) через VADP в версии 3.0 ограничена. Для клиентов, которые используют бесплатный ESXi, полноценный VADP-бэкап через Veeam требует платной лицензии vCenter. Это не баг Veeam - это архитектурное ограничение VMware, VADP без vCenter не работает. Но для некоторых клиентов это ломает экономику.

Итог

Для инфраструктуры с vSphere 4 и достаточным количеством VM, чтобы обосновать лицензию, Veeam B&R 3.0 - замена скриптам без компромиссов. Instant VM Recovery отвечает на вопрос "сколько нам стоит простой сервиса" реальным двухминутным RTO, а не надеждой что всё пройдёт по плану.

В рамках сопровождения инфраструктуры начинаем предлагать Veeam как стандарт для клиентов на vSphere. Для тех, кто ещё на VCB-скриптах - план миграции делается за одну встречу.