同じファイルリストを使用して複数の宛先にrsyncしますか?


22

rsyncが1つのディレクトリを複数のリモート宛先にすべて一度に、または並行してコピーすることが可能かどうか疑問に思っています。(必要ではありませんが、有用です。)

通常、次のようなものは問題なく機能します。

$ rsync -Pav /junk user@host1:/backup
$ rsync -Pav /junk user@host2:/backup
$ rsync -Pav /junk user@host3:/backup

そして、それが唯一のオプションである場合、それを使用します。ただし、/ junkは非常に多くのファイルがある低速ドライブにあり、毎回〜12,000個のファイルのファイルリストを再構築すると、実際の転送/更新に比べて非常に遅くなります(〜5分)。同じことを達成するために、このようなことをすることは可能ですか?

$ rsync -Pav /junk user@host1:/backup user@host2:/backup user@host3:/backup 

見てくれてありがとう!

回答:


12

バッチモードに関するrsyncのマニュアルページの情報を次に示します。

バッチモード

バッチモードを使用して、同じ更新セットを多くの同一システムに適用できます。多数のホストに複製されるツリーがあるとします。ここで、このソースツリーにいくつかの変更が加えられ、それらの変更を他のホストに伝達する必要があるとします。バッチモードを使用してこれを行うには、write-batchオプションを指定してrsyncを実行し、ソースツリーに加えられた変更をいずれかの宛先ツリーに適用します。write-batchオプションにより、rsyncクライアントは、他の同一の宛先ツリーに対してこの操作を繰り返すために必要なすべての情報を「バッチファイル」に保存します。

バッチファイルを1回生成すると、複数の宛先ツリーを更新するときに、ファイルステータス、チェックサム、およびデータブロック生成を複数回実行する必要がなくなります。すべてのホストに個別に同じデータを送信する代わりに、マルチキャスト転送プロトコルを使用して、バッチ更新ファイルを多数のホストに同時に並行して転送できます。

記録された変更を別の宛先ツリーに適用するには、同じバッチファイルの名前と宛先ツリーを指定して、read-batchオプションを指定してrsyncを実行します。Rsyncは、バッチファイルに保存されている情報を使用して宛先ツリーを更新します。

便宜上、スクリプトファイルはwrite-batchオプションが使用されるときにも作成されます。スクリプトファイルには、「。sh」が追加されたバッチファイルと同じ名前が付けられます。このスクリプトファイルには、関連するバッチファイルを使用して宛先ツリーを更新するのに適したコマンドラインが含まれています。Bourne(またはBourneのような)シェルを使用して実行できます。オプションで、代替の宛先ツリーパス名を渡して、元の宛先パスの代わりに使用できます。これは、現在のホストの宛先ツリーパスがバッチファイルの作成に使用されたパスと異なる場合に役立ちます。

   Examples:

          $ rsync --write-batch=foo -a host:/source/dir/ /adest/dir/
          $ scp foo* remote:
          $ ssh remote ./foo.sh /bdest/dir/

          $ rsync --write-batch=foo -a /source/dir/ /adest/dir/
          $ ssh remote rsync --read-batch=- -a /bdest/dir/ <foo

これらの例では、rsyncを使用して/ source / dir /から/ adest / dir /を更新し、この操作を繰り返すための情報は「foo」と「foo.sh」に保存されます。ホスト「リモート」は、ディレクトリ/ bdest / dirに入るバッチデータで更新されます。2つの例の違いから、バッチの処理方法に柔軟性があることがわかります。

  • 最初の例は、初期コピーがローカルである必要がないことを示しています-必要に応じて、リモートシェル構文またはrsyncデーモン構文のいずれかを使用して、リモートホストとの間でデータをプッシュまたはプルできます。

  • 最初の例では、リモートホストでread-batchコマンドを実行するときに、作成された「foo.sh」ファイルを使用して正しいrsyncオプションを取得します。

  • 2番目の例では、最初にバッチファイルをリモートマシンにコピーする必要がないように、標準入力を介してバッチデータを読み取ります。この例では、変更された--read-batchオプションを使用する必要があるため、foo.shスクリプトを使用しませんが、使用したい場合はスクリプトファイルを編集できます(他のオプションが標準を使用しようとしていないことを確認してください) 「--exclude-from =-」オプションなどの入力)。

    警告:

    read-batchオプションは、更新する宛先ツリーが、バッチ更新ファイルセットの作成に使用された宛先ツリーと同一であると想定しています。宛先ツリーの違いに遭遇した場合、更新が警告付きで破棄されるか(ファイルが既に最新のように見える場合)、またはファイルの更新が試行された後、ファイルが検証に失敗した場合、エラーで破棄された更新。これは、コマンドが中断された場合、読み取りバッチ操作を再実行しても安全であることを意味します。ファイルのサイズと日付に関係なく、バッチ更新を常に強制的に実行する場合は、-Iオプションを使用します(バッチの読み取り時)。エラーが発生した場合、宛先ツリーはおそらく部分的に更新された状態になります。その場合、

    すべての宛先で使用されるrsyncバージョンは、少なくともバッチファイルの生成に使用されるバージョンと同じである必要があります。バッチファイルのプロトコルバージョンがバッチ読み取りrsyncで処理するには新しすぎる場合、rsyncはエラーで終了します。古いrsyncが理解できるバッチファイルをrsyncの作成に生成させる方法については、--protocolオプションも参照してください。(バッチファイルはバージョン2.6.3で形式が変更されているため、それより古いバージョンと新しいバージョンを混在させることはできません。)

    バッチファイルを読み取るとき、rsyncは、バッチ書き込みコマンドと同じに設定していない場合、特定のオプションの値を強制的にバッチファイルのデータに一致させます。他のオプションは変更できます(変更する必要があります)。たとえば、-write-batchが--read-batchに変更され、-files-fromがドロップされ、-deleteオプションのいずれかが指定されていない限り、-filter /-include /-excludeオプションは不要です。 。

    BATCH.shファイルを作成するコードは、すべてのフィルター/包含/除外オプションを、シェルスクリプトファイルに「here」ドキュメントとして追加される単一のリストに変換します。上級ユーザーは、これを使用して、--deleteによって削除されるものの変更が必要な場合、除外リストを変更できます。通常のユーザーはこの詳細を無視して、バッチデータに対して適切な--read-batchコマンドを実行する簡単な方法としてシェルスクリプトを使用できます。

    rsyncの元のバッチモードは「rsync +」に基づいていましたが、最新バージョンでは新しい実装が使用されています。

