Windows Server Backup vs Veeam: второй обзор резервного копирования для небольшого клиента

В марте мы разбирали Veeam Backup 4.0 с инлайн-дедупликацией, в июне смотрели на аппаратный дедупликатор EMC Data Domain для крупной среды. Оба раза речь шла о клиентах, где масштаб оправдывает лицензионные затраты. Теперь другой конец спектра: небольшой клиент, три виртуальные машины на Hyper-V, бюджет на отдельное решение для бэкапов не предусмотрен.

Поводом стало обновление Windows Server Backup в R2. Инструмент наконец получил то, чего ему не хватало с момента появления в Server 2008: резервное копирование на сетевые шары и блочную дедупликацию через VSS. До этого WS Backup писал только на локальный диск или внешний USB/FireWire - что для серверов смотрится немного странно.

Что появилось в R2

До обновления Windows Server Backup в 2008 (не R2) был инструментом с серьёзными ограничениями. Только локальные целевые тома, только полные резервные копии дисков, никаких сетевых шар. В R2 добавили несколько важных вещей:

• Сетевые ресурсы как цель. Теперь можно указать UNC-путь вида \\nas\backups\server01, и бэкап пишет туда. Это открывает нормальную схему с центральным NAS для небольшой среды.
• Блочный инкремент через VSS. Не покопийное копирование файлов, а отслеживание изменённых блоков через теневые копии. Инкременты стали компактнее и быстрее.
• Восстановление отдельных томов и bare metal. Присутствовало и раньше, но в R2 восстановление через WinRE стало надёжнее в части поддержки оборудования.

На бумаге - вполне пригодный инструмент для небольшой среды.

Как проверяли на клиенте

Клиент - небольшая компания, один хост Hyper-V на Windows Server 2008 R2, три гостевые VM: файловый сервер, контроллер домена, 1С. Раньше бэкапы были честно устроены через Robocopy с расписанием по Task Scheduler - то есть фактически никакой резервной копии в нормальном смысле не было. Решили параллельно протестировать WS Backup и Veeam, чтобы дать клиенту обоснованную рекомендацию.

Настройка WS Backup заняла минут двадцать: открыли Server Manager, добавили компонент, указали расписание и UNC на NAS. Гостевые VM бэкапились через Hyper-V VSS writer - то есть снэпшоты делались корректно, с application-consistent состоянием для тех приложений, у которых есть VSS writer.

Veeam для Hyper-V тогда был в версии, заметно уступающей VMware-ветке по зрелости. Тем не менее базовый сценарий работал: агент-free бэкап VM через Hyper-V API, инкременты, репозиторий на том же NAS.

Где WS Backup справляется, а где нет

Для трёх VM встроенный инструмент вполне пригоден. Инкрементные бэкапы укладываются в ночное окно, на NAS пишется разумный объём, восстановление целой VM из консоли работает. Если нужно поднять упавшую гостевую машину - делается это через Hyper-V Manager плюс процедура восстановления из бэкапа, не самая удобная, но работающая.

Разница начинается там, где нужно восстановить не всю VM, а конкретный файл. У WS Backup процедура такая: примонтировать точку восстановления, найти файл, скопировать вручную. Делается это через командную строку или через Explorer, но отдельного UI для восстановления файлов нет. Для клиента, которому ИТ-отдел объясняет, как вернуть удалённый документ, это сложновато.

У Veeam есть отдельный мастер восстановления файлов: выбираешь VM, выбираешь точку восстановления, дальше Explorer прямо по содержимому диска. Для конечного пользователя разница ощутима.

Скорость восстановления - главный зазор

Тест восстановления целой VM показал разницу, которую сложно объяснить одними возможностями интерфейса. WS Backup при восстановлении виртуальной машины целиком фактически возвращает всю копию тома с хоста. На трёх VM это работает терпимо - но при увеличении числа машин время восстановления растёт пропорционально объёму всего резервируемого набора, а не конкретной VM.

Veeam хранит каждую VM отдельно в своём формате VBK/VIB. Восстановление одной VM не зависит от того, сколько ещё VM в репозитории. Если завтра у клиента станет не три, а десять VM, разница в RTO будет уже не академической.

Для нынешних трёх машин мы провели несколько пробных восстановлений - разница есть, но не критичная. Для клиента с таким парком WS Backup закрывает базовую потребность. Но если инфраструктура начнёт расти, этот же клиент быстро почувствует ограничения.

Итог по ситуации

Рекомендация для данного клиента вышла такой: пока это Hyper-V с тремя VM и нет внятного бюджета на Veeam - Windows Server Backup настраиваем и мониторим. Настроили ежедневные инкременты на NAS, раз в неделю полный бэкап, проверку через задачу в Task Scheduler с отправкой результата по почте.

Veeam для этого клиента - разговор на будущее, как только парк VM перевалит за пять-шесть машин или появится требование к RTO. Лицензия считается по сокетам хоста - для одного сокета цена уже обоснована, если восстановление действительно критично.

В рамках сопровождения инфраструктуры мы сейчас чаще всего именно так и делаем: встроенный WS Backup как рабочее решение для малого парка, Veeam - для тех, кому скорость восстановления и granular recovery действительно нужны. Разрыв между ними есть, и он вполне измеримый.