Veeam 9.5 U2: объектное хранилище как Capacity Tier в SOBR

Update 2 для Veeam Backup & Replication 9.5 вышел на прошлой неделе, и в нём есть одна вещь которую мы ждали конкретно под задачу долгосрочного хранения резервных копий: поддержка объектного хранилища как Capacity Tier в Scale-out Backup Repository. Не просто «можно настроить», а официально задокументированная и работающая функция.

Что такое SOBR с Capacity Tier

Scale-out Backup Repository в Veeam - это логический пул из нескольких репозиториев, который сам решает куда класть данные. До Update 2 SOBR работал только с блочными хранилищами и файловыми шарами - всё, что можно смонтировать как Volume или расшарить по SMB/NFS. Объектное хранилище не поддерживалось.

Теперь к SOBR добавляется второй «уровень» - Capacity Tier. Механика такая: свежие бэкапы живут на Performance Tier - это обычные диски, быстрые, дорогие, рядом с продакшном. По истечении заданного срока (например, 30 дней) Veeam сам перемещает или копирует данные на Capacity Tier - в объектное хранилище. Это может быть AWS S3, Azure Blob или любой S3-совместимый эндпоинт.

Нас интересует последнее: S3-совместимый эндпоинт. В нашем случае это собственный Ceph-кластер с радиогейтом S3, который мы перевели на BlueStore в начале месяца.

Как это выглядит на практике

Настройка делается в консоли Veeam - никаких скриптов, никаких кастомных инструментов.

Добавляем объектное хранилище. В Backup Infrastructure -> Backup Repositories добавляем новый репозиторий типа «Object Storage Repository». Выбираем совместимый с S3, указываем эндпоинт, access key, secret, bucket. Здесь важен нюанс: Veeam в U2 работает с собственной структурой папок внутри бакета и не любит когда в бакете что-то лежало до него - лучше выделить отдельный бакет именно под это.

Добавляем Capacity Tier к существующему SOBR. В свойствах SOBR появилась вкладка Capacity Tier. Включаем, выбираем созданный Object Storage Repository. Задаём политику: через сколько дней перемещать (Move) или копировать (Copy) данные на объектное хранилище.

Move vs Copy - принципиальный выбор. Move освобождает место на Performance Tier, Copy оставляет копию там и там. Для нас в большинстве случаев имеет смысл Move: Performance Tier должен держать актуальные точки восстановления, а старые архивы - на объектном хранилище. Если нужна защита от потери объектного хранилища - Copy, но это удваивает расход.

Восстановление. Это место которое нас беспокоило больше всего - нет ничего хуже чем дешёвое хранение из которого нельзя нормально восстановиться. Проверили: виртуальные машины из Capacity Tier восстанавливаются стандартными мастерами Veeam. Консоль видит все точки восстановления независимо от того где физически лежит бэкап. Veeam прозрачно тянет данные из объектного хранилища.

Скорость восстановления ниже чем с Performance Tier - это очевидно и ожидаемо. Но для архивных данных которые нужны раз в квартал «чуть медленнее» - приемлемо.

Стоимость хранения: почему это интересно

У нескольких клиентов в managed-проектах стоит задача хранить резервные копии 90-180 дней. Раньше это означало либо дорогие быстрые диски (держать полгода архивов на SAN - деньги, которые жалко), либо ручную работу: самописные скрипты которые двигают файлы на дешёвое NAS, а потом непредсказуемо не могут оттуда восстановиться через Veeam.

Объектное хранилище в схеме существенно дешевле блочного на единицу объёма. На нашем Ceph с BlueStore - примерно втрое по стоимости гигабайта относительно «горячего» хранилища. При этом восстановление остаётся в стандартном UI Veeam, а не в каком-то самодельном велосипеде.

Что скрипит

Честно - есть нюансы.

Первое - скорость tiering-а. Перемещение данных на Capacity Tier работает в рамках окна обслуживания. Если у вас сотни гигабайт «съехавших» по сроку бэкапов накопилось за несколько дней пропуска окна - Veeam начинает перекладывать их все сразу. На нашей конфигурации это создавало ощутимую нагрузку на сеть и на Ceph одновременно с ночными джобами бэкапа. Нужно аккуратнее планировать окна.

Второе - консистентность бакета. После нескольких тестовых удалений и повторных конфигураций в бакете остался мусор который Veeam не убирал сам. Там нет автоматической garbage collection под удалённые машины. Нужно самостоятельно следить за тем чтобы не копилось.

Третье - шифрование. Данные на Capacity Tier шифруются, но ключи управляются в самом Veeam. Если потерять конфигурацию Veeam - данные на объектном хранилище останутся нечитаемыми. Это не недостаток, просто нужно держать в голове при планировании DR для самого Veeam.

Что дальше

Пока разворачиваем на одном клиентском проекте в пилотном режиме: 30-дневный Performance Tier на быстрых дисках, 90 дней на Ceph через S3. Если через месяц не обнаружим неприятных сюрпризов с восстановлением - переведём ещё несколько.

Экономика выглядит убедительно, механика работает. Главный вопрос который остаётся открытым - как это поведёт себя с большими объёмами на длинном горизонте. Посмотрим.