Veeam v12 Direct-to-S3 с Object Lock: уходим от ленточного робота на immutable-бэкапы

Клиент держал резервные копии на LTO-ленте уже лет восемь. Схема классическая и по-своему надёжная: роботизированный ленточный привод, посменная ротация картриджей, вывоз на внешнее хранение. Работало. До того момента, когда робот начал сбоить - механика, ничего экзотического. Запчасти под заказ, ждать недели. Пока ждали, все резервные копии физически лежали в приводе, к которому нельзя обратиться. Вот это и был сигнал.

Параллельно Veeam Backup & Replication v12 добавил нативную поддержку Direct-to-Object Storage - запись резервных копий напрямую в S3-совместимое хранилище без промежуточного репозитория на диске. С S3 Object Lock в режиме COMPLIANCE это даёт immutable-хранение: никакой администратор, никакой ransomware и никакой сбой механики не сотрёт копию до истечения срока удержания. Именно это сочетание нас интересовало.

Почему Direct-to-Object, а не SOBR с capacity tier

До v12 стандартная схема с S3 в Veeam выглядела так: локальный диск как performance tier, потом offload на S3 как capacity tier через Scale-Out Backup Repository. Это работало, но создавало лишнее звено: диск под performance tier всё равно нужен, и rescan / offload добавлял задержку.

В v12 Direct-to-Object позволяет писать напрямую в бакет - без промежуточного диска. Есть ограничения: не все типы заданий поддерживают Direct-to-Object одинаково хорошо, и для VMware-окружений c CBT производительность на первом полном бэкапе будет зависеть от сети до S3. Но для клиента с умеренным объёмом данных и ночным окном резервного копирования это не проблема.

Выбор S3-таргета

Клиент уже смотрел на S3-совместимые хранилища - у нас был опыт с MinIO на другом проекте. Здесь выбрали облачного провайдера с поддержкой Object Lock - конкретно Selectel Object Storage, который к этому моменту уже поддерживает Object Lock в COMPLIANCE-режиме.

Бакет создаётся с включённым Object Lock сразу при создании - потом включить нельзя. Retention задаём на уровне бакета как default, чтобы Veeam не мог случайно создать объект без retention:

# через AWS CLI, совместимый с Selectel S3
aws s3api create-bucket \
  --bucket veeam-prod-backups \
  --object-lock-enabled-for-bucket \
  --endpoint-url https://s3.selectel.com

aws s3api put-object-lock-configuration \
  --bucket veeam-prod-backups \
  --object-lock-configuration \
    '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}' \
  --endpoint-url https://s3.selectel.com

Тридцать дней - это минимум, который согласовали с клиентом. Критически: COMPLIANCE-режим не имеет override даже от root-пользователя хранилища. Если поставить срок неправильно - объекты нельзя удалить, только ждать. Проверили дважды перед тем, как подключать Veeam.

Конфигурация в Veeam

Добавляем Object Storage Repository: тип - S3 Compatible, вводим endpoint, credentials (access key / secret key с минимально необходимыми правами - s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject для cleanup expired, s3:GetObjectLegalHold / PutObjectLegalHold). Veeam на этапе добавления репозитория проверяет наличие Object Lock на бакете и показывает галочку "Make recent backups immutable for X days" - включаем.

Затем создаём Backup Job с таргетом на этот репозиторий напрямую, без SOBR. В настройках Veeam видит, что репозиторий поддерживает immutability, и предупреждает: если выставить срок иммутабельности длиннее, чем retention политики бэкапа, удалить старые точки восстановления не получится, пока Object Lock не истечёт. Это логично, и клиент с этим согласился.

Что изменилось в RTO

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

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

Здесь важно не обманываться: S3 - это не локальный диск, и сеть до облачного хранилища имеет значение. Если нужно восстановить несколько терабайт за час - нужно считать полосу. Но для типичного сценария «упала одна ВМ, надо поднять за разумное время» - разница принципиальная.

Мониторинг и алерты

С лентой мониторинг строился вокруг статуса задания в Veeam и физического состояния картриджей. С S3 добавился новый класс проблем: доступность endpoint, квоты, счёт за хранение.

Подключили алерты через Veeam ONE на:

• Задание завершилось с ошибкой - стандартно.
• Задание не запускалось N часов - защита от тихого сбоя расписания.
• Размер бэкапа отклонился от нормы - аномальное уменьшение может сигнализировать о проблеме с CBT или источником.

Плюс внешний мониторинг доступности S3 endpoint - просто HEAD-запрос к бакету раз в несколько минут из Zabbix.

Что пока открыто

Клиент хочет посмотреть на Instant VM Recovery прямо из S3 - в v12 это технически возможно, но мы ещё не тестировали под реальной нагрузкой. Veeam монтирует диски ВМ напрямую из объектного хранилища, что для медленных или перегруженных S3-endpoint может создать неприятности во время работы восстановленной ВМ.

Ленточный робот после ремонта решили оставить как архивный tier для долгосрочного хранения - более трёх лет. Экономика хранения на ленте на горизонте лет выигрывает у объектного хранилища. Но оперативный backup-цикл теперь полностью на S3 через managed-сопровождение.