Veeam Backup & Replication 5: первый бэкап 2 ТБ за ночь и 60% экономии на NAS

Около двух лет мы держали бэкапы VMware-сред на самописных скриптах: snapshot API + robocopy на NAS. Работало - в том смысле, что данные копировались. Но каждый раз, когда нужно было восстановить конкретную ВМ, начинался квест: найти нужный снапшот, примонтировать вручную, вытащить VMDK, подождать. RTO в таких условиях - понятие очень приблизительное.

После выхода Veeam Backup & Replication 5.0 решили дать ему шанс. Поставили на тестовую среду одного из клиентов - около 30 ВМ на VMware vSphere 4.1, суммарно порядка 2 ТБ данных. Что получилось - рассказываем.

Первый полный бэкап

Настройка заняла часа три с учётом изучения интерфейса. Veeam ставится как обычное Windows-приложение, подключается к vCenter через API, дальше - визард, который проводит за руку. Никаких агентов внутри ВМ для резервного копирования не нужно: Veeam работает через VMware VADP (vStorage APIs for Data Protection) и делает снапшот на уровне гипервизора.

Первый полный бэкап всех 30 ВМ завершился за ночь. Это само по себе стало приятным сюрпризом - раньше полное копирование через robocopy растягивалось на двое суток при малейшей нагрузке на NAS.

Дедупликация и компрессия отработали прямо при записи. Итоговый размер на NAS - примерно 40% от исходного объёма. Цифра хорошая, хотя на разных клиентских средах она явно будет отличаться: ВМ с SQL Server dedupeируются хуже, чем файловые серверы с похожими документами. На этом клиенте микс оказался удачным.

Инкрементальные бэкапы - отдельная история. Veeam использует Changed Block Tracking (CBT) от VMware: гипервизор ведёт журнал изменённых блоков с момента последнего снапшота, и Veeam забирает только их. Ночной инкрементал на 30 ВМ укладывается в 40-50 минут. Robocopy об этом мог только мечтать.

Репликация: горячий резерв на второй площадке

У клиента есть небольшая резервная площадка - туда ходит отдельный канал и стоит один ESXi-хост. Veeam 5 умеет репликацию ВМ напрямую между хостами: берёт снапшот источника и передаёт дельту на реплику. По сути - живая копия каждой ВМ на втором хосте, отстающая от боевой на интервал репликации.

Мы настроили репликацию для пяти критичных ВМ с RPO 4 часа. При аварии на основной площадке эти машины поднимаются на резервном хосте вручную через несколько кликов в vCenter. Не автоматический failover, но для клиента такого размера этого достаточно.

Учения: RTO 15 минут

Это самая важная часть. Настроить бэкап несложно - сложнее убедиться, что восстановление реально работает, когда нужно. Договорились с клиентом на плановые учения в субботу утром.

Сценарий: ВМ с файловым сервером «падает» (просто выключаем), задача - поднять её и убедиться, что пользователи могут работать.

Veeam предлагает несколько вариантов восстановления. Мы взяли Instant VM Recovery - это когда ВМ запускается прямо с бэкап-хранилища, пока данные мигрируют обратно на датастор в фоне. Через 4 минуты ВМ уже загружалась. Ещё несколько минут - проверка доступности шар и тест с файлами.

Итого от начала процедуры до «шары доступны» - 15 минут. С robocopy и ручным монтированием VMDK это занимало от часа до трёх в зависимости от везения.

Отдельно проверили восстановление отдельного файла через Veeam Explorer for Windows: нашли файл в бэкапе пятидневной давности, восстановили рядом с оригиналом. Без ручных монтирований, без VMDK, просто через GUI. Это то, что раньше требовало либо теневых копий внутри ВМ, либо танцев с бубном.

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

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

Репозиторий на дешёвом NAS - узкое место. Veeam пишет быстро, и если NAS не тянет по IOPS, дедупликация при записи начинает тормозить весь процесс. Пришлось поиграть с настройками параллелизма задач.

Instant VM Recovery работает только пока работает бэкап-репозиторий. Очевидно, но стоит держать в голове: если NAS лёг вместе с основными серверами, этот вариант не работает. Для таких сценариев нужна реплика на второй площадке - что у этого клиента и есть.

Итог

Переход с самописных скриптов на Veeam B&R 5 - один из тех случаев, когда инструмент реально меняет подход к задаче, а не просто автоматизирует то, что делалось вручную. 60% экономии на NAS, инкрементал за ночь вместо двух суток, восстановление за 15 минут вместо «как получится».

Следующий шаг - провести аналогичные учения с ВМ на SQL Server и проверить консистентность бэкапа через VSS-интеграцию. Подозреваем, что там будут свои нюансы.

Если занимаетесь похожей задачей - организуем аудит текущей схемы резервного копирования и настройку Veeam в рамках сопровождения ИТ-инфраструктуры.