二台のサーバー、一つの VPN、両方に存在しなければならない一つのディレクトリ、そして実行は簡単だが元に戻すのは難しいコマンド。入力する前に、どちらのコピーが権威なのかを決めてください、以降の rsync の問いはすべてその答えに依存するからです。一方向のレプリカ、共有の作業フォルダー、バージョン管理されたアーカイブでは、変更と削除に対するルールが異なります。トンネルは経路を提供するだけで、そのどれについても意見を持ちません。

コマンドを入力する前にどちらのコピーが勝つかを決める

方向を一文で書き留め、両側のホスト名とパスを含め、データの所有者に合意を得てください。この解説では、ソースは /srv/publish/、宛先は fileserver.example 上のアカウントで、/srv/mirror/ にだけ書き込めます。

コピーの前に、SSH のホスト鍵が検証済みであること、宛先アカウントがレプリカ領域にだけ書き込めること、両方のホストが互換性のある rsync バージョンを持っていることを確認します。これらの前提は、小さな計画ミスが権限インシデントになるのを防ぎます。何かがうまくいかないとき、宛先のログにどのアカウントが現れるかも教えてくれます。

コピーを事前確認し、詳細リストを読む

まずプレビューフラグでコピーを実行し、出力を保存します。詳細な変更は各パスに何が起きるかを示し、後から得る完了サマリーよりはるかに有用です。出力を変更記録に残せば、次の実行に比較対象ができます。

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

末尾のスラッシュは重要です。ソース側ではそのディレクトリの中身を意味し、省略するとソース名の付いたディレクトリ階層がもう一段加わります。rsync のマニュアルは両方の形式をメタデータ保持のフラグとともに記述しており、必要なオプション群は習慣ではなくデータによって決まります。

各行を、意図した宛先と照らして読んでください。プレビューフラグを外すとコピーが実行され、ファイルを上書きする可能性があり、削除オプションがなければ、宛先にすでにある余分なファイルはその場に残るだけです。これが安全な既定値になるのは、取り残された古いファイルを受け入れられると本当に決めた場合だけです。答えが否なら、このコマンドに余分なフラグを振りかけるのではなく、下の削除の判断を行うべきです。

次に削除を運ぶかどうかを決める

宛先をミラーにすることは二つ目の判断であり、一つ目の改善ではありません。削除フラグを加え、他は何も変えずに単独で事前確認し、リストの差分がその判断だけに属するようにします。

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

削除は同期対象の範囲内で受信側の余分なファイルを取り除くため、誤ったソースパス、マウントされていないディレクトリ、意図より多くを除外するフィルターが、破壊的な実行をきれいなミラーのように見せることがあります。事前確認のリストは、その差分が高くつく前に見える唯一の場所です。データが正当化する場所では独立した復旧コピーを保ち、ミラーは履歴を保つ代わりに偶発的な削除を忠実に再現することを忘れないでください。

事前確認は何もロックしません。人は試行と本番の間にファイルを編集し、ファイルシステムにも独自の事情があるため、承認した実行と実際に走る実行は、両方のツリーが静かでない限り同じ操作ではありません。

一方向のジョブ二つは双方向同期にならない

同じコマンドを両方向で走らせるのは、このシナリオでデータを失う最も一般的な方法です。各方向は相手側を宛先とみなし、新しい内容を喜んで上書きし、削除はスケジュールが発火する順に鏡映しされます。

利用者が両方のコピーを編集しなければならないなら、競合処理、削除の追跡、そのモデル向けに設計されたツールが必要であり、それは別の製品判断です。スケジュールの順序で近似するのは、共有フォルダーが誰も調停できない各文書の二つの版を持つに至る道です。cron の項目二つと願いに頼るのではなく、明示的に決めてください。

ポリシーを書いてから自動化する

スケジュールされたジョブは、方向、パス、メタデータのポリシー、承認済みの削除の判断を引き継ぐべきです。その五つの事実は、次の管理者が決して読まないかもしれない wiki ページではなく、ジョブファイル自体に置いてください。重複する実行を防いでください、同じツリーに同時に書き込む二つのコピーはどちらも意図しない状態を生むからです。

ソースが稼働中のデータベースや他の複数ファイルのデータセットである場合は、まずアプリケーション整合性のあるエクスポートか調整されたスナップショットを取ってください。再帰的なファイル走査はトランザクションではなく、変化するデータセットのコピーは一貫したものではありません。

完了と失敗を記録し、終了コードだけでなく宛先のデータセットを確認してください。障害後に VPN を復旧しても接続が戻るだけで、最後のコピーが完了したか、競合する編集が解決されたかは何も語りません。

関連記事