Привет, Хабр! В связи с последними событиями бизнес крепко задумался — где безопасно разворачивать ИТ-системы, чтобы они стабильно работали? Популярность набирают самые разные идеи, от подземных ЦОДов до полного и окончательного on-premise. А что если бэкапиться в облаке, но вынести данные далеко-далеко, за тридевять земель — за границу… Законно ли это? И как все обустроить?
Перевезти данные за границу даже для резерва — дело, сами понимаете, не самое обыденное. На пути стоят федеральные законы, физические ограничения каналов связи и, само собой, бюджет.
Мы собрали пять вопросов, которые чаще всего задают про резервирование за рубежом, и попросили ответить наших экспертов: ИТ-директора OXYGEN Александра Будкина и эксперта по работе с госорганами Филиппа Новикова. Какие данные можно отправить за рубеж уже сейчас, что делать с ПДн, сколько времени займет займет бэкап данных в условный Узбекистан? Разбираемся!
1. Какие принципы резервирования будут рабочими в текущей ситуации?
Александр Будкин, ИТ-директор OXYGEN:
Сегодня понятие отказоустойчивости вышло за рамки конкретного дата-центра — нужна геораспределенность в самом широком смысле. Слишком многие ощутили на себе, каково это — остаться без работающих клиентских сервисов. А другие не ощутили, но ощутить бы не хотели. Поэтому решения по дублированию инфраструктуры принимаются на уровне руководства, а не только ИТ-службы. Критерии выбора облачной площадки тоже сдвинулись: теперь смотрят, в каких городах и странах есть кластеры у облачного провайдера, какие схемы резервирования предлагают.
Мы советуем опираться на три принципа:
● Трансграничный Disaster Recovery — хранение копий ключевых данных и теплого резерва в дружественных юрисдикциях.
● Гибридная схема предполагает on-prem плюс облако и хотя бы две зоны доступности. Так остается пространство для маневра: что останется на своем оборудование, какие серверы подхватят нагрузку в случае сбоев.
● Независимость от единственного провайдера — прямая реализация тезиса «не храните все яйца в одной корзине». Основной площадкой может быть платформа одного провайдера, а другая — резервной, но так, чтобы между ними не было связи в управлении.
Вот арифметика независимости: три провайдера, и у каждого три зоны доступности — и вот у вас уже девять точек размещения. «Что-то на богатом» — или, как сейчас говорят, роскошный максимум.
Надо также учитывать, что именно будем резервировать. Слой виртуализации и слой приложений защищаются по-разному, а сами приложения должны уметь жить в разных облаках. Здесь пригодится провайдер, который понимает, как распределить ваши системы между платформами.
2. Какие схемы бывают и чем платим за скорость восстановления?
Александр Будкин, ИТ-директор OXYGEN:
Трансграничный Disaster Recovery — это всегда баланс между стоимостью и метриками. Сколько времени простоя и потерянных данных вы готовы пережить, за какую доступность готовы заплатить — из ответов на эти вопросы рождается ваша схема.
Варианты трансграничного резерва такие, от самого простого:
● Только бэкапы, без инфраструктуры. Так вы не тратите деньги на строительство полноценной площадки, при этом у вас будет достаточная копия критичных данных. В случае ЧС инфраструктура поднимается отдельно, плюс это не всегда можно сделать быстро.
● Теплый резерв — базовая инфраструктура, куда данные реплицируются с небольшим отставанием. При сбое резерв масштабируют до рабочей нагрузки и переключают трафик.
● Горячий резерв. Это уже Active-Active: две площадки работают одновременно, данные синхронизируются почти мгновенно, переключение занимает секунды. Это самый надежный вариант и самый дорогой, потому что вы, по сути, платите за еще одну полноценную инфраструктуру.
3. Какие данные и системы можно резервировать за рубежом, а какие нет?
Филипп Новиков, эксперт по работе с госорганами OXYGEN:
За рубежом можно резервировать:
● Чисто технологические и бизнес-данные (без ПДн). Исходный код программных продуктов, не связанных с КИИ, ERP-системы без карточек сотрудников и клиентов, каталоги товаров, логистические цепочки, техническая документация и контент (медиафайлы, картинки, описания).
● Персональные данные граждан РФ. Только в качестве «вторичной» (зеркальной) копии. Согласно ч. 5 ст. 18 ФЗ № 152 «О персональных данных», в России действует правило первичной локализации.
Как это работает технически:
Когда пользователь регистрируется на вашем сайте, его данные обязаны в первую очередь прилететь в дата-центр на территории РФ, записаться там в основную базу данных и пройти систематизацию.
Как сделать бэкап за рубеж легально:
После того, как данные зафиксированы в РФ, закон не запрещает настроить репликацию (копирование) этого массива в ЦОД дружественной страны (например, в Казахстан или Узбекистан). Перечень стран есть в обновленном приказе Роскомнадзора № 253 от 16 сентября 2026 г. (вступает в силу с 30.10.2026 г.).
Например:
|
Статус в проекте перечня |
Страны |
Режим передачи |
|
Включены |
Казахстан, Узбекистан, Кыргызстан, Армения, Беларусь, Таджикистан, Азербайджан, Китай, Индия, Вьетнам, Таиланд, Бразилия, ЮАР, Турция, Сербия, Монголия |
Сразу после уведомления РКН |
|
Не включены |
ОАЭ, Саудовская Аравия |
Сбор сведений + ожидание 10 рабочих дней |
Рабочая схема для трансграничного бэкапа ПДн получается такой:
● Сбор данных и первичная база остаются в РФ.
● Уведомление РКН до начала трансграничной передачи данных.
● Перенос зашифрованной копии в зарубежный кластер, например в Казахстан или Узбекистан.
● При этом ключи шифрования хранятся на территории РФ.
4. Что с задержками: насколько они мешают при резерве в другой стране?
Александр Будкин, ИТ-директор OXYGEN:
Задержка зависит от маршрута, каналов и расстояния. Как убрать ее полностью — человечество пока не придумало. Можно только определить для себя границы допустимого.
Если пинг начинается от 30 мс, веб-сайт, корзина и каталог работают, но пользователи задержку почувствуют. Это нормальная плата за то, чтобы сервис был доступен в аварийном режиме. Все-таки Disaster Recovery — это всегда ответ на катастрофу, вообще не штатная ситуация. Медленный сайт лучше недоступного сайта, верно?
С базами данных так не получится: им нужно подтверждение, что запись действительно сделана. Для 1С и SAP трансграничный резерв тоже выглядит сомнительно. И вопрос соблюдения 152-ФЗ тоже остается — эти системы работают с персональными данными, а значит, для них действуют все те правила, о которых говорили ранее.
5. Сколько времени занимает запуск зарубежного резерва?
Александр Будкин, ИТ-директор OXYGEN:
Чтобы оценить время, существующий объем данных делим на скорость канала за рубеж. Получаем порядок времени первичной загрузки.
Но важно иметь в виду, что это самый просто вариант — и он относится только к бэкапам. Полноценная резервная площадка требует проектирования, помимо копирования данных, нужно настроить саму инфраструктуру. И делать это нужно не во время катастрофы.
Вы определяете:
● какие сервисы и данные будете резервировать,
● где именно — в другом ЦОДе, у другого провайдера, в другом регионе, в другой стране,
● в каком порядке происходит резервирование и что нужно учесть: если речь о зарубежном кластере, то мы действуем в соответствии с законодательством, если разворачиваем площадку у второго провайдера — надо предусмотреть корректную работу приложений на обеих платформах.
Далее мы настраиваем сетевую связность между площадками, чтобы быстро запустить нагрузки на резервную в случае сбоя. И, разумеется, планируем регулярные тесты — без них это будет «фантомная» резервная площадка, которая как бы есть, но на самом деле на ней ничего не работает.
Кстати, интересный кейс: при трансграничном резервировании скорость международного канала ограничена, поэтому бэкап даже 20 Тб данных может занять до месяца. Чтобы сократить время первоначальной синхронизации с DR-площадкой, можно скопировать данные по местным каналам в ближайший кластер, а далее разобрать оборудование и перевезти за рубеж, где в итоге будут храниться бэкапы.
—
Есть ли в вашей компании резервная площадка? Как смотрите на трансграничное резервирование? И что, по вашему, в этой теме самое важное?
А мы всегда рады видеть вас в Telegram-канале OXYGEN — там мы регулярно пишем про облака, ЦОДы и кибербез.
ссылка на оригинал статьи https://habr.com/ru/articles/1098222/