Immutable backup через Veeam и отечественный S3: тестируем трёх провайдеров

В середине года сразу несколько отечественных облачных провайдеров объявили о поддержке S3 Object Lock в своих объектных хранилищах. Появление функциональности - это одно, а работает ли она с Veeam так, как заявлено - другой вопрос. Мы взяли трёх провайдеров, подключили к одному тестовому стенду и провели несколько недель за замерами.

Предыстория простая: несколько клиентов в рамках managed-сопровождения параллельно спросили про immutable backup в отечественное облако. Это и подтолкнуло нас сделать нормальный сравнительный тест, а не отвечать «смотрите сами» каждый раз.

Что проверяли и как

Стенд: Veeam Backup & Replication последней версии, подключение к трём S3-совместимым хранилищам через встроенный механизм Scale-out Backup Repository с capacity tier. Immutability включали через Object Lock в compliance mode - именно этот режим запрещает удаление объекта даже владельцу бакета в период retention.

Провайдеров называть по именам не будем - не потому что скрываем, а потому что характеристики у них меняются быстро и публиковать снапшот смысла нет. Обозначим как P1, P2, P3. Все трое - российские юрлица, хранилища в дата-центрах на территории РФ, что важно для части наших клиентов с требованиями по локализации.

Совместимость с Object Lock: где споткнулись

Это оказалось самым интересным и неожиданным местом теста.

P1 прошёл без проблем. Veeam успешно создал бакет с Object Lock, выставил retention на объекты при загрузке, и проверка immutability через консоль провайдера подтвердила - объект заблокирован, удалить нельзя. Тест на «а вдруг всё-таки можно» через API тоже прошёл: 403 в ответ на DELETE.

P2 - здесь начались нюансы. Бакет с Object Lock создаётся, флаг выставляется, но Veeam при верификации бэкапа ругался на то, что не может прочитать статус блокировки через GetObjectRetention. Провайдер этот метод API реализовал с отличием от AWS-спецификации в части ответа на unset retention - Veeam ожидает конкретную структуру XML, получает другую, и интерпретирует это как ошибку. На уровне самих данных блокировка работала, но Veeam считал репозиторий «не подтверждённым» и не давал запустить immutable backup в полноценном режиме. Обход нашли - через создание объектов с явным выставлением retention date при каждой загрузке, а не через дефолтное значение бакета. Работает, но это не то, как задумано.

P3 - неожиданно лучший результат с небольшой оговоркой. Всё работает, API совместим, но при создании бакета с Object Lock нужно явно запросить эту функциональность в поддержке - из стандартного интерфейса создаётся бакет без Object Lock, и изменить это потом нельзя. Один раз попался - потерял время.

Скорость: что реально влияет

Замеры скорости загрузки оказались менее показательными, чем мы ожидали - не потому что все провайдеры одинаковые, а потому что разброс внутри одного провайдера в зависимости от времени суток и размера объекта перекрывал разброс между провайдерами. Тем не менее несколько наблюдений фиксируем.

• Размер чанков Veeam имеет значение. По умолчанию Veeam загружает объекты частями, и размер части влияет на количество multipart upload запросов. На P2, у которого overhead на каждый API-запрос чуть выше, это заметно на большом количестве небольших файлов в бэкапе.
• Параллельность задач. При нескольких одновременных заданий бэкапа P1 держался стабильнее - пропускная способность снижалась пропорционально числу задач. У P3 при трёх параллельных заданиях наблюдалось нелинейное падение, которое выровнялось после того как уменьшили параллелизм в настройках репозитория.
• Восстановление. Это часто забывают проверять при тестах бэкапа. Восстановление отдельных файлов через Veeam Explorer работало у всех трёх, скорость download примерно эквивалентна upload - никаких сюрпризов.

Стоимость хранения: считаем реально

Прайс-листы у всех трёх провайдеров выглядят похоже на первый взгляд - стоимость за гигабайт-месяц. Дьявол в деталях.

Транзакционные расходы. Veeam при работе с объектным хранилищем генерирует заметное количество LIST и HEAD запросов - не только PUT при записи и GET при чтении. У P1 LIST-запросы платные и при активном использовании репозитория набегает сумма, сопоставимая с хранением. P2 и P3 LIST не тарифицируют отдельно, что на больших объёмах даёт ощутимую разницу в итоговом счёте.

Исходящий трафик. При восстановлении данных из облака трафик тарифицируется. Для immutable backup это важно: если вам никогда не нужно восстанавливаться, то ноль. Если нужно - прибавляйте к стоимости хранения. Все трое тарифицируют исходящий трафик, ставки у P1 и P3 ниже чем у P2.

Минимальный объём объекта. P1 выставляет минимальный размер тарифицируемого объекта в 128 КБ. Если у вас много мелких файлов в бэкапе - это существенно. Veeam в режиме per-machine backup создаёт достаточно мелких объектов, чтобы это сказалось.

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

Что в сухом остатке

Immutable backup в отечественное объектное хранилище - это рабочий сценарий. Не в смысле «когда-нибудь заработает», а прямо сейчас, с Veeam, без экзотических обходов. Но провайдеры заметно отличаются в точности реализации S3-API, и это влияет на то, насколько гладко работает автоматика Veeam.

Наш вывод по итогам теста: перед выбором провайдера под конкретного клиента стоит потратить день на тестовый стенд с реальными заданиями бэкапа, а не ориентироваться только на декларируемую поддержку Object Lock. Разница между «поддерживаем» и «работает без ручного вмешательства с Veeam» - существенная.

Тест продолжается - следим за тем, как провайдеры будут устранять найденные несовместимости. P2 уже открыл тикет к своей команде разработки.