С 1 сентября 2015 года требование о локализации персональных данных вступило в силу. Операторы обязаны хранить и обрабатывать персональные данные граждан РФ в базах на территории России. Многие компании за лето перенесли продуктивные системы на российские площадки, но забыли про резервные копии. А бэкап, который уезжает в зарубежный дата-центр, – это та же база персональных данных, только в другом файле. Локализация продакшена без локализации бэкапов не закрывает требование 242-ФЗ.

Где прячется зарубежный вывоз

Самый частый случай – облачные сервисы резервного копирования. Вы настраиваете агент, он шлёт инкременты в «облако», а где физически лежат тома, не знаете. У большинства западных провайдеров регион хранения по умолчанию – Европа или США. Второй случай – реплика на DR-площадку за границей: схема выглядела разумной до сентября, теперь это нарушение.

Проверьте три вещи. Первое – географию каждого хранилища, куда уходят копии: snapshot СУБД, файловые дампы, образы виртуальных машин, архивы почты. Второе – маршруты репликации между площадками. Третье – внешние SaaS, которые сами делают бэкап ваших данных на своей стороне (CRM, трекеры, helpdesk). Последний пункт упускают чаще всего: чат-бот или система поддержки нередко хранят переписку и контакты клиентов у вендора. Если вы внедряли ботов в клиентском сервисе, уточните, где провайдер держит логи диалогов и их резервные копии.

Схема хранения внутри РФ

Базовый принцип – данные не покидают периметр страны ни в одной точке жизненного цикла копии. Рабочая схема для большинства заказчиков выглядит так:

  • Локальный уровень. Ежедневные инкременты на дисковом массиве рядом с продуктивом – для быстрого восстановления отдельных объектов.
  • Региональный уровень. Полные копии в российском дата-центре в другом городе – для защиты от потери площадки. Канал между площадками не выходит за пределы РФ.
  • Холодный уровень. Долговременный архив на ленте или в объектном хранилище отечественного провайдера, с проверкой геопривязки в договоре.

Если вы уже размещаете продуктив на российских мощностях после переезда, бэкап логично разворачивать у того же класса провайдеров – мы разбирали выбор площадок в материале про хостинг персональных данных в России. Зафиксируйте регион хранения письменно: устных заверений менеджера для проверки Роскомнадзора недостаточно.

Шифрование, контроль и тесты восстановления

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

Отдельно – наблюдаемость процесса. Резервное копирование незаметно деградирует: задание падает по таймауту, инкремент не закрывается, том заполнился. Заведите задания бэкапа в общую систему мониторинга вместе с прикладными сервисами. Подходы к сквозному контролю мы описывали в заметке про распределённую трассировку – те же принципы корреляции событий работают и для инфраструктурных задач.

И главное правило, которое нарушают почти все: бэкап без теста восстановления – это не бэкап, а надежда. Раз в квартал поднимайте систему из копии на изолированном стенде и замеряйте реальное время восстановления.

Вывод

Локализация бэкапов – это не отдельный проект, а часть единой архитектуры хранения данных. Сведите карту потоков копий, уберите зарубежные точки, зашифруйте тома и регулярно проверяйте восстановление. Сама схема под требования 242-ФЗ и под ваши RPO/RTO проектируется на уровне инфраструктуры хранения и резервного копирования.