SSD Nodes Learn Hosting plans →
Руководства Matt ConnorАвтор: Matt Connor

Где разместить VPS для хранения данных из России

Выбор локации для VPS с учетом требований 152-ФЗ и сетевых задержек. Узнайте, почему пропускная способность важнее RTT и как правильно хранить персональные данные граждан РФ.

Где разместить VPS для хранения данных, если вы находитесь в России

Покупка VPS для хранения данных из России — это два решения, и только одно из них является техническим. Техническое решение заключается в выборе места расположения диска, и для массового хранения данных важнее пропускная способность и потеря пакетов, а не время кругового обхода (RTT). Юридическое решение заключается в том, что именно вы будете там хранить, поскольку федеральный закон № 152-ФЗ по-разному трактует ваши личные архивы и персональные данные других людей.

В этом руководстве не приводятся показатели задержки. Единственный важный путь — это маршрут между вашим соединением и сервером, который вы рассматриваете, поэтому каждое измерение ниже — это команда, которую вы запускаете самостоятельно.

Почему время кругового обращения (RTT) почти не влияет на передачу больших объемов данных

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

Протокол TCP (transmission control protocol) не отправляет один пакет и не ждет подтверждения. Он поддерживает окно неподтвержденных данных в процессе передачи, и Linux автоматически увеличивает это окно до нескольких мегабайт. Один поток на канале с задержкой 50 ms может передавать сотни мегабит в секунду после того, как окно будет открыто. RTT определяет лишь то, сколько времени потребуется соединению для выхода на рабочую скорость. Он не определяет скорость, на которой соединение стабилизируется.

RTT действительно вредит в одном конкретном сценарии: когда на одну операцию приходится один круговой цикл. Если примонтировать удаленный диск как файловую систему и копировать 40,000 мелких файлов, каждый файл потребует как минимум одного RTT, а зачастую и нескольких — для открытия, записи и закрытия. В этом случае передача будет идти со скоростью примерно один файл за RTT, независимо от того, какой объем пропускной способности вы приобрели. Именно поэтому инструменты, которые упаковывают данные в крупные объекты и отправляют несколько объектов одновременно (например, restic или rclone с параллельной передачей), значительно превосходят примонтированную удаленную файловую систему на том же канале связи.

Потеря пакетов — основная причина замедления на длинных маршрутах

Расстояние превращает небольшой процент потерь в значительное падение скорости. Именно по этой причине возникает ситуация, когда «ping в норме, а передача данных идет медленно». Алгоритм управления перегрузкой по умолчанию в Ubuntu — CUBIC. Он интерпретирует любой потерянный пакет как признак перегрузки сети и сокращает окно отправки. Восстановление этого окна требует множества циклов обмена данными (round trips), а на длинных маршрутах каждый такой цикл занимает много времени. Поэтому потеря 0.5 процента пакетов при задержке 50 мс снижает пропускную способность гораздо сильнее, чем те же 0.5 процента при задержке 5 мс.

Алгоритм BBR реагирует на измеренную полосу пропускания и задержку, а не считает каждую потерю признаком перегрузки. Благодаря этому он лучше работает на длинных маршрутах, где периодически теряются пакеты. Включите его на стороне отправителя: на VPS это ускорит ваши загрузки, а на локальной машине — выгрузку данных.

printf 'net.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\n' | sudo tee /etc/sysctl.d/99-bbr.conf
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control

Последняя команда должна вывести net.ipv4.tcp_congestion_control = bbr. Выполните замеры с помощью iperf3 до и после изменений, вместо того чтобы предполагать эффективность метода. На качественном канале без потерь этот алгоритм обычно не дает никакого прироста.

Какие регионы практически ближе

Франкфурт, Амстердам, Варшава и Хельсинки — это европейские локации, где хостинг-провайдеры концентрируют мощности для работы с российскими сетями, и именно их вам будут рекомендовать. Расстояние на карте плохо предсказывает реальное качество соединения. Трафик от российского провайдера до дата-центра в Хельсинки может проходить через Франкфурт или Стокгольм, а два провайдера в одном городе могут использовать совершенно разные магистральные каналы. Если вы находитесь восточнее Урала, западная Европа будет далеко в любом смысле, и маршруты через Алма-Ату или Ереван иногда работают лучше.

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

