VPN 経由のクラウドバックアップが遅い：本当のフェーズを見極める
遅いバックアップは転送ではなくスキャン、ハッシュ計算、再試行かもしれません。ルートを変える前にフェーズ、保存先の種類、復元を比較しましょう。
VPN 越しに這うようなバックアップは、トンネルを切って測り直すという分かりやすい実験を誘います。しかしその実験は別の問いに答えることが多く、ジョブはバイトを動かすのではなくファイルのハッシュを計算していたり、再試行を待っていたりするかもしれません。まずフェーズを分ければ、不満は具体的な期待結果を持つ具体的なテストに変わります。ルートが候補になるのは、転送フェーズこそが実際に遅い場合だけです。
遅いと感じるとき、ジョブはどのフェーズにいるのか
バックアップツールはフェーズを順に進みます。ファイルの検出、読み取りとハッシュ計算、圧縮、暗号化、アップロード、そして検証です。各フェーズには固有のボトルネックがあり、ネットワークに触れるのはその一部だけです。まだフェーズを報告しないツールは、スキャンが終わっていないことを伝えています。
百万個の小さなファイルの準備に二十分かかるジョブは、トンネルが速くなっても速くなりません。上り回線を飽和させているジョブは容量の問題で、対処法が異なります。遅延が起きている間に進捗出力を読み、フェーズを記録し、時刻を書き留めてください。不満の時点のフェーズだけが意味を持ちます。小さなファイルは大きなオブジェクトとは挙動が異なり、ファイルごとの往復が支配的になって転送は安定した速度に達しません。トンネルについて結論を出す前に、同種のもの同士を比較してください。
公開エンドポイントとプライベート NAS では失敗の仕方が違う
公開バックアップサービスは独自の認証済みアプリケーション接続を持ち、トンネルはより長い経路の一区間にすぎません。プライベート NAS は通常、自分のネットワークへの基本的な到達性をそのトンネルに依存しています。この違いが、切断が有効な基準になるのか、何も測っていないことになるのかを決めます。
公開の場合、ポリシーが許せば別ルートでの同じジョブは公平な比較になります。プライベートの場合、トンネルを外すとサーバーへの経路がまったく残らないため、結果が示すのは削除した経路であり、使っている経路ではありません。
| Destination | What the tunnel provides | Valid baseline |
|---|---|---|
| Public backup service | One hop among several | The same job over another route |
| Private NAS | The only path to the server | None that removes the tunnel |
| Self-hosted gateway | Path plus split-DNS policy | Only if the policy is unchanged |
停止は遅い転送とは別の障害である
この表の三列目が、安定性テストをそもそも実施できるかを決めます。トンネルを外す基準は、別の経路が存在する場所でしか意味を持たないからです。使える基準があるなら、平均速度ではなく障害の形を見てください。低いが安定したアップロードは容量を示し、止まって再開するジョブは中断、認証、または一つの厄介なファイルを示します。この二つはほぼ同じ不満を生みながら、まったく違う修理を必要とします。
再試行はあらゆる測定を歪めます。回線上のバイト数は実際に変化した量より多いことがあるからです。ジョブを再び中断して何が起きるかを見る前に、再開の挙動を読んでください。分割して再開できるアップロードは安く復旧しますが、ファイル全体のやり直しはそうではありません。数分ごとに再接続するトンネルも、実際には安定性の問題なのに帯域の問題に見えます。経路 MTU がこれを悪化させ、利用可能なペイロードを減らすトンネルは大きなセグメントを止め、小さなものだけが通ります。
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com一つのアップロードが他のすべてのフローを飢えさせる
上り回線を埋めるアップロードは通話とブラウジングを応答不能にし、バックアップがその回線を争う唯一のものになることはほとんどありません。二つ目の同期クライアントだけで同じ症状が出ます。トンネルを責める前に、ほかに何がアップロードしているかを見てください。
最高スループットを争うのではなく、ツールが文書化しているスケジュールや帯域制限を使ってください。対話的な作業のために余裕を残すほうが、最後の数パーセントより通常は価値があります。そのうえで制限が実際に何に適用されるかを確認してください。ファイル単位で制限するツールもあれば、実行全体を制限するものもあり、小さなファイルのオーバーヘッドを完全に無視するものもあります。作業負荷に合わない制限は何も変えません。分割トンネリングもここでは疑わしいところで、ランチャーをトンネルから外しても、アップロードを行うヘルパーサービスは外れません。たとえば Rclone は転送制限と再試行の挙動の両方をドキュメントで公開しており、制限が何を制御すべきかを考えるうえで有用な参照になります。
速度テストではなく復元で締めくくる
完了したアップロードは、そこから何かが復元されるまでバックアップではありません。期待するバージョンが存在することを確認し、ツールが文書化している手順で代表的なファイルを復元してください。復元に必要な情報は、失う可能性のあるマシンやプロファイルとは別の場所に置き、実験を整頓するためだけに動作するバックアップを捨てないでください。
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hostsネットワーク変更の後に転送と復元の両方を繰り返し、改善がデータを速く動かすだけでなくバックアップに資することを示してください。その二回目の実行がチケットを閉じます。復元を試さないまま速くなった転送は、無防備のままいるためのより遅い方法です。