私はあなたが試すことができると思います

rsync --write-batch=foo -Pav /junk user@host1:/backup
foo.sh user@host2:/backup
foo.sh user@host3:/backup

推奨コマンドは機能しません:remote destination is not allowed with --read-batch
kynan

完全なコマンドを表示します。-ファイル名は標準入力から読み取ることを意味し、STDINもfoo例ではローカルファイルから読み取られます。
クロエ

2
これは私がやろうとしていたことの最大の正しい解決策のように見えますが、これに対する私のユースケースは長い間エーテルに蒸発しました。:D
ジェシー

4

unisonを使用しみてください。ファイルのキャッシュを保持するため、ファイルリストの作成がはるかに高速になります。


2
注:Unisonはファイルの「キャッシュ」を保持しません。ファイル名、タイムスタンプ、チェックサムのデータベースのみを保持します。ファイルシステムのスキャンを実行し、チェックサムを作成してリモートと比較します。Unisonの唯一の利点は、双方向の同期です。Unisonをお勧めしますが、ここでは役に立ちません。
クロエ

4

rsync --batch-modeマルチキャストをサポート。ネットワークでこれが可能な場合は、調査する価値があるかもしれません。


2

ファイルシステムの変更はどうですか?

少し前に、マルチテラバイトFSをext3からXFSに切り替えました。ディレクトリをスキャンする時間(前回チェックしたときに約600,000個のファイルがある)は、15〜17分から30秒未満になりました。


1

直接的な答えではありませんが、rsyncバージョン3+を使用すると、ファイルリスト全体を生成する前に転送が開始されます。

まだあまり効率的ではない別のオプションは、それらをジョブとして実行することで、同時にいくつかを実行することです。

また、tarを使用してもかまわない場合は、この絞首刑について考えました。

tar cf - . | tee >(ssh localhost 'cat > test1.tar') >(ssh localhost 'cat > test2.tar') >/dev/null

もちろん、各ローカルホストは異なるサーバーになります(キーベースのログインを想定)。ただし、上記を使用したことはありません。


うーん!奇妙なことに、cwrsync(rsync 3.0.7)はそうしないようです。しかし、それがこれらの膨大なランタイムを削減する上で大きな助けになるので、なぜそうなのかを調べなければなりません。ありがとう!
ジェシー

両側のそのバージョン?
カイルブラント

いいえ、実際には。ローカルマシンはcwrsync 3.0.7で、リモートホスト(私が現在作業しているホスト)はDebian Lennyのrsync 3.0.3です。それが誤動作するほどバージョンの違いが大きすぎるとは思えないが、私は知らない。Debian側のアップグレードを検討する。
ジェシー

1
なんて奇妙な小さなワンライナー。ただし、rsyncを使用すると、せいぜい数百kbのデータが変更されただけで、複数の低速リンクでデータの数ギガバイトを再複製する必要がないという事実を活用していなければ、おそらくうまくいくでしょう。また、(cw)rsync 3.0.7の両端を取得しても、ファイルリストの構築と転送は引き続き行われました。ただし、それについてはあまり気にしません。
ジェシー

「tar cf-」ではありません 「tar c」と同じです。?
ヨハンブール

1

host1、host2、host3からrsyncジョブを実行するのはどうですか?または、ジョブを実行してhost1にコピーし、host2およびhost3で実行してhost1から取得します。


1

より良い解決策は、gitでリポジトリを作成し、3つのホストにプッシュすることです。より高速に、ファイルリストパーツは必要なく、リソースの消費が少なくなります。

幸運を祈ります、
ジョアン・ミゲル・ネベス


10
gitは変更時間もアクセス許可も保持せず(実行ビットを除く)、データの2番目のコピーをgitオブジェクトとして保存する必要がありますが、.git/既にほとんどのデータを保持しているリモートへのプッシュは高速になります。gitはrsyncの代替ではありません。
ダンD.

さらに、支払わない限り、gitは一般公開されます。
クロエ

8
@クロエ、あなたはgitをGitHubと間違えます。Gitリポジトリ自体は無料のオープンソースの分散バージョン管理システムであり、そして誰もが含め、あらゆる手段でのgitリポジトリをホストすることができhttpnfsそしてafp。GitHubは、gitリポジトリの作成と維持を管理し、(支払いを行わない限り)それらを公開するWebサイトです。
トリニンゲン14

1
@Chloe GitHubは公開されていますが、BitBucketはプライベートリポジトリを提供します。
sws

2
また、Gitは空のディレクトリを追跡しません。
フリム

1

自分でこの答えを探すには、最初にrsyncを使用してバッチを作成し、それをすべてに送信する必要があると思うので、一度だけファイルリストをクランチする必要があります3つのrsyncをすべてバックグラウンドで実行して、それらを並行して実行します。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.