Интеграция облачных хранилищ с локальными системами хранения данных

Интеграция облачных хранилищ с локальными системами хранения данных на практике сводится к одной схеме: рабочие данные лежат на своей СХД в серверной, а архивы и резервные копии уезжают в облако по протоколу S3. Локальная половина даёт скорость и контроль, облачная - вторую площадку и оплату по факту. Техника тут давно отработана. Спотыкаются на другом: западные облака российским компаниям закрыты, и инструкции трёхлетней давности ведут в тупик.

Что изменилось и почему старые инструкции не работают

20 марта 2024 года Microsoft, Amazon и Google закрыли доступ к облачным сервисам для компаний, зарегистрированных в России, - это последствие 12-го пакета санкций ЕС. Всё, что писали про связку локального хранилища с облаком через AWS Direct Connect, Azure ExpressRoute или Google Cloud Interconnect, для российской компании превратилось в теорию.

Рабочая схема выглядит проще. С одной стороны - ваша СХД или сервер с дисковой полкой. С другой - объектное хранилище российского провайдера: Yandex Object Storage, Selectel, VK Cloud, Cloud.ru, МТС Web Services. Все они говорят на S3 - том же протоколе, который когда-то придумала Amazon для своего хранилища. Софт, который умеет S3, обычно работает с любым из них: меняются адрес точки доступа и пара ключей.

Что оставить у себя, а что отдать в облако

Раскладывают данные по двум признакам: как часто к ним обращаются и сколько времени готовы ждать. Важность тут вторична. Секретный договор, который открывают раз в пять лет, спокойно живёт в ледяном классе. База 1С, к которой стучатся сто человек, не переживёт даже хорошего канала.

Опись - отдельный пункт, о котором забывают. Если в ледяном классе лежит 30 ТБ без каталога, то через два года найти в них конкретный акт будет дороже, чем заново запросить его у контрагента. Держите список того, что уехало, у себя.

Локальную половину гибрида собирают по обычным правилам: как выбрать систему хранения данных под задачу мы разбирали отдельно, там же про выбор между полкой, сервером с дисками и готовой системой хранения данных.

Четыре способа связать локальную СХД с облаком

Способы отличаются тем, кто принимает решение о перемещении данных: администратор, сама СХД или программа резервного копирования.

Облачный шлюз показывает бакет как сетевую папку или диск. Пользователи работают привычно, шлюз занимается протоколом, кэшем и шифрованием. Быстрее всего запускается, сильнее всего зависит от канала.

Многоуровневое хранение встроено в саму СХД: система следит за обращениями и вытесняет холодные блоки на нижний уровень, вплоть до облачного. Настраивается один раз, дальше работает без человека. Требует, чтобы такая функция была в вашей модели - в бюджетных полках её нет.

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

Резервное копирование в облачный репозиторий - с него обычно и начинают. Единственный вариант, который вообще не трогает продуктив: программа бэкапа просто получает ещё одно место назначения.

Чем стыкуют: протокол, канал, софт

S3 как общий язык

S3 стал стандартом де-факто, и это удобно: один и тот же скрипт работает с Yandex Object Storage, Selectel и с вашим собственным хранилищем в стойке. Смена провайдера сводится к смене эндпоинта. Локальную часть тоже можно сделать S3-совместимой - тогда обе половины гибрида говорят одинаково, и мы разбирали это в статье про своё S3-хранилище в стойке.

Канал: считайте не гигабайты, а окно

Тут админов подводит арифметика. Терабайт по каналу 100 Мбит/с уезжает около суток - при условии, что канал свободен и никто больше в него не лезет. Первая заливка архива в 20 ТБ по такому каналу растянется почти на три недели. И это считалось по полосе: на россыпи мелких файлов упрётесь не в неё, а в число операций, там терабайт может ехать вдвое дольше. Поэтому её разбивают на порции и запускают в нерабочие часы, а при совсем больших объёмах уточняют у провайдера, есть ли у него вариант физического переноса данных.

