編集：2つの詳細な答えに基づいて、以下を試しました。
rsync --progress -v -az -e “ssh” /archive/images/dcam/ [email protected]:/data/archive/images/dcam --dry-run
だから--progressを使用すると結果を見ることができます。 -vを使用すると冗長にできますか？ -azはそれを保持し（したがってタイムスタンプを取得します）、zはそれを圧縮してネットワークトラフィックを節約します。 -e 10.xxxxxシステムの認証キーにソースSSHキーを持つSSHを介してログインします。ああ、このエラーが発生しました。
rsync: Failed to exec \#342\#200\#234ssh\#342\#200\#235: No such file or directory (2)
rsync error: error in IPC code (code 14) at pipe.c(84) [sender=3.0.6]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in IPC code (code 14) at io.c(600) [sender=3.0.6]
リモートシステムにすでにデータが含まれている/data/archive/images/dcamがあるため、これは奇妙です。
rsyncがどのように機能するかを完全に理解してはいけません。私は2つのサーバーを持っています。あるサーバーには別のサーバーに転送したいデータがたくさんあります。だから... NFSはサーバーB（バックアップがある場所）からサーバーAにフォルダをマウントしました。
そしてこれは重要なライブサーバーなので、2TBのデータでRSYNCを実行することに緊張しました...次のように手動で実行しました。 /images/imageDateXX と入力し、2 TB のフォルダとデータに対してこれを繰り返します。いよいよ動作するようになりました。そのため、サーバーをダウンさせていないのは幸いで、このデータは一晩更新されています。したがって、サーバーBを最新の状態に保つためにcronjobを設定しました。
0 8 * * * rsync -r /archive/images/ /mnt/backup/archive/images
これは始まりましたが（私の考えでは）、完了するまでに2日かかります。単にサーバーAの新しい/変更された内容を見てサーバーBに入れるのではなく、すべてのファイルをサーバーBに再び上書きするようです。この理論をテストする方法がわかりませんが、時間がかかります。 rsyncにスイッチがない場合、またはフォルダごとにrsyncフォルダを実行して親フォルダでrsyncを実行すると、rsyncとは「異なる」ように見えます。なぜなら、rsyncはそれがすべて新しいデータだと思い、すべてをコピーするからです。サーバーbと同じ場所？
この理論をテストまたは決定する方法がわかりません。簡単だと思います。 rsyncは、ファイルがserverBにない場合、またはserverAから変更された場合に自動的にファイルを上書きするか、ファイルをコピーします。
ベストアンサー1
rsync --progress -av -e "ssh" /archive/images/ username@[serverIP-or-domainname]:/archive/images --dry-run
サンプル:
rsync --progress -av -e "ssh" /archive/images/ [email protected]:/archive/images --dry-run
これは、両方のシステムのディレクトリが/archive/imagesで、キーが設定されていて、リモートシステムがsshdを実行していると仮定します。私はそうすると確信しています。
--dry-run不快なミスを避けるのに役立つように、タスクが実行するアクションを特定することは常に便利です。
-v作業場所の追跡に役立つ出力の詳細を追加します。
--deleteソースに存在しなくなったファイルをターゲットから削除します。これは、リモートシステムにデータミラーを作成したい場合にしばしば必要です。データが大きく異なる場合は、およびを調べて、--delete-beforeどちら--delete-afterが--delete-during要件に最も適しているかを確認することをお勧めします。通常、--deleteこれはかなりうまく機能しますが、TiBデータの場合はこれが重要です。--delete-beforeたとえば、ほぼいっぱいのリモートディスクを処理する場合に便利です。
削除するときは注意してください！ ！ローカルパスにないすべてのエントリをリモートパスに削除します。つまり、間違ったパスを指定すると、そのリモートディレクトリ内のすべてのエントリを削除または削除しようとします。少なくとも間違えないように--delete最初から使用しないでください。--dry-run
-rtvzはい-a。ほとんどのアプリケーションにはこれで十分だと思います。
-a-aHAXデフォルトでは、ソースのほぼ実際のミラー（ほとんど完全なミラー）が作成されます。-a/（いいえ、、）と同じです--archive。-rlptgoD-H-A-X
--progressジョブの実行中に進行状況を表示するので便利です。
-e "ssh"sshを実行するときに、より多くのsshオプションまたはコマンドに他のオプション（たとえば、特定のsshポート）を使用する必要がある場合は、コマンドが長くなる可能性があります。サンプル:-e "ssh -p 423"
-z：CPU使用率を減らしたい場合に帯域幅が大きく変わらない場合（画像などのバイナリファイルを想定）、-z圧縮オプションを削除してください。
--bwlimit：マシン間のネットワーク帯域幅が多すぎるかどうかを心配する場合に便利です。最小速度サイズは1k、1KiB / s、1m、別名1MiB / sなどです。これは、ネットワーク伝送の帯域幅をすべて使用したくない場合に便利です。人が言ったように、--max-sizeさまざまな単位の構文を参照してください。
単位文字列の最初の文字は、B（バイト[該当なし
--bwlimit]）、K（キロ）、M（メガ）、G（ギガ）、T（テラ）、またはP（ペタ）です。文字列が単一文字である場合、または「ib」が追加された場合（例：「G」または「GiB」）、単位は1024の倍数です。 「B」で終わる2文字のサフィックス（「kb」など）を使用すると、1000の倍数である単位が得られます。文字列の文字は、使用する大文字と小文字の組み合わせにすることができます。
--partial：転送が中断される可能性があると思われる場合に便利です。これにより、中断時に rsync がデフォルトで転送の一部を削除するのを防ぎます。
最初の完全同期の後、変更されたファイルのみが更新されるため、それ以降のすべての同期速度ははるかに高速になります。ロジックが正常に機能している場合は、将来の同期--deleteで常にそれを使用して、ローカルファイルとリモートファイルを同期したままにし、削除したり名前を変更したファイルを削除したりすることができます。一部の構成では、ファイル内で変更されたデータのみが更新されます。たとえば、ファイルには変更可能なメタデータがありますが、バイナリコアデータは変更されず、メタデータ部分のみが変更される場合です。画像にはあまり良くありませんが、他のデータ型には適しており、同期を100倍高速化できます。
rsyncとnfs
特に、ext4を使用している場合、nfsを介したrsyncはすべてのファイルシステム属性をサポートしていないため失敗します（-aの場合と同じように転送したい場合）。また、非常に遅いです。 nfsは、拡張ファイル属性の問題のないローカルネットワークを介した小規模転送に適していますが、本番環境では使用しません。私はnfsを介してバックアップを実行するためにrsyncを使用しようとしましたが、あまりにも多くの属性を転送できないため、ext4が登場したときに停止する必要がありました。
マニュアルページの再同期
これらのシステムで作業するときは、rysncのマニュアルページを読むよりも役に立ちません。たとえば、--partial私は今日までこれが問題であることに気付かず、非常に大きなファイル転送の中断のために困難を経験して再起動する必要がありました。次回の起動時に中止されました。
私の考えでは、rysncがこれまでに作られた最高のcliソフトウェアの1つですが、マンページがひどくて再構成が切実に必要なので、ここにないものを見つけるのは難しいです。 、私は今日それを読むまでそのうちのいくつかを知っていました。たとえば、--partial大量のファイル転送が中断されたため、再起動に失敗したため、数え切れないほど時間がかかりました。
Andrew Tridgellにピザを送ってください、ハハ、人々がrsyncのためにお金を払いたいと思ったときに彼が求めるものです。しかし、より良い方法は、マニュアルページを修正してより便利にし、論理的な部分に分割することです。読んで使用してください。しかし、優れた文書ですが、再構成はうまくいきません。