Перенос сервера в другую страну по требованию закона

MAATRIX

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

Когда речь идёт именно о требовании закона, а не о совете

Добровольный переезд сервера — это когда вы сами решили, что в другой стране дешевле, ближе к аудитории или надёжнее, и выбираете момент по своему усмотрению. Вынужденный переезд по требованию закона — принципиально другая ситуация: у него есть внешний триггер (изменение законодательства, предписание регулятора, решение суда) и часто — конкретный срок исполнения.

Типичные основания: требования о локализации персональных данных граждан определённой страны (в России — 152-ФЗ, подробно о самом требовании — в статье про локализацию баз ПДн и в разборе 152-ФЗ и где законно держать сервер с персональными данными), предписания об удалении или переносе данных после проверки, изменение статуса юрисдикции для трансграничной передачи данных, отзыв лицензии у провайдера в стране присутствия. Какое именно основание применимо и что оно требует буквально — задача юриста. Инженерная задача начинается после того, как эта определённость есть: перенести то, что нужно, туда, куда нужно, в срок, который дан, и суметь это доказать.

Чем вынужденный переезд отличается от планового

Разница не в технологиях миграции — команды pg_dump, rsync и docker save работают одинаково независимо от причины переезда. Разница — в трёх вещах, которые меняют весь процесс планирования.

Срок исполнения задан извне. При добровольном переезде вы сами выбираете окно миграции: ночь с пятницы на субботу, период низкой нагрузки, время после релиза. При исполнении предписания срок обычно указан явно — «в течение 30 дней» или «к определённой дате» — и не подстраивается под ваш календарь. Часть привычных практик безопасной миграции (недели параллельной работы старой и новой инфраструктуры «на всякий случай») может быть просто недоступна по времени: планирование идёт от жёсткого дедлайна, а не от комфортного запаса.

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

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

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

Полный перенос или разделение данных: что выбрать

Первое архитектурное решение — вам действительно нужно перенести весь сервер целиком, или только часть данных (обычно — персональные данные определённой категории граждан), а остальная инфраструктура может продолжать работать там же, где работала?

Это не техническое решение — его должен подтвердить юрист по формулировке конкретного требования. Но с инженерной стороны это два разных проекта с разной сложностью:

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

Технические схемы разделения данных по юрисдикциям

Ниже — не готовые решения «под ключ», а рабочие паттерны, из которых собирается конкретная схема под вашу базу и приложение.

Вынесенная таблица/схема с ПДн через Foreign Data Wrapper (PostgreSQL). Основная база остаётся в прежней локации, а таблицы с персональными данными физически хранятся на сервере в требуемой юрисдикции. Приложение обращается к ним прозрачно через FDW:

-- на основном сервере (старая локация)
CREATE EXTENSION IF NOT EXISTS postgres_fdw;

CREATE SERVER pdn_server
  FOREIGN DATA WRAPPER postgres_fdw
  OPTIONS (host '10.20.0.5', port '5432', dbname 'pdn_ru');

CREATE USER MAPPING FOR app_user
  SERVER pdn_server
  OPTIONS (user 'app_ro', password 'из secret-хранилища, не в файле');

IMPORT FOREIGN SCHEMA public
  LIMIT TO (users_personal_data)
  FROM SERVER pdn_server
  INTO app_schema;

Плюс — минимум изменений в коде приложения, запросы работают почти как раньше. Минус — задержка сети между двумя локациями ложится на каждый запрос к этой таблице, и при высокой нагрузке FDW не всегда даёт приемлемую производительность — нужно тестировать на своём профиле нагрузки, а не верить на слово.

Отдельный сервис-шлюз для ПДн. Вместо прямого доступа к БД — небольшой API-сервис, который живёт в требуемой юрисдикции, хранит только чувствительные данные и отдаёт основному приложению токен/ссылку вместо самих данных (принцип токенизации):

Основное приложение (старая локация)
   └── обращается по HTTPS к pdn-service.example-uk.internal
         └── PostgreSQL с персональными данными (Великобритания)
         └── возвращает не сами данные, а токен: "ref-8f2a91"

Это чище архитектурно и проще обосновать регулятору («персональные данные физически не покидают требуемую юрисдикцию, наружу отдаётся только непрозрачный токен»), но требует реальной переработки кода приложения — везде, где раньше был прямой SQL-запрос к таблице с ПДн, теперь должен быть вызов сервиса.

Маршрутизация на уровне сети/прокси по географии пользователя. Если критерий разделения — не тип данных, а гражданство/локация самого пользователя (например, данные пользователей из одной страны должны храниться там, а из других — где угодно), разделение делают на уровне входящего трафика:

geo $user_region {
    default        row;
    77.88.0.0/16   ru;   # пример диапазона, не используйте как есть
    95.108.0.0/16  ru;
}

upstream backend_ru { server 10.0.1.10:8080; }
upstream backend_row { server 10.0.2.10:8080; }

