Veeam v13: нативный S3 для российских вендоров и immutable chain на MinIO

Veeam v13 вышел на прошлой неделе. Главное, что нас интересовало в changelog - нативная поддержка S3-совместимых хранилищ без custom-endpoint хаков. Год назад, когда мы разбирали Veeam 12.2 на MinIO в air-gap, одним из раздражителей было именно то, что подключение российских S3-совместимых хранилищ требовало либо танцев с реестром на Windows-хосте, либо подпорки в виде промежуточного S3-прокси. V13 обещает, что этого больше не нужно. Мы проверили.

Что изменилось в части S3-совместимости

В v13 Veeam переработал слой взаимодействия с объектными хранилищами. Раньше под S3-совместимыми хранилищами подразумевалось «AWS S3 с другим endpoint», и любое отклонение от семантики AWS - другой формат заголовков, иная обработка multipart upload, отсутствие части служебных endpoint-ов - приводило к ошибкам, которые диагностировались плохо. V13 добавляет явный режим «generic S3-compatible», в котором Veeam не пытается проверить список AWS-специфичных capabilities и работает с минимальным общим знаменателем S3 API.

Практически это означает: хранилища типа отечественных VK Cloud Object Storage, Yandex Object Storage и аналогичных подключаются без ручной правки конфигов. MinIO в distributed-режиме - тоже. Мы проверили на стенде с MinIO 20250310, на котором уже гоняли 12.2, - подключение прошло через мастер без дополнительных шагов.

Стенд и конфигурация

Конфигурация стенда не изменилась принципиально по сравнению с прошлогодними тестами: VMware-кластер, Veeam Backup & Replication v13 на Windows Server, MinIO distributed на четырёх нодах с Object Lock, всё в изолированном сегменте сети. Клиент - субъект КИИ, требования к неизменяемости бэкапов существенные.

На MinIO: bucket с включённым versioning, Object Lock в режиме COMPLIANCE, retention period выставлен на уровне bucket-политики. Сервисный аккаунт с минимальными правами - те же, что и раньше, плюс s3:GetObjectRetention и s3:PutObjectRetention, которые в v13 стали использоваться явно.

На стороне Veeam в v13 появился отдельный раздел в настройках repository: «Immutable backup chain settings». Раньше управление immutability было размазано по нескольким местам интерфейса, сейчас собрано в одном месте с явными опциями: использовать Object Lock хранилища, использовать Veeam-side immutability или оба механизма одновременно.

Immutable backup chain: как это работает в v13

Veeam v13 формализовал понятие immutable backup chain. Идея в том, что не только отдельный restore point, но вся цепочка инкрементов к нему защищается от удаления и модификации согласованно. В предыдущих версиях была ситуация, когда full backup был под Object Lock, а инкрементальные бэкапы той же цепочки - нет, что делало protection неполной: удалить инкремент = сломать chain = фактически потерять восстанавливаемость.

В v13 при создании задания Veeam вычисляет retention window цепочки и устанавливает Object Lock retention на все файлы цепочки согласованно. При добавлении нового инкремента retention period у полного бэкапа автоматически продлевается так, чтобы вся цепочка оставалась консистентной.

Мы проверили это на MinIO:

• Full backup создаётся с retention, равным полному retention window задания.
• Incrementals получают retention, достаточный для обеспечения цепочки до следующего full.
• При merge-операции (synthetic full) Veeam корректно обновляет retention на новом full backup и снимает блокировки с файлов, которые больше не нужны.

Последний пункт - тот, где в 12.x были проблемы. Merge при Object Lock COMPLIANCE раньше мог упасть именно потому, что файлы старого full ещё были под блокировкой. В v13 Veeam сначала пересчитывает, какие блокировки можно снять, снимает их, и только потом запускает merge. На нашем стенде эта последовательность отработала корректно.

Где ограничения всё-таки есть

Не без нюансов. Object Lock в режиме COMPLIANCE - строгий режим: retention нельзя сократить даже от имени root-пользователя хранилища. Это значит, что если в задании Veeam изменить retention period в сторону уменьшения, старые restore points останутся заблокированными до истечения оригинального срока. Veeam об этом предупреждает в интерфейсе, но далеко не сразу - предупреждение появляется при сохранении задания, а не при изменении параметра.

Второй момент: immutable chain корректно работает только при использовании forward incremental backup. Reverse incremental - не поддерживается с Object Lock, что логично: reverse incremental модифицирует существующие файлы. В интерфейсе v13 reverse incremental блокируется автоматически при включении immutability, но в документации это написано мелким шрифтом.

Третий - производительность. Дополнительные запросы к Object Lock API на каждый файл цепочки дают заметный overhead на больших заданиях. На нашем стенде с заданием в несколько сотен виртуалок время финализации задания после записи данных увеличилось. Не критично, но при планировании окон бэкапа стоит учесть.

Итог

Нативная S3-совместимость без custom-endpoint хаков - это реальное улучшение, а не маркетинг. Подключение российских S3 через generic-режим работает. Immutable backup chain на MinIO с Object Lock в v13 стал заметно надёжнее: согласованная блокировка всей цепочки и корректный merge - это то, чего не хватало в предыдущих версиях.

Для клиентов КИИ, где managed-сопровождение включает управление бэкапной инфраструктурой, v13 выглядит как осмысленное обновление, а не формальный апгрейд. Мы планируем переводить стенды на v13 по мере прохождения внутреннего тестирования.