Дедупликация в Veeam 6.5: переводим трёх клиентов и смотрим на коэффициент

Последние две недели августа у нас прошли под знаком миграции резервного копирования. Трое клиентов на сопровождении, у каждого своя история: один делал бекапы через скрипт на базе VSS и xcopy, второй использовал Backup Exec 2012 с агентами на каждой ВМ, третий - Veeam 6.1, но без включённых опций сжатия, потому что «поставили как есть». Всех трёх мы перевели на Veeam Backup & Replication 6.5 с правильно настроенными дедупликацией и компрессией, и теперь можно говорить о первых наблюдениях.

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

Veeam 6.5 вышел с поддержкой vSphere 5.1, а мы как раз в начале августа разбирались с vSphere Replication 5.1 у одного из клиентов. Логично было не тянуть с апдейтом бекапного слоя: новая платформа, новый инструментарий бекапа - всё в один заход.

Встроенная дедупликация в Veeam работает на уровне блоков внутри задания: продукт сравнивает блоки данных между разными ВМ одного job-а и не пишет одинаковые блоки дважды. Сжатие идёт поверх. Всё это происходит на proxy-сервере до записи на репозиторий, то есть сеть и диски репозитория получают уже обработанный поток.

Три кейса - три стартовых точки

Клиент A (xcopy + VSS). Шесть ВМ, Windows Server 2008 R2 и пара 2003-х. Бекапы складывались как полные копии раз в неделю, инкрементов не было в принципе. Каждая полная копия занимала примерно столько же места, сколько сам диск ВМ. Здесь дедупликация ударила сильнее всего: Windows-образы с похожим набором системных файлов и одинаковой базой обновлений здорово пересекаются по блокам. После нескольких прогонов Veeam репозиторий показал коэффициент около 3.2:1 - это сочетание дедупа и сжатия, разделить их в интерфейсе нельзя, только суммарно.

Клиент Б (Backup Exec с агентами). Девять ВМ, смешанная среда: Windows и пара Linux. Backup Exec работал, но агентные лицензии стоили отдельно, агент на Linux регулярно капризничал. Миграция потребовала перестройки всей схемы задний - в Veeam не нужен агент внутри ВМ для VMware-бекапа, всё через vSphere API. Коэффициент вышел около 2.8:1. Linux-образы дедуплицируются хуже Windows: ext4 с разными inode-раскладками даёт меньше совпадений по блокам, чем NTFS с типовой структурой каталогов.

Клиент В (Veeam 6.1 без настроек). Здесь работы было меньше всего: обновили продукт, включили дедупликацию и компрессию в настройках job-ов, пересчитали сeed-бекапы. Коэффициент поднялся с примерно 1.3:1 до 2.9:1. То есть продукт был, а экономия не работала просто потому что при первоначальной установке никто не тронул дефолтные настройки.

Что стоит держать в голове

Память proxy-сервера. Дедупликация Veeam работает in-memory: чем больше RAM у proxy, тем выше дедуп-ratio, потому что продукт может сравнивать блоки из большего окна. На слабых серверах с 8 ГБ мы видели заметно скромнее цифры, чем на машинах с 16+ ГБ.

Режим компрессии. Optimal - разумный выбор по умолчанию. High заметно нагружает CPU proxy, при этом прирост по месту невелик. Extreme вообще не рекомендуется для большинства сред - выигрыш исчезающий, а нагрузка ощутимая.

Дедупликация между job-ами не работает. Это принципиально: если у вас десять job-ов на разные группы ВМ, каждый job дедуплицирует внутри себя, но не с соседними. Для среды с множеством однотипных Windows-серверов стоит группировать похожие ВМ в один job, иначе часть потенциала теряется.

Время восстановления не изменилось. Это важно: клиенты иногда думают, что сжатые бекапы медленнее восстанавливать. На практике восстановление конкретной ВМ из Veeam занимает примерно то же время, что занимало раньше - узкое место в обоих случаях сеть или дисковая система репозитория, а не распаковка.

Итог первого месяца

Три клиента, разные отправные точки, результат в целом сходится к коэффициенту 3:1 на типичных Windows-образах. Репозитории сократились на 60-70% физически, лицензионная нагрузка у клиента Б снизилась за счёт отказа от агентных лицензий Backup Exec.

Остался один открытый вопрос: как поведёт себя дедупликация через три-четыре месяца, когда накопится история инкрементов и Windows получит очередной пакет обновлений. Цикл обновлений меняет значительную часть системных файлов, и коэффициент теоретически может немного упасть. Посмотрим в конце года.