server {
    location /api/ {
        proxy_pass http://backend_$user_region;
    }
}

Определение "гражданства" по IP-диапазону — грубый и ненадёжный метод (VPN, мобильные сети, роуминг ломают его сразу), поэтому в реальных схемах геолокация IP — это только первый фильтр, а окончательное решение о том, где хранить данные конкретного пользователя, обычно принимается на уровне бизнес-логики — по адресу регистрации, гражданству в анкете, явному согласию — а не по IP на момент запроса.

Асинхронная репликация с фильтрацией по строкам. Если нужно, чтобы копия ПДн была именно в целевой юрисдикции, а не только доступна из неё, используют логическую репликацию PostgreSQL с публикацией, ограниченной нужными строками:

-- на источнике
CREATE PUBLICATION pdn_pub FOR TABLE users_personal_data
  WHERE (country_code = 'RU');

-- на целевом сервере в нужной юрисдикции
CREATE SUBSCRIPTION pdn_sub
  CONNECTION 'host=old-server dbname=main user=repl_user'
  PUBLICATION pdn_pub;

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

Общие шаги самой миграции (снятие бэкапа, перенос, проверка целостности, переключение) не отличаются от обычного переноса базы — они разобраны в статье перенос большой базы с минимальным даунтаймом. Специфика вынужденного переезда — именно в выборе схемы разделения выше и в сжатых сроках на неё.

Как задокументировать миграцию для регулятора

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

• Манифест миграции — простой текстовый или JSON-файл, фиксирующий, что именно перенесено, откуда и куда, с точными timestamp:

{
  "migration_id": "pdn-migration-2026-09",
  "requirement_ref": "внутренний номер предписания/основания",
  "started_at": "2026-09-10T21:00:00+03:00",
  "completed_at": "2026-09-11T03:40:00+03:00",
  "source": {"host": "old-server.example.com", "location": "old-country"},
  "target": {"host": "new-server.example.com", "location": "required-country"},
  "objects_moved": ["users_personal_data", "orders_pii_subset"],
  "verification": {"method": "sha256 checksum + row count diff", "status": "passed"}
}

• Контрольные суммы до и после — простое, но убедительное доказательство, что перенесённые данные не повреждены и не подменены:

# на старом сервере до переноса
pg_dump -Fc -t users_personal_data mydb | sha256sum > before.sha256

# на новом сервере после переноса
pg_dump -Fc -t users_personal_data mydb | sha256sum > after.sha256
diff before.sha256 after.sha256

• Журнал доступа и удаления старых копий — если требование предполагает не просто копирование, а именно перенос с прекращением хранения в прежней локации, нужен лог, когда и как старые данные были удалены или доступ к ним закрыт (снятие прав на уровне БД, физическое удаление файлов, отзыв сетевого доступа).
• Версионирование конфигураций — файлы docker-compose.yml, конфиги nginx, миграционные скрипты имеет смысл держать в git с осмысленными коммитами и датами — это естественная и уже привычная форма документирования, которая заодно служит доказательством процесса.

Как долго и в каком виде хранить такую документацию — снова вопрос к юристу применительно к конкретному основанию для переезда: единого универсального срока нет.

Чек-лист подготовки к миграции по требованию закона

• Зафиксировать точный срок исполнения из документа/предписания и отсчитать от него реальный технический дедлайн с запасом на непредвиденное (минимум несколько дней буфера, если срок это позволяет).
• Определить с юристом: нужен полный перенос сервера или только выделенного набора данных — от этого зависит вся дальнейшая архитектура.
• Провести инвентаризацию: какие именно таблицы/файлы/сервисы подпадают под требование, кто из приложений и сервисов к ним обращается.
• Выбрать техническую схему разделения (FDW, отдельный сервис, репликация с фильтром, полный перенос) исходя из того, сколько времени реально есть на разработку и тестирование.
• Арендовать и подготовить сервер в целевой юрисдикции заранее, не в последний момент — настройка ОС, сети, СУБД и файрвола сама по себе занимает время, которое лучше не тратить из бюджета основного дедлайна.
• Настроить перенос данных (репликация или разовый перенос) и обязательно проверить его на копии/staging-окружении, а не сразу на проде — даже при сжатых сроках.
• Подготовить план отката на случай, если после переключения обнаружится проблема — при сжатых сроках соблазн пропустить этот пункт особенно велик, но именно здесь чаще всего случаются самые дорогие ошибки.
• Настроить логирование и манифест миграции заранее, до начала переноса, а не задним числом после.
• Проверить, что старые копии данных корректно закрыты/удалены там, где это требуется условиями переноса.
• Обновить внутреннюю документацию и, если применимо, уведомить связанные стороны (клиентов, партнёров, само ведомство) в сроки, предписанные требованием — здесь снова нужна сверка с юристом по конкретной формулировке обязанности уведомления.

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

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