Veeam v12 preview: тестируем direct-to-S3 на MTC S3 и разбираемся с throttling

Veeam выкатил публичный preview v12 в октябре, и один из главных анонсов - direct-to-object storage: бэкап идёт прямо на S3-совместимое хранилище, минуя промежуточный repository сервер. Раньше схема выглядела так: агент снял снапшот, передал на repository, repository уже записал в object storage через Scale-Out Backup Repository (SOBR). Лишний hop, лишний диск на repository, лишнее место. В v12 этот hop убирается - для поддерживаемых object storage, разумеется.

Плюс второй блок изменений - расширенный immutable backup. WORM-объекты теперь поддерживаются глубже: не только через S3 Object Lock на AWS, но и через совместимые реализации у других провайдеров. Для клиентов в контексте требований по защите от ransomware это актуально.

Мы решили погонять preview на живом клиентском стенде - с отечественным объектным хранилищем MTC S3.

Схема стенда

У клиента - виртуальная инфраструктура на vSphere 7.0, бэкапится Veeam BR 11. Repository - Windows-сервер с локальными дисками, SOBR настроен с выгрузкой в MTC S3. Типичная схема «горячий кеш на локале, холод в облако». Preview v12 установили параллельно на отдельный VBR-сервер, чтобы не трогать продуктив.

В v12 настраиваем объектный репозиторий напрямую: добавляем MTC S3 как S3-совместимый endpoint, указываем bucket, включаем Object Lock (заранее создали bucket с включённым lock через консоль MTC). Отдельного repository-сервера для кеша не добавляем - это и есть direct mode.

Что получили по скорости

Бэкап той же VM через прямую запись прошёл заметно быстрее, чем через старую схему с SOBR. Разница чувствуется - убираешь посредника, убираешь двойную запись. Локальный диск на repository больше не является узким местом.

Но тут начались нюансы с throttling.

MTC S3 ограничивает количество PUT-запросов на bucket. Veeam при direct-to-S3 пишет параллельно несколько потоков, и на средних и крупных VM мы стали получать HTTP 503 SlowDown от S3. Veeam это обрабатывает - делает retry с backoff - но итоговое время бэкапа у крупных VM (100+ GB данных на диске) ползло вверх именно из-за ретраев.

Решение - ограничить параллелизм в настройках задания. В v12 preview появился параметр максимального количества параллельных потоков на object storage task. Выставили 4 вместо дефолтных 8 - throttling пропал, скорость немного упала, но итоговое время всё равно лучше чем через SOBR.

Immutable backup на практике

Object Lock на стороне MTC S3 работает - объекты после записи действительно нельзя удалить до истечения retention. Проверили через консоль и через API: попытка удалить объект с активным lock возвращает ошибку.

Со стороны Veeam retention policy работает корректно: expire в Veeam не удаляет объект, пока не истёк Object Lock. Это именно то поведение, которое нужно - бэкапы не исчезнут, даже если кто-то получит доступ к учётке VBR.

Одна шероховатость - у MTC S3 Object Lock работает только в режиме Compliance, Governance-режима нет. Это значит, что retention нельзя укоротить даже администратором. Для части клиентов это нормально и даже желательно, для других создаёт неудобства при ошибочно выставленном retention. Надо учитывать при проектировании политики.

Что в итоге

Direct-to-S3 в v12 preview работает и даёт реальный выигрыш для инфраструктур, где промежуточный repository был узким местом. Несколько практических вещей, которые стоит держать в голове:

• Throttling - реальная проблема. Если S3-провайдер ограничивает частоту запросов, параллелизм надо снижать вручную. Дефолтные настройки Veeam рассчитаны на AWS, у которого эти лимиты другие.
• Object Lock перед бэкапом. Bucket надо создавать с включённым Object Lock сразу - постфактум его не включишь, это ограничение S3.
• Preview есть preview. Мы нашли один баг: при определённой последовательности действий UI завершает wizard с ошибкой, хотя задача создаётся. Возможно специфика именно нашей конфигурации, нужно смотреть дальше.

GA v12 ещё не вышел, и часть поведения наверняка изменится до релиза. Но направление правильное - для тех, кто использует S3-совместимые хранилища в managed-инфраструктуре, это реальное упрощение схемы. Меньше компонентов, меньше точек отказа, защита от удаления на уровне хранилища.

Будем наблюдать за RC и финальным релизом.