Offsite-бэкап через S3-совместимый API: тест с отечественным провайдером

Несколько недель назад мы возились с Ceph и его RADOSGW, который умеет говорить по S3-протоколу. Параллельно несколько отечественных провайдеров запустили коммерческие объектные хранилища с тем же S3-совместимым API - уже не «поставь сам», а купил и пользуешься. Решили проверить, насколько это работает для offsite-бэкапа реальных клиентских данных.

Контекст. У нас есть несколько клиентов, у которых offsite-бэкап делается по старинке: лента в пятницу, курьер в субботу, кассеты на полке у директора. Мы про этот квест с лентами писали ещё в 2000-м - с тех пор хранение выросло, а схема принципиально не поменялась. RTO при полном восстановлении - в районе восьми часов, и это при условии, что нужная кассета читается с первого раза.

Что тестировали. Два инструмента на одном клиентском стенде: Veeam Backup & Replication (там S3-совместимое хранилище идёт как Cloud Repository) и Bacula с отдельным S3-плагином. Данные - файловый сервер плюс SQL Server, суммарно несколько сотен гигабайт. Провайдер - отечественный, с российскими серверами и ценой в рублях, что для части клиентов уже аргумент сам по себе.

Veeam. Настройка оказалась неожиданно прямолинейной. В мастере создания репозитория выбираешь «S3 Compatible», вбиваешь endpoint, access key, secret key - и оно работает. Единственный камень преткновения - провайдер не поддерживал multipart upload для объектов крупнее определённого размера, и первый полный бэкап завершился ошибкой. Решилось ограничением размера блока на стороне Veeam. Инкрементальные копии потом шли без проблем.

Bacula. Здесь чуть сложнее. S3-плагин требует отдельной компиляции с libs3, и документации на него меньше, чем хотелось бы. Зато Bacula даёт больше контроля над политикой хранения: можно прозрачно писать в облако так же, как в локальный Volume, с теми же скриптами retention и верификацией после записи. Настроили как второй уровень хранения - локальный диск плюс копия в S3.

Тест восстановления. Это главное, ради чего вся история. Взяли свежий полный бэкап плюс последний инкремент и восстановили файловый сервер в изолированную среду - от момента начала до момента, когда сервис доступен. Получилось около четырёх часов. Сюда входит: развернуть VM с нуля, восстановить систему из Veeam, поднять SQL Server, проверить консистентность базы. Основной лимитирующий фактор - скорость скачки с провайдера, не вычислительная мощность.

Для сравнения: тот же сценарий с лентами - восемь часов и это без учёта времени на поиск нужной кассеты и доставку с «внешнего хранилища».

Что насторожило.

• Стоимость трафика на скачку. Провайдер считает исходящий трафик. Пока мы тестировали на стенде - некритично. Но для реального DR с регулярными тест-ресторами это надо считать в бюджете.
• Задержки на запись. Первый полный бэкап шёл существенно дольше, чем на локальный диск. Понятно, почему, но окно резервного копирования надо пересматривать.
• Проверка целостности. Провайдер честно возвращает MD5 по ETag при загрузке объекта. Veeam проверку использует, Bacula с плагином - надо проверять отдельно, автоматически этого не происходило.
• Регуляторная история. Для части клиентов данные под 152-ФЗ. Вопрос о том, где физически сидят серверы и есть ли у провайдера нужные документы, пришлось задавать вручную. Ответ получили, но не сразу.

Итог на сейчас. Схема рабочая. S3-совместимый API достаточно стандартный, чтобы инструменты, написанные под Amazon, работали с отечественным провайдером при минимальных правках конфига. RTO в четыре часа против восьми - разница ощутимая, особенно когда клиент звонит в воскресенье.

Переводить всех клиентов прямо сейчас на эту схему не планируем: надо набрать больше статистики по надёжности провайдера, доделать мониторинг успешности загрузки и понять, как будет вести себя задержка при увеличении объёма. На ленты тоже не закрываем глаза - для ряда случаев гибридная схема «диск + облако + лента раз в месяц» выглядит разумнее чистого облака.

В рамках managed-сопровождения это меняет чеклист проверки бэкапов: вместо «кассета на месте, голова чистая» теперь ещё и «объекты загрузились, MD5 совпал, тест-ресторе прошёл». Работы чуть больше, но уровень уверенности другой.