Veeam 12.2 и air-gap на MinIO: проверяем шифрование на отечественных серверах

Veeam Backup & Replication 12.2 вышел в конце января, и первое, что нас там заинтересовало, - обновлённая работа с air-gap репозиториями и расширенная поддержка S3-совместимых хранилищ, в том числе отечественных. Для части клиентов, где бэкапы уходят на изолированный сегмент сети с MinIO на российском железе, это был хороший повод проверить на живом стенде, что именно изменилось и где по-прежнему приходится работать руками.

Стенд - типовой для нас сценарий: VMware-кластер, Veeam Backup & Replication 12.2, MinIO в качестве S3-совместимого объектного хранилища, всё это на серверах отечественной сборки, изолированный сегмент без выхода в интернет. Клиент - субъект КИИ, и требования к неизменяемости резервных копий у него не бумажные.

Что нового в 12.2 по части air-gap

Основное изменение, на которое смотрели, - поддержка immutable backup на S3-совместимых хранилищах без прямой зависимости от вендорской реализации Object Lock. Veeam 12.1 уже умел работать с Object Lock, но требовал точного соответствия AWS S3-семантике, что на части отечественных S3 работало с оговорками. В 12.2 добавили режим, где неизменяемость обеспечивается на стороне Veeam через собственный механизм блокировки записи, а не только через Object Lock хранилища.

Второе - улучшенная работа с offline-копированием для air-gap: Veeam теперь явно разделяет в интерфейсе сценарии «S3 без интернет-доступа» и «полностью изолированный репозиторий с ручным переносом носителей». Звучит как косметика, но на практике это означает, что часть эвристик при подключении хранилища перестала выдавать предупреждения о недоступности проверочных endpoint-ов AWS. Мелочь, которая раздражала.

Как настраивали

Подключение MinIO к Veeam 12.2 как object storage repository в целом без сюрпризов. MinIO работает в режиме distributed setup на четырёх нодах, Object Lock включён. Настройки на стороне MinIO:

• Bucket с включённым versioning и Object Lock в режиме COMPLIANCE.
• Отдельный сервисный аккаунт с минимальными правами: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:GetBucketVersioning и s3:GetObjectLegalHold / s3:PutObjectLegalHold для работы с блокировками.
• TLS на endpoint MinIO - самоподписанный сертификат из внутреннего CA.

На стороне Veeam в 12.2 появилась опция явно указать CA-сертификат для S3-совместимых хранилищ прямо в мастере подключения, без необходимости добавлять его в системное хранилище Windows на сервере Veeam. Незаметное улучшение, но нас оно несколько раз выручало в предыдущих версиях, где диагностика «не доверяет сертификату» приходила в виде невнятной ошибки подключения.

Шифрование при передаче: что проверяли

Здесь было несколько вопросов. Первый - работает ли шифрование канала (TLS между Veeam и MinIO endpoint) штатно без дополнительных костылей. Работает. TLS 1.2 и TLS 1.3 на MinIO, Veeam корректно устанавливает защищённое соединение, сертификат из внутреннего CA принимается без ошибок после добавления через интерфейс.

Второй вопрос был интереснее: шифрование данных на стороне Veeam (Veeam-side encryption) в сочетании с Object Lock. Veeam умеет шифровать резервные копии перед тем, как они уходят на хранилище - это означает, что на MinIO приходит уже зашифрованный блоб, и ключи хранилище не видит. С Object Lock это должно работать вместе: Veeam шифрует, отправляет, ставит legal hold через API. Проверили - работает корректно. Object Lock не мешает Veeam читать файлы обратно для восстановления, потому что блокировка на удаление, а не на чтение.

Третий момент - производительность при шифровании. Шифрование на стороне Veeam даёт заметную нагрузку на CPU сервера Veeam, это известно. На нашем стенде это было ощутимо на больших джобах, но в пределах разумного - упирались в сеть раньше, чем в CPU. На production-нагрузке стоит учитывать при выборе железа под Veeam-сервер.

Где всё-таки пришлось копать

Air-gap в смысле «физически изолированный сегмент» у клиента означает, что MinIO и Veeam находятся в разных VLAN с межсетевым экраном между ними. Veeam при добавлении S3 repository пытается достучаться до нескольких endpoint-ов для проверки совместимости. В 12.2 список endpoint-ов, к которым Veeam обращается во время настройки, немного изменился - нам пришлось пересмотреть правила на МЭ. Документация по этому в release notes поверхностная, список endpoint-ов выяснили из Wireshark на сетевом шлюзе. Старый добрый способ.

Ещё один момент: MinIO на отечественных серверах - в нашем случае это Inferit RS224 - показал одну неочевидную проблему при работе с большим количеством одновременных запросов от Veeam. MinIO начинал дропать соединения под нагрузкой, что Veeam воспринимал как ошибки и ретраил. Оказалось - настройки open file limits на уровне systemd unit были дефолтными. Подняли limits, проблема ушла. Не специфика Veeam 12.2, но в связке всплыло именно здесь.

Итог на сейчас

Связка Veeam 12.2 + MinIO на отечественных серверах в air-gap сегменте работает штатно, и 12.2 действительно немного упростил ряд мест, которые раньше требовали ручного вмешательства. Шифрование при передаче и шифрование на стороне Veeam совместно с Object Lock - рабочий сценарий без хаков.

Что стоит учесть тем, кто идёт по этому пути: правила МЭ под Veeam в air-gap надо проверять заново при обновлении - список используемых подключений меняется. Системные настройки MinIO под нагрузку стоит проработать заранее, не когда уже упало. И самоподписанный CA теперь добавляется через интерфейс Veeam - не нужно лезть в Windows cert store, что при managed-сопровождении экономит время при масштабировании.

Immutable backup с отечественным S3 и air-gap - это реалистичный сценарий для КИИ. Не без нюансов, но без принципиальных блокеров.