Измерение собственного пути с помощью mtr

sudo apt update
sudo apt install -y mtr-tiny iperf3
sudo mtr -rwzbc 200 198.51.100.10

-r выводит отчет и завершает работу, -w предотвращает обрезание имен хостов, -z показывает, к какой сети относится каждый узел, -b отображает имя и IP-адрес одновременно, а -c 200 отправляет 200 циклов, чтобы процент потерь стал статистически значимым.

Сначала смотрите на последнюю строку. Потери на промежуточном узле, которые исчезают на последующих, не являются потерями на вашем пути: маршрутизаторы отдают низкий приоритет генерации ICMP-ответов, необходимых mtr. Поэтому загруженный магистральный маршрутизатор может показывать потери, при этом корректно пересылая ваш трафик. Реальными являются только те потери, которые сохраняются до самого конечного узла. Любое значение выше примерно 1 процента на конечном узле будет сильно замедлять передачу больших объемов данных, и никакой выбор инструмента передачи это не исправит.

Если сеть фильтрует ICMP и трассировка прерывается на раннем этапе, выполните трассировку по протоколу TCP до порта, который вы планируете использовать:

sudo mtr -rwc 100 -T -P 443 198.51.100.10

Маршрутизация часто бывает асимметричной, поэтому запустите mtr с VPS в сторону вашего собственного адреса. Если ваше домашнее подключение находится за CGNAT (carrier grade network address translation), ваш адрес недоступен извне, и обратная трассировка остановится внутри сети вашего провайдера. Это ожидаемое поведение, а не ошибка.

Измерение пропускной способности с помощью iperf3

Запустите сервер на VPS и откройте порт только на время проведения теста:

sudo apt install -y iperf3
sudo ufw allow 5201/tcp
iperf3 -s -p 5201

Затем с машины, на которой находятся данные для загрузки, выполните:

iperf3 -c 198.51.100.10 -p 5201 -t 30 -P 1
iperf3 -c 198.51.100.10 -p 5201 -t 30 -P 4
iperf3 -c 198.51.100.10 -p 5201 -t 30 -P 4 -R

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

Остановите сервер нажатием Ctrl+C после завершения тестов, затем закройте порт. Оставленный в режиме ожидания iperf3 -s позволяет любому пользователю в интернете использовать ваш лимит трафика.

sudo ufw delete allow 5201/tcp

Что закон № 152-ФЗ говорит о хранении данных на VPS за пределами России

Федеральный закон № 152-ФЗ от 27 июля 2006 года «О персональных данных» — это тот самый закон, который имеют в виду, когда говорят о «локализации данных». Три его статьи определяют, является ли использование зарубежного VPS для хранения данных проблемой для вас. Ниже приведено описание текста закона. Это не является юридической консультацией.

Статья 1 часть 2 проводит границу. Закон не применяется к обработке персональных данных физическим лицом исключительно для личных и семейных нужд, при условии, что такая обработка не нарушает права субъектов персональных данных. Ваши семейные фотографии и резервные копии сервера, который вы используете для личных целей, находятся по эту сторону границы.

Статья 18 часть 5 содержит требование о локализации. Оно применяется к оператору, то есть к тому, кто определяет цели обработки. С 1 июля 2025 года эта норма читается как запрет, а не как предписание. В редакции, введенной Федеральным законом № 23-ФЗ от 28 февраля 2025 года, при сборе персональных данных, в том числе через интернет, не допускается запись, систематизация, накопление, хранение, уточнение или извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся за пределами территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4 и 8 части 1 статьи 6. Предыдущая версия этого требования вступила в силу 1 сентября 2015 года согласно Федеральному закону № 242-ФЗ от 21 июля 2014 года.

Статья 12 регулирует трансграничную передачу. В редакции, действующей с 1 марта 2023 года, введенной Федеральным законом № 266-ФЗ от 14 июля 2022 года, оператор обязан уведомить Роскомнадзор (Федеральную службу по надзору в сфере связи, информационных технологий и массовых коммуникаций) до начала передачи персональных данных за рубеж. Подача уведомления об обработке данных согласно статье 22 является отдельной обязанностью и не связана с тем, где физически находится диск.

