著者 ロシアのストレージ VPSは遅延と法律で選ぶ
ロシアからストレージ VPS を使うなら、RTT よりスループットとパケット損失を確認します。連邦法 No. 152-FZ が個人データに求める扱いも解説します。
ロシア国内でストレージ VPS を配置する場所
ロシアからストレージ VPS を購入する場合、判断は 2 つあります。そのうち技術的な判断は 1 つだけです。技術面ではディスクをどこに置くかを決めます。大容量ストレージでは、ラウンドトリップ時間よりもスループットとパケット損失が重要です。法的な判断では、何を保存するかを決めます。連邦法 No. 152-FZ では、自分のアーカイブと他人の個人データは異なる扱いになります。
このガイドでは、遅延の数値を引用しません。重要なのは、利用している接続と検討中のサーバーの間の経路だけです。そのため、以下の測定はすべて、自分で実行するコマンドを使います。
バルクストレージではラウンドトリップ時間がほとんど問題にならない理由
ラウンドトリップ時間（RTT）は、1 つのパケットがサーバーに到達して戻ってくるまでの時間です。測定が最も簡単な値なので、これを基準にリージョンを選ぶ人がいます。ただし、写真のディレクトリや夜間バックアップを転送する場合、RTT だけで決まることはほとんどありません。
TCP（transmission control protocol）は、1 つのパケットを送信して待つ動作をしません。未確認応答のデータをウィンドウ内に保持して送信し続けます。Linux はこのウィンドウを自動的に数 MB まで拡大します。RTT が 50 ms の経路でも、ウィンドウが拡大すれば、1 本のストリームで数百 Mbps を転送できます。RTT が決めるのは、接続が速度に到達するまでの時間です。最終的に落ち着く転送速度を決めるものではありません。
RTT が影響するのは、特定のパターンです。1 回の操作ごとに 1 回のラウンドトリップが必要になる場合です。リモートディスクをファイルシステムとしてマウントし、40,000 個の小さなファイルをコピーすると、各ファイルで少なくとも 1 回、多くの場合は open、write、close によって複数回のラウンドトリップが発生します。この場合、どれだけ帯域幅を契約しても、転送速度はおおむね RTT 1 回につき 1 ファイルになります。そのため、データを大きなオブジェクトにまとめて、restic や並列転送を使用する rclone のように複数を同時に送信するツールは、同じリンク上でも、マウントしたリモートファイルシステムを大きく上回ります。
長い経路で実際に転送を壊すのはパケットロスです
距離があると、わずかな損失率でも大幅な速度低下につながります。これが「ping は正常に見えるのに転送が進まない」原因です。Ubuntu のデフォルトの輻輳制御は CUBIC です。CUBIC はパケットロスを輻輳として扱い、送信ウィンドウを縮小します。そのウィンドウを再拡大するには多数のラウンドトリップが必要です。長い経路では、各ラウンドトリップに時間がかかります。そのため、50 ms の経路における 0.5 パーセントの損失は、5 ms の経路における同じ 0.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 で変更前後を測定してください。パケットロスのないクリーンな経路では、通常はまったく変化しません。
実際に近い地域はどこか
Frankfurt、Amsterdam、Warsaw、Helsinki は、ホスティングプロバイダーがロシアのネットワーク向けに設備容量を集約しているヨーロッパの拠点です。推奨されるのも主にこれらの地域です。地図上の距離は、実際の通信品質を判断する材料としては不十分です。ロシアの ISP から Helsinki のデータセンターへ向かう通信でも、Frankfurt や Stockholm を経由することがあります。同じ都市にあるプロバイダーでも、利用するトランジットの構成は大きく異なる場合があります。Ural 山脈より東にいる場合、西ヨーロッパはあらゆる意味で遠く、Almaty や Yerevan のような拠点のほうが適切な経路になることもあります。
そのため、地図だけで選ばないでください。ほとんどのホストは、拠点ごとにテスト用 IP アドレスとテストファイルを公開しています。料金を支払う前に、それらを使って確認してください。確認には、実際にアップロードで使用する接続を使います。別のネットワークに接続した phone から試してはいけません。料金と管轄を比較して検討する場合は、EU のストレージ 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 回のサイクルを実行します。これにより、パケット損失率を意味のある値として確認できます。
最初に最後の行を確認します。途中のホップで発生した損失が、その後のホップでは発生していない場合、それは実際の経路上の損失ではありません。ルーターは、mtr が必要とする ICMP 応答の生成を低い優先度で処理するため、高負荷のコアルーターが、トラフィックを正常に転送しながら損失を報告することがあります。最終ホップまで継続する損失だけが実際の損失です。最終ホップでおおむね 1 パーセントを超える損失があると、大容量のアップロードに大きな影響が出ます。転送ツールを変更しても、この問題は解決しません。
ネットワークで ICMP がフィルタリングされ、トレースが早い段階で終了する場合は、実際に使用するポートへの TCP でトレースします。
sudo mtr -rwc 100 -T -P 443 198.51.100.10ルーティングは非対称になることが多いため、VPS から自分のアドレスに向けても mtr を実行します。自宅の接続が CGNAT (carrier grade network address translation) の背後にある場合、外部からそのアドレスには到達できず、逆方向のトレースは ISP 内部で停止します。これは想定される動作であり、障害ではありません。
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 -R1 回目は単一のアップロードストリームです。2 回目は 4 本のストリームを並列で使用します。-R は方向を反転し、VPS から自分のマシンへ送信します。最初の 2 つの結果を慎重に比較してください。4 本のストリームが 1 本より大幅に高速なら、制限は接続単位にあります。原因はウィンドウサイズまたは損失回復処理です。この場合、並列接続に対応した転送ツールを使うと最大速度に達します。両方の結果が同じなら、実際の上限に達しています。一般的な家庭回線や小規模オフィス回線では、この上限はサーバーの所在地ではなく、自分の上り回線によるものです。
テストが終わったら Ctrl+C でサーバーを停止し、ポートを閉じます。iperf3 -s が待ち受けたままだと、インターネット上の誰でも帯域幅の使用量を増やせます。
sudo ufw delete allow 5201/tcpNo. 152-FZ がロシア国外のストレージ VPS について定める内容
2006 年 7 月 27 日付の連邦法 No. 152-FZ「個人データについて」は、「データローカライゼーション」と呼ばれる要件の根拠となる法律です。外国にあるストレージ VPS が問題になるかどうかは、この法律の 3 つの条文で決まります。以下では、法律の条文の内容を説明します。法的助言ではありません。
第 1 条第 2 項が適用範囲を定めます。 この法律は、個人が専ら個人的および家族的な目的で個人データを処理する場合には適用されません。ただし、その処理によって、データの対象者の権利が侵害されないことが条件です。家族写真や、自分で運用するサーバーのバックアップは、この範囲に含まれます。
第 18 条第 5 項がローカライゼーション要件を定めます。 この要件は、処理の目的を決定する者、つまりオペレーターに適用されます。2025 年 7 月 1 日以降、この規定は指示ではなく禁止事項として定められています。2025 年 2 月 28 日付の連邦法 No. 23-FZ によって導入された文言では、インターネット経由の場合を含め、個人データを収集する際に、ロシア連邦の市民の個人データを、ロシア連邦の領域外にあるデータベースを使用して記録、体系化、蓄積、保存、更新または検索することは認められません。ただし、第 6 条第 1 項の第 2 号、第 3 号、第 4 号および第 8 号に定める場合を除きます。同じ要件の旧版は、2014 年 7 月 21 日付の連邦法 No. 242-FZ によって導入され、2015 年 9 月 1 日に施行されました。
第 12 条が越境移転を定めます。 2022 年 7 月 14 日付の連邦法 No. 266-FZ によって導入され、2023 年 3 月 1 日から施行されている現行版では、オペレーターは、個人データを国外へ移転する前に、通信・情報技術・マスメディア監督連邦サービスである Roskomnadzor に通知しなければなりません。第 22 条に基づく処理の通知は別の義務であり、ディスクの所在地とは関係ありません。
実務上の区別は明確です。自分のアーカイブを Frankfurt のストレージ VPS に保存する場合は個人的な利用であり、152-FZ は適用されません。一方、ユーザーが登録するサービスを運用し、そのユーザーの氏名、電話番号、注文履歴を同じ外国のディスクだけに保存する場合、あなたはオペレーターに該当します。その場合、まず第 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 の2つ目のリモートを作成し、remote 設定で最初のリモート上のパスを指定します。ファイル名の暗号化には standard を選び、パスワードと salt を設定します。
sudo apt install -y rclone
rclone config
rclone sync ~/photos secret:photos --transfers=8 --progress
rclone cryptcheck ~/photos secret:photos暗号化リモートでは、単純な rclone check ではなく rclone cryptcheck を使用します。check では、暗号化層を通過するチェックサムを比較できないためです。ファイル名の暗号化を off にすると、.bin 拡張子が追加されるだけで、サーバー上ではすべての名前が読めるままです。そのため、別の処理で名前を読み取る必要がない限り、standard のままにします。
単一のアーカイブであれば、age で十分です。以下の recipient を、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暗号化しても、すべての情報が隠れるわけではありません。サーバーには、ファイルサイズ、保持しているオブジェクト数、接続時刻、接続のたびに転送するデータ量が引き続き分かります。また、法的な扱いも変わりません。自分が鍵を保持する個人データは、引き続き個人データだからです。article 18 part 5 で問題になるのはデータベースの所在であり、ホストがその内容を読めるかどうかではありません。
率直な注意点を1つ挙げます。パスワードがデータそのものです。パスワードを失うと、暗号文は意味のないデータになり、復旧手段も、役に立つサポートチケットもありません。バックアップを作成したマシンを失っても残る場所に、パスワードを書き留めてください。ストレージ VPS 上のデータを暗号化するでは、鍵の管理についてさらに詳しく説明しています。
ロシアから海外のホスティングプロバイダーへ支払う
ロシアの銀行が発行したカードは、Visa と Mastercard がロシアでの業務を停止した2022年3月以降、ロシア国外では利用できなくなりました。また、ロシア国内の Mir システムは、多くのホスティングプロバイダーが利用する決済処理業者では受け付けられていません。多くのホスティングプロバイダーは申込時に制裁対象のスクリーニングも実施し、更新のたびに再実施する場合もあります。2026年9月時点でも、ほとんどの欧州および北米のプロバイダーではこの状況が続いています。
不便さよりも、その結果のほうが重要です。更新できないストレージ VPS は、ストレージとして機能しません。通常、ホスティングプロバイダーは短い猶予期間の後に未払いのサーバーを停止し、さらに長い期間が経過するとディスクを削除します。これらの期間は、チェックアウト時に同意する利用規約に記載されています。1 TB のデータをアップロードする前に規約を確認し、更新日をカレンダーに登録してください。更新日より十分前に通知されるリマインダーも設定します。
データを預ける前に、2点を確認してください。1点目は、自国向けのプロバイダーのチェックアウトページに実際に表示される支払い方法です。2点目は、料金がユーロ建てかドル建てかです。外貨建ての固定月額料金は、ルーブル建ての月額費用が固定されることを意味しません。このガイドでは、プロバイダーの支払いルールや制裁ルールを回避する方法は扱いません。ホスティングプロバイダーが支払いを受け付けない場合は、受け付けるプロバイダーを選んでください。
シードに必要な計算: 初回アップロードにかかる時間
初回のアップロードには時間がかかります。その後は変更分だけを送信するため、写真やドキュメントでは通常、誤差といえる程度の量になります。計算は 1 行で済みます。秒数は、バイト数に 8 を掛けて、ビット毎秒で割ります。1 GB を 1,000,000,000 バイトとして数えると、500 GB は 4 兆ビットです。
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 Mbit/s のアップロード回線では、500 GB の連続アップロードに 138.9 時間かかります。これは 6 日近くに相当します。実効速度が 80 Mbit/s の場合は 13.9 時間で、夜間に実行して翌朝の一部までかかる計算です。ギガビット回線では 1.4 時間です。5 行で、家庭や小規模オフィスの接続の大半をカバーしています。傾向は明確です。シードにかかる時間を決めるのは自分のアップロード回線であり、サーバーが 2,000 km 遠くにあっても、この点での影響はほとんどありません。
実用上の注意点が 2 つあります。まず、初回のアップロードは tmux 内で実行するか、systemd サービスとして実行してください。ノート PC を閉じても処理が終了しません。restic と rclone はどちらも停止した位置から再開できます。次に、ISP の公正利用ポリシーを先に確認してください。1 週間に 500 GB のアップロードは、住宅向け契約で速度制限の対象になる可能性がある通信量です。必要な容量がまだ決まっていない場合は、必要なストレージ容量の算出を先に行います。そのうえで、ストレージ VPS とオブジェクトストレージで 1 TB の料金を比較すると、シードした 1 TB ごとの月額コストが決まります。
信頼する前に復元してコピーを検証する
一度も復元したことがないコピーは、推測にすぎません。3 つのコマンドで事実として確認できます。
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/documentscheck はファイルデータをダウンロードせずに、リポジトリの構造とメタデータだけを検証します。そのため、途中で切り詰められた pack ファイルや破損した pack ファイルは検出できません。--read-data-subset=5% は pack ファイルの 5 percent をランダムにダウンロードして検証します。これにより、そのような破損を検出できます。使用する帯域幅は指定した割合に比例します。たとえば、500 GB のリポジトリの 5 percent では 25 GB をダウンロードします。同じフラグには、1/5 のような割合や、10G のようなサイズも指定できます。
次に、実際のファイルをバイト単位で比較します。
sha256sum ~/documents/report.pdf /tmp/restore-test/home/me/documents/report.pdfハッシュが完全に一致すれば、暗号化を含む一連の処理全体が正常に完了したことになります。
この確認は、バックアップを作成したマシンとは別のマシンから、書き留めておいたパスワードだけを使って 1 回実施してください。これが、実際の障害を検出するテストです。リポジトリのパスワードが、故障した laptop の shell history にしか存在しないという障害です。そのテストに一度も合格していない remote disk は、backup ではなくコピーです。1 台だけで storage VPS を backup として扱えるかどうかについては、storage VPS だけで backup とみなせるかを、依存する前に確認してください。同じ注意は provider 側の snapshot にも当てはまります。snapshot は、保護対象の server と同じ infrastructure 上に保存されるためです。そのため、snapshot と backup は異なる問題を解決することも確認してください。
1 台の server でこの構成が機能したら、次に確認するのは各 machine がどのように相互接続するかです。private tunnel で provider 間の 2 台の VPS を接続すると、その traffic を public internet に流さずに済みます。そもそもどの種類の server が必要かまだ決めていない場合は、storage VPS と通常の VPS の違いから確認してください。
FAQ
自分のバックアップをロシア国外のストレージ VPS に保存することは合法ですか？
連邦法 No. 152-FZ は、第 1 条第 2 項により、他者の権利を侵害しない限り、個人が自分自身または家族のためだけに個人データを処理する場合には適用されません。自分の写真や、自分のために運用しているサーバーのバックアップは、この範囲に該当します。データが他者のものである場合は扱いが変わります。この場合、あなたは事業者となり、第 18 条第 5 項のローカライゼーション要件が適用されます。この規定の文言は、2025 年 2 月 28 日付の連邦法 No. 23-FZ により導入され、2025 年 7 月 1 日から施行されています。ここで説明しているのは法律の内容です。法的助言ではないため、この内容を基にサービスを構築する前に、現行の条文を確認し、専門家に相談してください。
クライアント側の暗号化で 152-FZ のローカライゼーション要件を満たせますか？
いいえ。暗号化によって、ホスティング事業者が読み取れる内容は変わります。第 18 条第 5 項が定めているのはデータベースの所在地であり、自分が鍵を保持する個人データも個人データであることに変わりはありません。それでも暗号化は行ってください。機密性については、ホストとその管轄区域を脅威モデルから外せるためです。ただし、ローカライゼーションの要否は別の問題として、個別に判断してください。
VPS への ping は正常なのに、転送が遅いのはなぜですか？
ラウンドトリップ時間はスループットではありません。主な原因は、パケット損失とファイルごとのラウンドトリップです。パケット損失が発生すると、CUBIC 輻輳制御によって送信ウィンドウが縮小されます。経路が長い場合、ウィンドウの回復には遅いラウンドトリップが多数必要になるため、1% 未満の損失でも帯域幅の大部分が失われます。マウントしたリモートファイルシステムで多数の小さなファイルをコピーすると、リンクの帯域に余裕があっても、ファイルごとに少なくとも 1 回のラウンドトリップが発生します。iperf3 -c 198.51.100.10 -t 30 -P 1 を実行し、続けて -P 4 を付けた同じコマンドを実行してください。4 ストリームの方が 1 ストリームより大幅に速い場合、制限はリンク自体ではなく、接続単位にあります。
ロシアから利用する場合、Frankfurt、Amsterdam、Warsaw、Helsinki のどのリージョンを選ぶべきですか？
推測せずに測定してください。4 つの地域にはいずれも、ロシアのネットワーク向けの容量を持つプロバイダーがあります。ただし、地図上の距離よりも、自分の ISP が選択する経路の方が重要です。同じ都市でも、プロバイダーによって結果が異なる場合があります。各プロバイダーにテスト用 IP アドレスを問い合わせ、アップロードに使用する接続から各候補に対して sudo mtr -rwzbc 200 <ip> と iperf3 のテストを実行してください。ping が最も短い場所ではなく、最終ホップでのパケット損失が最も少ない場所を選びます。
最初の 500 GB のアップロードにはどのくらいかかりますか？
ビット数を実効アップロード速度で割ってください。500 GB は 4 trillion ビットなので、実効 80 Mbit/s では約 13.9 時間、実効 8 Mbit/s では約 138.9 時間かかります。これは計算値です。自分の回線で iperf3 が測定した速度に置き換えてください。接続が切れて最初からやり直すことにならないよう、アップロードは tmux 内または systemd サービスとして実行してください。開始前に ISP の公正利用ポリシーも確認してください。