Бэкапы за границей при базе в РФ: практический разбор рисков

MAATRIX

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

Как бэкап оказывается за границей — типичные сценарии

Почти никто не принимает решение «положим бэкапы в другой юрисдикции» осознанно. Это почти всегда побочный эффект удобства или инерции:

• Managed backup у облачного провайдера. Многие панели резервного копирования (в том числе встроенные в популярные SaaS для мониторинга и CI) по умолчанию создают бакет в ближайшем к штаб-квартире регионе — обычно EU или US — и администратор просто не меняет регион при первой настройке.
• rclone/restic/borgbackup с давно забытым конфигом. Классика: rclone config был один раз настроен на Backblaze B2, AWS S3 или Wasabi, потому что там дешевле или был бесплатный тестовый период, и с тех пор cron гоняет туда данные годами.
• Готовые SaaS-бэкапы вроде BorgBase, Rsync.net, Tarsnap. Удобные и надёжные сервисы, но физически — сервера в США или Европе.
• Репликация Proxmox Backup Server или Veeam на удалённый инстанс. Если второй PBS/Veeam repository поднят «для надёжности» на VPS у другого провайдера, и этот провайдер зарубежный — реплика уезжает вместе с бэкапом.
• Синхронизация с личным облаком. Скрипт архивирует базу и через rclone copy или rsync кладёт архив в Dropbox, Google Drive или OneDrive — часто как «второй контур» поверх основного бэкапа, настроенный кем-то на скорую руку.
• WAL-архивирование и логическая репликация БД. PostgreSQL с archive_command, указывающим на удалённый S3-bucket, или реплика MySQL, поднятая на зарубежном сервере «для аналитики», по факту хранит полную копию боевых данных.

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

Юридическая сторона: почему это может противоречить локализации

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

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

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

Практический риск: бэкап недоступен именно тогда, когда нужен

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

• Блокировка сервиса на уровне сети. Провайдер объектного хранилища может попасть под блокировку по IP-диапазону или домену — не потому что он плохой, а потому что рядом в том же CDN или облаке оказался заблокированный ресурс. Восстановление базы в 3 часа ночи — не время выяснять, что нужный endpoint недоступен из РФ.
• Блокировка платежа. Зарубежная карта или платёжная система, привязанная к аккаунту хранилища, перестаёт проходить — подписка замораживается, доступ к данным сохраняется какое-то время, но продлить или расширить хранилище становится нельзя.
• Гео-ограничения на стороне сервиса. Некоторые зарубежные сервисы сами ограничивают или полностью прекращают обслуживание аккаунтов, зарегистрированных из России — с уведомлением за 30 дней или вовсе без него.
• Просто исходящий канал. Даже без блокировки, скорость и стабильность канала до зарубежного дата-центра зависят от маршрутизации, которая может меняться без предупреждения — восстановление 200 ГБ базы по нестабильному каналу превращается в лотерею именно в момент аварии.

Ключевая мысль: бэкап, который нельзя скачать в момент восстановления, по факту не является бэкапом — вне зависимости от того, насколько аккуратно он создавался. Риск здесь не «а вдруг заблокируют», а в том, что доступность зарубежного хранилища — это переменная, которую администратор в России не контролирует и не может гарантировать в SLA перед своим бизнесом.

Как провести аудит собственной схемы бэкапов

Прежде чем что-то менять, нужно честно понять, что происходит сейчас. Это занимает от часа до дня в зависимости от числа систем, и делается один раз, а дальше — по чек-листу раз в квартал.