Вариантов стыка три. Обычный интернет с HTTPS - подходит для ночных бэкапов и стоит ноль. Туннель IPsec поверх интернета - когда нужен закрытый канал и адресация в одну сеть. Выделенный канал или стык на площадке провайдера - когда объёмы регулярные и терять их в общем интернете нельзя; это уже разговор про деньги и договор.

Софт

Из открытого - rclone для синхронизации папок с бакетом и restic для резервных копий со сжатием, дедупликацией и шифрованием на стороне клиента. Оба живут в кроне и не требуют лицензий. Из коммерческого российского - Кибер Бэкап и RuBackup умеют складывать копии в S3-совместимые хранилища, но набор поддерживаемых сценариев зависит от версии и лицензии, так что этот пункт стоит проверить до покупки, а не после.

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

Из чего складывается счёт

Хранение в облаке дешёвое. Дорого обходится всё остальное: обращения к объектам, исходящий трафик и попытка уйти раньше срока.

Ориентиры по публичным прайс-листам Yandex Cloud и Selectel на август 2026 года. Тарифы у провайдеров меняются - перед расчётом сверьтесь с калькулятором конкретного облака.

Три статьи расходов, которые не попадают в первую прикидку:

• Операции. Чем холоднее класс, тем дешевле хранение и дороже каждое обращение. Миллион мелких файлов в ледяном классе может стоить дороже, чем один архив того же объёма.
• Исходящий трафик. У Yandex Object Storage первые 100 ГБ в месяц не тарифицируются, дальше считают за гигабайт. Разовое восстановление архива на несколько терабайт легко перекроет годовую плату за его хранение.
• Минимальный оплачиваемый срок. У холодных и ледяных классов он есть почти всегда - у разных провайдеров от месяца до года. Положили и через неделю передумали - заплатите как за полный срок.

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

Безопасность: что спросят при проверке

Первый вопрос будет про географию, и только потом про шифрование. Часть 5 статьи 18 закона 152-ФЗ требует: при сборе персональных данных россиян их запись, систематизация, накопление, хранение, уточнение и извлечение идут в базах, которые находятся на территории России. Поэтому провайдера и адрес его ЦОД проверяют до того, как заводят первый бакет; подробности - в разборе локализации персональных данных по 152-ФЗ. GDPR вспоминают только те, у кого есть европейские клиенты.

Цена вопроса выросла: с мая 2025 года за утечку данных 1-10 тысяч человек юрлицу грозит от 3 до 5 миллионов рублей, а за неуведомление Роскомнадзора о начале обработки - от 100 до 300 тысяч, причём безо всякой утечки.

Техническая часть простая:

• Шифруйте до отправки. Данные должны уходить в облако уже зашифрованными, а ключи оставаться у вас. Тогда компрометация провайдера не превращается в компрометацию ваших архивов.
• Включите версионирование и блокировку объектов. Режим WORM (записал один раз - перезаписать нельзя) поддерживается в том числе Yandex Object Storage и работает только при включённом версионировании. Это главная защита от шифровальщика, который добрался до учётки бэкапа. Важная деталь: у блокировки два режима, и мягкий снимается тем, у кого есть права на бакет. Если защищаетесь именно от захвата учётки, нужен строгий режим, где срок нельзя сократить вообще никому.
• Разделите учётные записи. Сервисный ключ, которым бэкап пишет в бакет, не должен уметь удалять. Ключ на удаление живёт отдельно и достаётся руками.

Ротацию ключей делают по регламенту компании. Универсального срока нет - и «каждые 90 дней» на маленькой инфраструктуре чаще создаёт риск потерять ключ, чем защищает от чего-то реального.

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

Что ломается на практике

Копии уезжают, восстановление не проверяли. Самая частая история. Бэкап в облако настроили в марте, письма о выполнении приходят, а первое реальное восстановление случается в ноябре - и выясняется, что в задание не попал том с базой. Восстановление тестируют по расписанию, хотя бы раз в квартал, и обязательно на отдельную машину.