На практике разделение выглядит четко. Хранение собственных архивов на VPS во Франкфурте — это личные нужды, и 152-ФЗ на это не распространяется. Запуск сервиса, который регистрирует пользователей и хранит их имена, номера телефонов и историю заказов исключительно на зарубежном диске, делает вас оператором, и в этом случае статья 18 часть 5 становится первым требованием, которое необходимо выполнить.

Промежуточный случай — резервное копирование, именно здесь чаще всего возникают сложности. Дамп базы данных ваших клиентов по-прежнему содержит их персональные данные, поэтому исключение для личных нужд на него не распространяется. Является ли зашифрованная вторичная копия за рубежом при условии, что основная база данных находится в России, соблюдением статьи 18 части 5 — это вопрос для юриста, работающего с актуальным текстом закона. Не решайте этот вопрос на основе статьи в интернете, включая эту. Указанные выше номера законов — это то, что нужно искать на официальном портале правовой информации, где публикуется консолидированный текст со всеми внесенными изменениями.

Шифрование перед загрузкой: на хосте хранятся только зашифрованные данные

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

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

sudo apt install -y restic
restic init --repo sftp:backup@198.51.100.10:/srv/restic
restic --repo sftp:backup@198.51.100.10:/srv/restic backup ~/documents ~/photos

Для зеркала, которое остается доступным для просмотра, в rclone предусмотрен удаленный тип crypt, который является оберткой для другого удаленного хранилища. Запустите rclone config, сначала создайте обычное удаленное хранилище для VPS, затем создайте второе хранилище типа crypt, параметр remote которого указывает на путь в первом хранилище, выберите standard для шифрования имен файлов и установите пароль и соль.

sudo apt install -y rclone
rclone config
rclone sync ~/photos secret:photos --transfers=8 --progress
rclone cryptcheck ~/photos secret:photos

Используйте rclone cryptcheck, а не обычный rclone check для удаленного хранилища типа crypt, так как check не может сравнивать контрольные суммы через слой шифрования. Установка шифрования имен файлов в значение off лишь добавляет расширение .bin и оставляет все имена читаемыми на сервере, поэтому оставьте значение standard, если только другие инструменты не должны читать эти имена.

Для одиночного архива достаточно утилиты age. Замените получателя ниже на открытый ключ, который age-keygen вывел для вас:

sudo apt install -y age
age-keygen -o ~/.age-key.txt
grep -i 'public key' ~/.age-key.txt
age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p -o photos.tar.zst.age photos.tar.zst

Шифрование скрывает не всё. Сервер по-прежнему видит размеры файлов, количество хранимых объектов, время ваших подключений и объем передаваемых данных при каждом сеансе. Это также не меняет юридическую оценку, поскольку персональные данные, ключ от которых находится у вас, остаются персональными данными: статья 18 часть 5 применяется в зависимости от того, где физически находится база данных, а не от того, может ли хост прочитать её содержимое.

Важное предупреждение. Пароль — это и есть данные. Если вы его потеряете, зашифрованный текст превратится в беспорядочный набор байтов без возможности восстановления и без службы поддержки, способной помочь. Запишите его там, где он сохранится даже в случае утраты компьютера, на котором создавалась резервная копия. Шифрование данных на VPS для хранения подробно рассматривает вопросы управления ключами.

Оплата услуг зарубежного хостинг-провайдера из России

Карты, выпущенные российскими банками, перестали работать за пределами России в марте 2022 года, когда Visa и Mastercard приостановили свою деятельность в стране, а национальная система «Мир» не принимается платежными шлюзами, которые использует большинство хостеров. Многие провайдеры также проводят проверку на соответствие санкционным спискам при регистрации, а некоторые повторяют её при каждом продлении услуг. По состоянию на сентябрь 2026 года ситуация у большинства европейских и североамериканских провайдеров остается прежней.