1. Составьте список всех мест, куда физически попадают копии данных. Не «что написано в документации», а что реально настроено: crontab -l на каждом сервере, все rclone listremotes, все repository у restic/borgbackup, все bucket policy у объектных хранилищ, все настройки backup-плагинов в панелях управления (cPanel, Proxmox, CyberPanel и т.д.).
2. Проверьте юрисдикцию хранилища физически, а не по названию бренда. «Российский аккаунт» в облаке международного провайдера может физически лежать в европейском регионе — регион нужно смотреть в настройках bucket, а не полагаться на то, что компания открыла юрлицо в РФ.

   # для S3-совместимого хранилища через rclone
   rclone config show <remote-name>
   # смотрим endpoint и region — они выдают реальную локацию

1. Проверьте WAL-архивы и потоковую репликацию БД отдельно — это самый часто забываемый канал утечки бэкапа за рубеж, потому что визуально это не «бэкап», а «настройка отказоустойчивости».

   # PostgreSQL: где реально архивируется WAL
   sudo -u postgres psql -c "SHOW archive_command;"

1. Проверьте, что именно попадает в архив. Дамп всей базы целиком — это, скорее всего, персональные данные. Если можно исключить таблицы с ПДн из архива, уходящего за рубеж, а держать их только в РФ-копии — это отдельный, менее болезненный вариант архитектуры.
2. Зафиксируйте результат в одном документе — таблица «источник данных → куда бэкапится → в какой стране → кто отвечает». Без этого документа через полгода аудит придётся делать заново с нуля.

Отдельно: то, что бэкап физически уехал за рубеж, не значит, что он вообще рабочий — это соседний, но другой вопрос. Как проверить сам факт восстановимости копии, без разворачивания полного окружения, разобрано в статье «Как проверить, что бэкап рабочий, не восстанавливая всё».

Вариант решения: резервное хранилище тоже в России

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

Схема на практике — второй VPS в другом регионе РФ как приёмник бэкапов через restic или borgbackup:

# на сервере-источнике: инициализация repository на удалённом VPS в РФ
export RESTIC_REPOSITORY="sftp:backup-user@backup-host-ru:/data/restic-repo"
export RESTIC_PASSWORD="сложный-пароль-из-менеджера-паролей"

restic init

# ежедневный бэкап с ротацией
restic backup /var/lib/postgresql/data --tag daily
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Второй сервер должен быть у другого юрлица/провайдера, чем прод — иначе диверсификация мнимая: при бане аккаунта или сбое одного провайдера теряются обе копии разом. Разбор этой смежной ошибки — в статье «Антипаттерн: все бэкапы у одного провайдера».

Для примера — таблица, чем такая схема отличается от привычной «AWS S3 / Backblaze за рубежом»:

Как рассчитать объём диска, выбрать инструмент и настроить такой сервер под бэкапы с нуля — в статье «Лучший VPS для бэкапов в России».

Если копия за рубежом действительно нужна — шифруйте перед отправкой

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

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

restic и borgbackup шифруют репозиторий на клиенте по умолчанию — это удобно, потому что не требует отдельного шага:

# restic уже шифрует репозиторий ключом из RESTIC_PASSWORD,
# сервер хранения видит только зашифрованные блоки
export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.amazonaws.com/mybucket/backups"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
restic backup /data --tag offsite-encrypted

Если инструмент не шифрует сам (простой tar + rclone copy), шифруйте архив явно перед отправкой, например через age или gpg:

tar czf - /var/lib/postgresql/data | age -r age1qy... -o backup-$(date +%F).tar.gz.age
rclone copy backup-$(date +%F).tar.gz.age remote-eu:offsite-bucket/

Критичный момент, который чаще всего и обесценивает всю схему: ключ шифрования не должен храниться там же, где бэкап, и не должен покидать периметр РФ вместе с архивом. Если ключ лежит в том же бакете или в конфиге, который реплицируется вместе с данными — шифрование существует только на бумаге. Ключ храните отдельно: в менеджере секретов на самом источнике, в оффлайн-хранилище или в отдельном закрытом бакете внутри РФ с ограниченным доступом. Более подробный разбор именно этой модели доверия — в статье «Бэкап с шифрованием на чужое хранилище: схема доверия».

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

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