Правило 3-2-1 понимают наполовину. Три копии, два разных типа носителя, одна копия вне площадки. Облако закрывает третий пункт и частично второй, но не отменяет первые два: одна копия в облаке и одна на продуктиве - это не три копии. Про то, на каком железе держать локальную часть бэкапа, есть отдельный разбор.

Следят за местом, но не за деньгами. Место в облаке не кончается - в этом и подвох. Бюджетный алерт у провайдера ставится за пять минут и спасает от счёта, который заметили только в конце квартала.

Автоудаление воюет с минимальным сроком. Настроили политику хранения на 30 дней, положили данные в ледяной класс с минимальным сроком 12 месяцев - и платите за удалённое.

Когда гибрид не нужен

Схема не универсальная, и есть ситуации, где она проигрывает.

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

Отдельный случай - запреты. Государственная тайна, отдельные требования по значимым объектам критической информационной инфраструктуры, внутренние политики головной компании. Там вторая площадка тоже своя, и обсуждать облако бессмысленно.

И последнее, житейское: гибрид требует, чтобы за ним кто-то следил. Если в компании один админ на всё и он уже перегружен, лишний контур без владельца просто тихо сломается.

Как выбрать провайдера

Пять вопросов, которые стоит задать до подписания договора, остальное - детали.

Где физически стоят серверы: нужен адрес площадки, слово «Россия» на лендинге ничего не гарантирует. Что написано в SLA: доступность 99,9 % - это около 43 минут простоя в месяц, и отдельно смотрите, чем компенсируют нарушение - деньгами или кредитами на будущие услуги. Как тарифицируются операции и исходящий трафик: сравнение провайдеров по одной цене за гигабайт хранения ничего не покажет.

Дальше два вопроса, которые задают реже всего. Сколько будет стоить и сколько займёт выгрузка всего объёма, если вы решите уйти. И какое время реакции поддержки зафиксировано в приложении к договору - цифра с сайта в споре не поможет.

С чего начать

1. Сделайте опись: что за данные, сколько занимают, как часто к ним обращаются, есть ли среди них персональные.
2. Возьмите один некритичный участок - архив логов, тестовые среды, старые проекты - и настройте на нём выгрузку в облако.
3. Прогоните восстановление до того, как расширять схему. Засеките время и сравните с тем RTO, который вы пообещали бизнесу: обычно фактическое оказывается больше.
4. Включите бюджетный алерт с первого дня и посмотрите на счёт через месяц - обычно он отличается от расчётного.
5. Запишите схему в регламент: что где лежит, кто владелец, где ключи, как восстанавливать. Через год вы это не вспомните.

Частые вопросы

Можно ли подключить облачное хранилище как обычный сетевой диск?

Да, через облачный шлюз или клиент вроде rclone с монтированием. Работать будет, но скорость и стабильность упрутся в канал, поэтому для продуктивных данных так не делают.

Что быстрее - забрать 5 ТБ из облака или восстановить с локальной копии?

Локальная быстрее в разы. По каналу 100 Мбит/с 5 ТБ поднимаются около пяти суток, плюс счёт за исходящий трафик. Облачную копию держат как страховку на случай, когда локальной уже нет.

Считается ли облачная копия отдельной площадкой по правилу 3-2-1?

Да, требование «одна копия вне площадки» она закрывает. Но три копии всё равно должны быть тремя: продуктив, локальный бэкап и облако.

Нужен ли выделенный канал до провайдера?

Для ночных бэкапов обычно хватает интернета с HTTPS. Выделенный канал имеет смысл, когда объёмы регулярные, окно короткое или данные нельзя пускать через общий интернет.

Провайдер российский, а ЦОД в Казахстане - подходит по 152-ФЗ?

Нет. Закон говорит про расположение самих баз данных, юрисдикция провайдера тут ничего не решает. Уточняйте площадку и фиксируйте её в договоре.

По теме: облачное хранение данных: преимущества и недостатки для бизнеса · программно-определяемые хранилища: архитектура и внедрение