Последствия этого важнее, чем просто неудобства. VPS для хранения данных, который невозможно продлить, не является надежным хранилищем. Хостеры обычно приостанавливают работу неоплаченного сервера после короткого льготного периода, а затем удаляют диск; оба срока прописаны в условиях, которые вы принимаете при оформлении заказа. Прочитайте их перед тем, как загружать терабайты данных, и внесите дату продления в календарь с напоминанием, которое сработает заблаговременно.

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

Арифметика начальной загрузки: сколько времени занимает первая выгрузка

Первая выгрузка — самая ресурсоемкая. В дальнейшем вы передаете только измененные данные, что для фотографий и документов обычно составляет пренебрежимо малую величину. Расчет выполняется одной формулой: секунды равны байтам, умноженным на 8 и деленным на биты в секунду. Если считать гигабайт как 1 000 000 000 байт, то 500 ГБ — это 4 триллиона бит.

ChartTime to upload 500 GB at 80 percent of nominal uplink (computed, not measured)
The data behind this chart
[
  {
    "label": "10 Mbit/s uplink",
    "effective_mbit_s": 8,
    "hours_for_500_gb": 138.9
  },
  {
    "label": "40 Mbit/s uplink",
    "effective_mbit_s": 32,
    "hours_for_500_gb": 34.7
  },
  {
    "label": "100 Mbit/s uplink",
    "effective_mbit_s": 80,
    "hours_for_500_gb": 13.9
  },
  {
    "label": "500 Mbit/s uplink",
    "effective_mbit_s": 400,
    "hours_for_500_gb": 2.8
  },
  {
    "label": "1000 Mbit/s uplink",
    "effective_mbit_s": 800,
    "hours_for_500_gb": 1.4
  }
]

В строках таблицы предполагается, что вы получаете 80 процентов от номинальной скорости исходящего канала, что является справедливой поправкой на накладные расходы протоколов и использование сети другими устройствами в доме. Это расчетные показатели, а не результаты измерений реальной сети. Подставьте значение скорости, полученное через iperf3, в ту же формулу, и она останется верной.

При исходящем канале 10 Мбит/с выгрузка 500 ГБ занимает 138.9 часов непрерывной передачи, что составляет почти шесть суток. При эффективной скорости 80 Мбит/с это 13.9 часов — работа в течение ночи и части утра. На гигабитном канале это 1.4 часов. 5 строк охватывают диапазон, характерный для большинства домашних и офисных подключений, и закономерность очевидна: время начальной загрузки определяется скоростью вашего исходящего канала, поэтому сервер, расположенный на две тысячи километров дальше, практически не влияет на результат.

Два практических замечания. Запускайте первую выгрузку внутри tmux или как systemd service, чтобы закрытие крышки ноутбука не прервало процесс, так как и restic, и rclone умеют возобновлять работу с места остановки. Предварительно ознакомьтесь с политикой добросовестного использования (fair use policy) вашего провайдера, так как выгрузка половины терабайта за неделю — это объем трафика, который может привести к ограничению скорости по домашнему тарифу. Если вы еще не определились с объемом, расчет необходимого дискового пространства выполняется до этих вычислений, а сравнение стоимости терабайта на VPS и в объектном хранилище поможет понять, во сколько вам будет обходиться каждый выгруженный терабайт ежемесячно.

Проверка восстановления перед тем, как доверять копии

Копия, которую вы ни разу не восстанавливали, — это лишь предположение. Три команды превращают её в подтверждённый факт.

restic --repo sftp:backup@198.51.100.10:/srv/restic snapshots
restic --repo sftp:backup@198.51.100.10:/srv/restic check --read-data-subset=5%
restic --repo sftp:backup@198.51.100.10:/srv/restic restore latest --target /tmp/restore-test --include /home/me/documents

check сама по себе проверяет структуру репозитория и метаданные, не загружая данные файлов, поэтому она не может обнаружить обрезанный или повреждённый pack-файл. --read-data-subset=5% загружает и проверяет случайные 5 процентов pack-файлов, что позволяет выявить подобные повреждения. Расход трафика пропорционален запрошенному объёму: для репозитория размером 500 GB проверка 5 процентов потребует загрузки 25 GB. Этот же флаг принимает дробные значения, например 1/5, или размер, например 10G.

Затем сравните реальный файл побайтово:

