VPN経由のrsync:壊れた転送を再利用する再試行
切れたトンネルが終わらせるのは接続であってデータではない。--partial-dir で断片を残し、同じコピーを再実行し、公開前にファイルを検証する。
アップロードが十二ギガバイトのアーカイブの四ギガバイト地点で止まり、ダウンロード管理ソフトで身についた習慣が再開を押せと言う。rsyncはTCPストリームを再開しない。そのストリームはトンネルの最後の再送とともに消えているからだ。できるのは、すでに受け取ったバイトを保持し、次の試行の土台として使うことで、これは別のルールを持つ別の仕組みである。どのフラグを選ぶかで、その再利用がそもそも起こるかどうかが決まる。
再試行は状態を作り直すのであって、ストリームを再開するのではない
SSHセッションが切れると、遠端にはディスクに書き出せたものだけが残り、それ以外は何も残らない。再接続するセッショントークンも、再生するシーケンス番号もない。次の実行は新しい接続を開き、ソースをもう一度読み、受信側にすでに何を持っているかを尋ねる。
その最後の問いが、部分ファイルを残す価値の理由である。受信側のコピーはrsyncに比較する材料を与え、アルゴリズムは識別できた差分だけを送る。それでもメタデータの新しい転送とソースの新しい走査は必要なので、節約できる時間はファイルのどれだけが一致するかに比例し、前の接続がどこまで進んだかには比例しない。受信側が何も残していなければ、最初が何ギガバイト進んでいても、次の試行は完全なコピーになる。
再利用できる断片をどこに置くかを決める
既定の動作は部分ファイルを宛先パスに書き出すため、書きかけのアーカイブが最終的な名前で見えてしまう。--partial-dir はそれを任意のディレクトリへ移し、マニュアルはそのディレクトリを後続の転送がデータとして使うために保持されるものと説明している。相対名は宛先ディレクトリの下で解決され、両端の構成が異なる可能性があるときに望ましいのはまさにこれである。
rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
large-archive.bin [email protected]:/srv/incoming/
宛先でも順序が重要だ。部分ディレクトリには断片のための十分な空きが要り、ボリュームには完成ファイルのための空きも要る。転送の途中で宛先ボリュームを満杯にすると、ネットワーク問題に見えるがそうではない失敗が起き、保持した断片が切り詰められたまま残ることがある。実行を始める前に受信ホストの空き容量を確認し、失敗した後に確認しないこと。同じSSH経路で df -h を数秒走らせるのが、計画の最も安価な検証である。
権限はより小さな、しかし実際の懸念である。無関係なアカウントが書き込める部分ディレクトリでは、次の実行が受信済みとして扱う内容を他人が差し替えられてしまう。転送アカウントの所有に保ち、他のサービスが公開している場所に置かないこと。
同じコピーを実行する。賢いコピーではなく
再利用は、ソースと宛先が依然として同じ対象を指している場合にのみ成り立つ。同じパス、同じ名前、同じファイルである。ソースの名前を変えたり別の宛先ディレクトリを指したりすると、役に立たないものとの新しい比較が始まる。
差分動作を期待して --whole-file を加えてはいけない。このオプションはローリングチェックサムの比較なしにファイル全体をコピーするようrsyncに指示するもので、高速なローカルリンクでは妥当だが、失敗した長距離アップロードの後ではまったく逆である。--inplace も話を変える。宛先ファイルへ直接書き込むため、中断すると古い内容と新しい内容が混ざったファイルが残り、退避できる別の断片がない。
進捗行は転送の集計進捗を報告する。完了の合図ではない。接続がまだ開いているうちに数字が百パーセントに達したのは、データが押し出されたという意味であり、受信側が名前を変えた、同期した、受け入れたという意味ではない。
一致してからはじめて受け入れる
まず終了ステータスを確認し、エラーがないことに頼るのではなく結果を比較する。サイズの確認は切り詰められた転送のほとんどを捕まえ、チェックサムの比較は残りを捕まえる。どちらもアップロードをやり直すより安い。
アーカイブを下流の処理が公開するなら、その処理に受け入れ済みファイルを待たせる。最終的な名前で監視対象ディレクトリに落ちた保持断片は次のスキャンに拾われ、利用者のエラーは決して終わらなかった転送ではなく、壊れた入力についてのものになる。
受信側が確認するまでソースに触れない。試行の間にアーカイブを作り直すと比較の基準が変わり、次の実行はほぼすべてを転送するか、古いソースにも新しいソースにも一致しないファイルを作る。
制限がフラグではなく回線であるとき
ヘッダーとプロトコルのオーバーヘッドは転送の一つのコストであり、大きなファイルにどれだけ時間がかかるかを決めるのはめったにこれではない。再開の挙動のほうが重要だ。手作業なしで切断を生き延びる方法は、やり直しが必要な速い方法より早く使えるファイルを届ける。両端のストレージと認証経路も同じ比較に入る。
許可された代替経路を同じファイルと同じ宛先で比較し、中断後にそれぞれがどこから再開するかを記しておく。その一列は、短いテストで測ったどの最高速度よりも、VPN経由の十二ギガバイトのアップロードについて多くを語る。