Veeam Backup 10: наконец-то нормальный NAS Backup и immutable-копии против ransomware

Veeam 10 GA вышел 18 февраля, и мы уже планируем обновления для нескольких клиентов на managed-сопровождении. Релиз ждали давно - в основном из-за двух вещей: нормального NAS Backup и улучшенной поддержки immutable-репозиториев. Разбираем что реально изменилось и как это ложится в нашу практику.

NAS Backup - наконец без костылей

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

В Veeam 10 NAS Backup - полноценный встроенный механизм с поддержкой SMB и NFS. Ключевые моменты:

• Инкрементальный бэкап через Change Tracking. Для SMB-шар с поддержкой SMB Change Notify и для NetApp/Dell EMC - через нативные API снапшотов. Для прочих NFS/SMB - собственный механизм отслеживания изменений Veeam File Change Tracking.
• Гранулярное восстановление. Конкретный файл из точки восстановления без монтирования всего бэкапа. Давно ожидаемая вещь для поддержки пользователей - «мне нужен вот тот файл что я удалил три дня назад» решается в пару кликов.
• Поддержка scale-out. Репозиторий для NAS-бэкапов вписывается в ту же SOBR-логику, что и VM-бэкапы. Не нужно городить отдельную инфраструктуру.

На практике самый частый кейс у нас - 1С на файловом сервере Windows или отдельный NAS с рабочими файлами. Раньше это было отдельным бэкап-агентом с отдельным расписанием, отдельным мониторингом и периодическими вопросами «а точно бэкап работает». Теперь всё в одном окне Veeam Console.

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

Instant VM Recovery для любого гипервизора

В девятой версии Instant Recovery работал только для VMware. В десятке - Hyper-V тоже. Это важно, потому что у нас немало клиентов с Hyper-V как основным гипервизором.

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

Практически это меняет разговор с клиентом о планировании восстановления. Раньше приходилось объяснять что восстановление VM с Hyper-V - это несколько часов в худшем случае. Теперь - запустить из бэкапа за 10-15 минут, дать пользователям работать, разобраться с инцидентом не торопясь.

Immutable backup и S3 Object Lock

Вот где десятая версия закрывает реальную дыру. Поддержка S3 Object Lock - это механизм хранения бэкапов в режиме WORM (write once, read many), при котором данные нельзя удалить или изменить до истечения срока, даже если у атакующего есть credentials на S3.

С ростом ransomware-атак, которые целенаправленно ищут и шифруют бэкапы перед тем как зашифровать основные данные, это перестаёт быть параноей и становится нормальной практикой. Несколько клиентских инцидентов из прошлого года, когда зловред добрался до SMB-шары с бэкапами, сделали этот разговор проще.

Схема которую мы тестируем: основной репозиторий на локальном хранилище + второй уровень в S3-совместимом облаке с включённым Object Lock. Для российских клиентов это либо Yandex Object Storage, либо собственный MinIO с Object Lock - оба поддерживают нужный API.

Настройка в Veeam 10 прямолинейная: в свойствах объектного репозитория включаешь Make recent backups immutable for N days и выставляешь срок. После этого Veeam проставляет Object Lock retention при загрузке каждого бэкап-файла. Попытки удалить или перезаписать такой файл через S3 API возвращают ошибку - атакующий ничего не сделает, даже имея ключи.

Пара нюансов которые надо учитывать:

• MinIO требует версии с поддержкой Object Lock - не все сборки это умеют, надо проверять. Актуальные версии MinIO поддерживают, но при апгрейде с более старых - проверяйте конфигурацию.
• Стоимость хранения растёт. Immutable-копии нельзя удалить досрочно - значит, нельзя ужать расписание задним числом. Нужно изначально реалистично считать объём и срок хранения.
• Удаление просроченных бэкапов всё равно работает. Object Lock с Governance mode vs Compliance mode - разные уровни защиты. Veeam по умолчанию использует Governance, что позволяет удалять истёкшие объекты. Compliance mode строже, но тогда нельзя удалить ничего до истечения срока даже через AWS root account.

Что обновляем и в каком порядке

Обновление с Veeam 9.5 Update 4 до Veeam 10 у нас стоит в планах для нескольких клиентов на ближайшие недели. Порядок стандартный: сначала стенд, смотрим на задания, проверяем что все расписания подхватились, делаем тестовое восстановление.

Специфика десятой версии - поменялась схема каталога в репозитории для NAS Backup, так что если планируете мигрировать существующие NAS-задания с агентного решения, нужно пересоздать цепочки бэкапов. Это потеря истории, которую надо закладывать в план перехода.

Выходит, Veeam 10 закрывает несколько историй которые раньше приходилось решать через сторонние инструменты или скрипты. NAS Backup из коробки убирает отдельный класс технического долга. Immutable-копии дают реальную защиту от ransomware, а не иллюзию. Instant Recovery на Hyper-V выравнивает возможности с VMware-клиентами. Работы по обновлению хватит, но оно того стоит.