大きなディレクトリツリーをローカルにコピーしますか？ cpまたはrsync？
約1.8 TBの大きなディレクトリツリーをコピーする必要があります。それはすべてローカルです。習慣からrsyncを使用しますが、意味があるかどうか、そしてcpを使用するべきかどうか疑問に思います。
パーミッションとuid/gidはコピーで保持する必要があるので心配です（rsyncがこれを行うことは知っています）。同様にシンボリックリンクのようなもの。
宛先が空なので、一部のファイルを条件付きで更新することを心配する必要はありません。これはすべてローカルディスクなので、sshやネットワークについて心配する必要はありません。
私がrsyncから離れて誘惑される理由は、rsyncが必要以上のことを行う可能性があるためです。 rsyncチェックサムファイル。私はそれを必要とせず、cpよりも時間がかかるのではないかと心配しています。
では、rsyncまたはcpは何を考えていますか？
私はrsyncを使用します。これは、何らかの理由で中断された場合に、非常に少ないコストで簡単に再起動できることを意味します。また、rsyncであるため、大きなファイルを途中で再起動することもできます。他の人が言うように、それはファイルを簡単に除外することができます。ほとんどのものを保存する最も簡単な方法は、-aフラグを使用することです–「アーカイブ」。
rsync -a source dest
UID/GIDとシンボリックリンクは-a（-lpgoを参照）によって保持されますが、あなたの質問はfullコピーが必要かもしれないことを示唆していますファイルシステム情報の;および-aには、ハードリンク、拡張属性、またはACL（Linuxの場合）または上記norリソースフォーク（OSの場合）は含まれませんX.）したがって、ファイルシステムの堅牢なコピーのために、これらのフラグを含める必要があります。
rsync -aHAX source dest # Linux
rsync -aHE source dest # OS X
-uフラグは "コピーはソースファイルが宛先ファイルよりも新しい場合、または宛先ファイルが欠落している場合にのみ"。また、-a（アーカイブ）フラグは、再起動してアクセス許可を保持する必要がある場合、ファイルを再コピーするのではなく、再帰的になります。そう：
cp -au source dest
ローカルファイルシステムにコピーするときは、rsyncを次のオプションと共に使用する傾向があります。
# rsync -avhW --no-compress --progress /src/ /dst/
ここに私の推論があります：
-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)
別の回答で示唆されているように、次のtarコマンドを介して上記のrsync設定を使用すると、転送が17％高速になることがわかりました。
# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
大量のデータをコピーする必要がある場合は、通常、tarとrsyncを組み合わせて使用します。最初のパスは、次のようなtarを実行することです。
# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
通常、ファイルが大量にある場合、何らかの理由でtarが処理できないファイルがあります。または、プロセスが中断されるか、ファイルシステムの移行の場合は、実際の移行ステップの前に初期コピーを実行することをお勧めします。とにかく、最初のコピーの後で、私はそれをすべて同期するためにrsyncステップを実行します。
# cd /dst; rsync -avPHSx --delete /src/ .
/src/の末尾のスラッシュは重要であることに注意してください。
rsync
これが私が使用するrsyncです。これではなく、単純なコマンドにはcpを使用します。
$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/
cpio
これがさらに安全な方法です、cpio。 tarと同じくらい高速で、おそらくもう少し高速です。
$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null
tar
これも良好であり、読み取りエラーが続きます。
$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -
これらはすべてローカルコピー専用です。
あなたが好むものは何でも。 cpを使用する場合は、-aスイッチを忘れないでください。
本当に答えが必要な場合：私はrsyncを使用します。これは、はるかに柔軟だからです。コピーが完了する前にシャットダウンする必要がありますか？ちょうどctrl-cを押して、すぐに再開します。一部のファイルを除外する必要がありますか？ --exclude-fromを使用してください。所有権または権限を変更する必要がありますか？ rsyncがそれを行います。
rsyncコマンドは、転送するすべてのバイトのチェックサムを常に計算します。
コマンドラインオプション--checksumは、ファイルのチェックサムを使用して転送するファイルを決定するかどうかにのみ関係します。つまり、
-c, --checksum変更時間とサイズではなく、チェックサムに基づいてスキップします "
マンページにも次のように書かれています：
Rsyncは常に、ファイル全体のチェックサムをチェックすることにより、転送された各ファイルが受信側で正しく再構築されたことを検証しますが、転送後の自動検証は、このオプションの転送前の「このファイルが必要か更新しますか？」小切手。
したがって、rsyncも、-c/ --checksumオプションが「オフ」の場合でも、常に、受信側でファイル全体のチェックサムを計算します。
rsync -aPhW --protocol=28は、RSYNCでこれらの大きなコピーを高速化するのに役立ちます。 90GiBの途中にあり、それが壊れるという考えがCPから怖がってしまうので、私は常にrsyncを使います
このスレッドは非常に便利で、結果を得るには非常に多くのオプションがあったため、そのうちのいくつかをベンチマークすることにしました。私の結果は、他の人が何が速く機能したかを理解するのに役立つと思います。
532Gbのデータを1,753,200個のファイルに分散して移動するには、次のような時間がありました。
rsyncには232分かかりましたtarは206分かかりましたcpioには225分かかりましたrsync + parallel209分かかりました
私の場合、私はrsync + parallel。この情報が、より多くの人々がこれらの選択肢の中から決定するのに役立つことを願っています。
完全なベンチマークが公開されます ここ
rsyncはすばらしいですが、ツリーをメモリに格納するため、非常に大きなディレクトリツリーには問題があります。私はこのスレッドを見つけたとき、彼らがこの問題を解決するかどうかを確認しようとしていました。
私も見つけました：
http://matthew.mceachen.us/geek/gigasync/
ツリーを手動で分割して、複数のrsyncを実行することもできます。
ローカルでローカルディレクトリのコピーを行う場合、私の経験では「cp -van src dest」はrsyncよりも20％高速です。再起動性に関しては、これが「-n」の機能です。部分的にコピーされたファイルをrmする必要があるだけです。 ISOやそのようなものでない限り、痛みはありません。
ARJ IS SO OLD SCHOOL !! ARJやrsyncがパフォーマンスを発揮することを本当に疑っています。
間違いなく私がいつもやっていることはcpioを使うことです：
find . -print | cpio -pdm /target/folder
これはCPよりもほぼ高速で、tarよりも間違いなく高速で、パイプを一切使用しません。
あなたは間違いなく rclone を試してみたいと思います。これはすごく速いです：
Sudo rclone sync /usr /home/fred/temp -P -L --transfers 64
Transferred: 17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors: 75 (retrying may help)
Checks: 691078 / 691078, 100%
Transferred: 345539 / 345539, 100%
Elapsed time: 1m50.8s
これは、LITEONIT LCS-256（256GB）SSDとの間のローカルコピーです。
あなたは付け加えられます --ignore-checksumを最初の実行でさらに高速化します。
どちらも問題なく動作します。
rsyncに適用できる高速化がいくつかあります：
避ける
-z/--compress：転送はネットワーク経由ではなくRAM経由であるため、圧縮はCPUにのみ負荷をかけます。--append-verify：中断された転送を再開します。これは良い考えのように聞こえますが、危険な失敗事例があります。ソースと同じサイズ（またはそれ以上）の宛先ファイルは無視されます。また、最後にファイル全体をチェックサムします。つまり、--no-whole-file危険な失敗のケースを追加します。
使用する
-S/--sparse：nullのシーケンスをスパースブロックに変換--partialまたは-Pは--partial --progress：今後再開するために、部分的に転送されたファイルを保存します。注：ファイルには一時的な名前が付けられないため、コピー全体が完了するまで、他のファイルが宛先を使用しないことを確認してください。--no-whole-file再送信が必要なものはすべてデルタ転送を使用します。部分的に転送されたファイルの半分を読み取ることは、多くの場合、再度書き込むよりもはるかに高速です。--inplaceファイルのコピーを回避します（ただし、転送全体が完了するまで、何も宛先を読み取っていない場合のみ）
tarも機能しますが、rsyncのように中断されることはありません。
ARJを使用している場合はどうなりますか？
arj a -jm -m1 -r -je filepack /source
どこ -jm -m1は圧縮レベルであり、-jeを実行可能にします。これで、カプセル化されたファイルのbashができました。
次に、ターゲットマップに抽出します
filepack -y
ソースマップが作成される場所（どこで-yは常に受け入れ、上書き、スキップなど）
次に、可能であれば、ファイルパックをターゲット領域にftpで実行して実行できます。