sha256sum ~/documents/report.pdf /tmp/restore-test/home/me/documents/report.pdf

Два идентичных хеша означают, что весь цикл прошёл успешно, включая шифрование.

Выполните это один раз с машины, которая не является источником резервной копии, используя только записанный вами пароль. Это тест, который выявляет реальную проблему: пароль от репозитория существовал только в истории командной оболочки ноутбука, который вышел из строя. Удалённый диск, который никогда не проходил этот тест, является просто копией, а не резервной копией, и стоит прочитать статью считается ли storage VPS полноценной резервной копией, прежде чем полагаться на него. Та же осторожность применима к снимкам (snapshots) на стороне провайдера, которые хранятся на той же инфраструктуре, что и защищаемый ими сервер, поэтому снимки и резервные копии решают разные задачи.

Как только схема заработает для одного сервера, остаётся вопрос о том, как ваши машины взаимодействуют друг с другом, и объединение двух VPS разных провайдеров через приватный туннель позволит исключить этот трафик из публичного интернета. Если вы всё ещё решаете, какой именно сервер вам нужен, начните с изучения того, чем storage VPS отличается от обычного VPS.

FAQ

Законно ли хранить собственные резервные копии на VPS за пределами России?

Федеральный закон № 152-ФЗ не распространяется на обработку персональных данных физическим лицом исключительно для личных и семейных нужд согласно статье 1 части 2, если такая обработка не нарушает права других лиц. Ваши личные фотографии и резервная копия сервера, который вы используете для себя, подпадают под это исключение. Ситуация меняется, если данные принадлежат другим людям: в этом случае вы становитесь оператором, и к вам применяется требование о локализации из статьи 18 части 5 в редакции, введенной Федеральным законом № 23-ФЗ от 28 февраля 2025 года и действующей с 1 июля 2025 года. Это описание положений закона. Данная информация не является юридической консультацией, поэтому перед созданием сервиса изучите актуальный текст закона и обратитесь за профессиональной консультацией.

Достаточно ли шифрования на стороне клиента для выполнения требований 152-ФЗ о локализации?

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

Почему передача данных идет медленно, если пинг до VPS в норме?

Время прохождения сигнала (RTT) не равно пропускной способности. Две типичные причины — потеря пакетов и задержки при передаче множества мелких файлов. Потери заставляют алгоритм управления перегрузками CUBIC уменьшать окно отправки, а на длинном маршруте его восстановление требует множества медленных циклов RTT, поэтому даже доли процента потерь значительно снижают эффективную скорость. Копирование множества мелких файлов через смонтированную удаленную файловую систему требует как минимум одного RTT на каждый файл, независимо от пропускной способности канала. Запустите iperf3 -c 198.51.100.10 -t 30 -P 1, а затем ту же команду с флагом -P 4: если четыре потока работают значительно быстрее одного, значит, ограничение наложено на соединение, а не на сам канал.

Какой регион выбрать для работы из России: Франкфурт, Амстердам, Варшаву или Хельсинки?

Измеряйте, а не гадайте. Все четыре региона имеют провайдеров с емкостью каналов в сторону российских сетей, но маршрут вашего провайдера важнее расстояния на карте, и показатели двух провайдеров в одном городе могут различаться. Запросите у каждого тестовый IP-адрес, запустите sudo mtr -rwzbc 200 <ip> и тест iperf3 для каждого кандидата с того соединения, через которое будете загружать данные, и выбирайте локацию с наименьшими потерями на последнем узле, а не с минимальным пингом.

Сколько времени займет первая загрузка 500 GB?

Разделите объем данных на вашу эффективную скорость отдачи. 500 GB — это 4 триллиона бит, поэтому при эффективной скорости 80 Mbit/s это займет около 13.9 часов, а при эффективной скорости 8 Mbit/s — около 138.9 часов. Это расчетные показатели, поэтому подставьте значение скорости, измеренное с помощью iperf3 на вашем канале. Запускайте загрузку внутри tmux или как systemd-сервис, чтобы разрыв соединения не заставил вас начинать процесс сначала, и перед началом проверьте политику честного использования (fair use policy) вашего провайдера.