Veeam v12 GA: тестируем direct-to-S3 с Object Lock на MinIO и Selectel

В ноябре мы гоняли preview v12 на MTC S3 и нашли throttling-проблемы с параллельными потоками. Veeam обещал GA в феврале - и вот мы снова с тестовым стендом, только теперь на двух площадках: self-hosted MinIO, который у нас уже в продакшне у нескольких клиентов, и Selectel S3 как облачный вариант. Задача - понять, насколько схема готова к реальным рабочим нагрузкам.

Что изменилось от preview к GA

Главное, на что смотрели: throttling и стабильность wizard-а. В preview UI-баг с wizard-ом воспроизводился при определённой последовательности действий - создавал задачу, но бросал ошибку в конце, пугая инженера. В GA это починили.

По throttling - Veeam добавил возможность ограничить параллелизм прямо в настройках object storage repository. В preview это было, но в GA интерфейс стал нагляднее и появились задокументированные рекомендации по лимитам для разных классов провайдеров. Мелочь, но при работе с провайдерами, у которых лимиты на PUT-запросы ниже AWS, это сразу сказывается на стабильности.

Стенд

Два сценария, у одного клиента с инфраструктурой на vSphere 7.0:

• MinIO self-hosted - наш кластер 4 узла, EC:4, SATA SSD. Object Lock включён на уровне bucket с момента создания, режим Compliance.
• Selectel S3 - облачный endpoint, bucket с Object Lock, Governance-режим (у Selectel в отличие от некоторых других провайдеров он есть).

В обоих случаях - чистый direct-to-object, без промежуточного repository и SOBR. VBR v12 на Windows Server, vCenter 7.0, набор VM от 20 до 200 GB полезных данных на диске.

Результаты по скорости и RPO

На MinIO неожиданно хорошо. Локальная сеть 10G между VBR-сервером и MinIO-кластером убирает все вопросы по пропускной способности - бэкап 50 GB VM укладывается в окно, которое раньше занимал только transfer на SOBR. Промежуточный диск не пишется вообще, и это сразу видно: нагрузка на хранилище VBR-сервера практически нулевая.

RPO при ежечасных инкрементальных заданиях держится без проблем. Раньше ежечасный инкремент упирался в скорость записи промежуточного repository - теперь узкое место исчезло, и для нескольких VM клиент перешёл с 2-часового RPO на часовой без изменения железа.

На Selectel картина чуть иная - канал до облака ограничивает итоговое время, и для крупных VM (150+ GB данных) ежечасный инкремент начинает конкурировать с предыдущим заданием. Решается настройкой параллелизма и разнесением VM по разным заданиям с офсетом. Ничего принципиально нового, но учитывать надо.

Стоимость хранения - тут и удивило

До v12 схема была: горячий repository на локальных дисках + выгрузка холода в object storage через SOBR. Это означало капитальные расходы на диски для repository и операционные на object storage. В direct-to-S3 схеме repository-сервер остаётся (VBR ему нужен для метаданных и управления), но диски под промежуточный кеш больше не нужны. Точнее, они нужны только если включить capacity tier cache - а для клиентов с быстрой локальной сетью до MinIO кеш не даёт ничего.

На двух клиентах мы посчитали TCO за год: убираем диски с repository, платим только за MinIO (который уже есть) и за электричество. Экономия получилась неожиданно ощутимой - не потому что object storage дешевле дисков как класс, а потому что убирается дублирование хранения. Раньше каждый бэкап жил на repository до момента offload-а в object storage - то есть одновременно в двух местах.

С Selectel математика другая: платишь за трафик и за хранение по тарифу. Для клиентов с большими объёмами это дороже self-hosted MinIO, но вопрос закрывается по-другому: нет CAPEX на железо, нет операционки на поддержку кластера. Разные задачи - разный инструмент.

Object Lock: Compliance vs Governance на практике

На MinIO у нас Compliance - нельзя сократить retention даже от рута. На Selectel Governance - администратор с нужной политикой может снять lock.

Для большинства клиентов Compliance кажется избыточно жёстким, пока не случается первый инцидент с рансомвarem, когда кто-то с admin-доступом к VBR пытается удалить «лишние» задания. В Compliance-режиме попытка удалить объект с активным lock возвращает ошибку - и точка. Veeam expire policy это учитывает корректно: задание не пытается физически удалить объект до истечения lock, просто помечает как expired в своей базе.

Governance удобнее при ошибочно выставленном retention - можно поправить. Но это же означает, что при компрометации admin-учётки рансомварь теоретически может снять lock и удалить бэкапы. Клиенту надо объяснять эту разницу и выбирать осознанно.

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

Одна вещь раздражает стабильно: при потере соединения с S3 во время active full backup Veeam не умеет возобновить задание с точки разрыва. Задание падает, следующий запуск стартует новый full. Для клиентов с нестабильным каналом до облачного S3 это боль - особенно если full занимает несколько часов. На self-hosted MinIO в той же сети вопрос не стоит, но для Selectel при плохом дне у провайдера это реальный сценарий.

В preview это тоже было, в GA не изменилось. Workaround - schedule full на ночь с большим окном и следить за завершением.

Итог пока рабочий: для клиентов с self-hosted MinIO в той же сети direct-to-S3 в v12 GA - реальное улучшение, не маркетинг. Для облачного S3 нужно аккуратно просчитывать канал и тарификацию. Если у вас стоит вопрос по архитектуре резервного копирования - managed-инфраструктура включает и это тоже.