Veeam Backup 4.0 и дедупликация: как мы вдвое сжали хранилище резервных копий

Несколько недель назад Veeam выпустил Backup & Replication 4.0 с двумя ключевыми новинками: инлайн-дедупликацией и блочными инкрементными бэкапами VM. Мы к этому моменту уже полгода думали о замене самописных скриптов снэпшотов на ESXi - и решили наконец попробовать.

Результат оказался неожиданно конкретным: хранилище резервных копий у одного из клиентов сжалось примерно вдвое. Не за счёт тонкой настройки - просто по умолчанию.

Почему вообще меняли скрипты

После перехода нескольких клиентов на ESXi 4.0 в январе мы описывали, что самописные bash-скрипты резервного копирования пришлось переписывать с нуля - Service Console в ESXi нет, старый подход через SSH на хост не работает. Написали новые скрипты на VI Perl Toolkit: отдельная управляющая VM, снэпшоты через API, копирование VMDK по SCP на NAS.

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

Параллельно VI Perl Toolkit как инструмент для бэкапов - это самодеятельность. Нет нормальной отчётности, нет retry при ошибке, нет централизованного журнала. Что-то упало ночью - узнаёшь утром, если вообще узнаёшь.

Что изменилось в Veeam 4.0

Предыдущие версии Veeam для VMware делали блочную копию VMDK через VMware API (VADP - vStorage API for Data Protection), но без дедупликации: каждая инкрементная копия хранила полный delta-блок изменений без устранения повторов между разными VM или разными точками восстановления.

В 4.0 добавили два механизма:

• Инлайн-дедупликация. Блоки, идентичные уже сохранённым в репозитории, не записываются повторно. Работает как между разными VM, так и между инкрементами одной машины.
• Блочные инкременты на уровне изменённых секторов. Veeam отслеживает через CBT (Changed Block Tracking) VMware, какие именно блоки VMDK изменились с последнего бэкапа, и копирует только их - без снэпшот-delta логики, которую мы использовали в скриптах.

CBT в VMware появился ещё в ESX 4.0, но раньше мы его не использовали в скриптах - потому что интеграция через VADP это уже не «три строчки perl», а серьёзный объём API-работы.

Как разворачивали

Veeam Backup & Replication 4.0 - это Windows-приложение. Установили на выделенную виртуалку под Windows Server 2008 R2; консоль там же. Лицензия считается по числу сокетов хостов ESXi - у клиента два хоста, два сокета.

Добавили хосты ESXi через vCenter credentials, указали репозиторий - тот же NAS, но теперь Veeam пишет в свой формат VBK/VIB, а не в VMDK-файлы напрямую. Создали задания бэкапа: полный раз в неделю, инкрементные - ежедневно, хранить семь точек восстановления.

Первый полный бэкап ожидаемо занял несколько часов - данных немало. Дальше инкременты стали укладываться в ночное окно без проблем.

Что получилось по хранилищу

Сравнили объём резервных копий через три недели после перехода - достаточно, чтобы накопилось несколько полных и несколько инкрементных циклов.

Раньше (скрипты + VMDK-снэпшоты): около 1,4 ТБ при семи точках восстановления.

После (Veeam 4.0 с дедупликацией): около 680 ГБ при тех же семи точках.

Соотношение получилось примерно 2:1. Объясняется просто: в виртуальной среде много однотипных Windows-машин, у которых на дисках значительная часть блоков идентична - системные файлы, общие библиотеки, паттерны нулевых блоков на незанятом пространстве. Дедупликация на уровне репозитория всё это схлопывает.

Выдуманных точных процентов давать не будем - у другого клиента цифры будут другими, зависит от однородности среды. Но порядок тот же.

Что ещё понравилось

Отчётность. Каждое утро - письмо с итогами ночных заданий: сколько VM прошло успешно, сколько с предупреждениями, сколько упало. Раньше это надо было делать самим через лог-файлы на cron.

Восстановление отдельных файлов без разворачивания всей VM. В Veeam 4.0 можно примонтировать точку восстановления и вытащить конкретный файл прямо из консоли - без разворачивания VM на отдельный хост. Клиент уже воспользовался один раз: удалённый документ вернули за пять минут.

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

Цена вопроса

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

Для клиентов на сопровождении рассматриваем Veeam как замену самописным скриптам там, где среда на VMware и объём хранилища бэкапов стал проблемой. Скрипты никуда не денутся там, где бюджета на лицензию нет - но теперь есть понимание, чего это стоит в пересчёте на объём NAS.