大きなディレクトリツリーをローカルにコピーしますか？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）によって保存されますが、質問は、ファイルシステム情報の完全なコピーが必要なことを意味しています。そして、-aハードリンク、拡張属性、または（Linuxの場合）ACLまたは上記は含まれませんや（OS X上）リソースフォークをこのように、ファイルシステムの堅牢なコピーのために、あなたはそれらのフラグを含める必要があります：

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

デフォルトのcpが再び開始されますが、-uフラグは「SOURCEファイルが宛先ファイルよりも新しい場合、または宛先ファイルが欠落している場合にのみコピーします」。また、-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 --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

これらはすべてローカルコピー専用です。

あなたが好むものは何でも。-aあなたが使うことを決めるときにスイッチを忘れるなcp。

本当に答えが必要な場合：rsyncを使用するのは、はるかに柔軟だからです。コピーが完了する前にシャットダウンする必要がありますか？ctrl-cを押して、すぐに再開します。一部のファイルを除外する必要がありますか？使用するだけ--exclude-fromです。所有権または権限を変更する必要がありますか？rsyncがそれを行います。

このrsyncコマンドは、転送するバイトごとに常にチェックサムを計算します。

コマンドラインオプション--checksumは、ファイルのチェックサムを使用して転送するファイルを決定するかどうかにのみ関係します。

-c, --checksum mod-timeとサイズではなく、チェックサムに基づいてスキップします」

マンページには次のようにも書かれています。

rsyncは、ファイル全体のチェックサムをチェックすることにより、転送された各ファイルが受信側で正しく再構築されたことを常に確認しますが、転送後の自動検証は、このオプションの転送前の「このファイルは必要ですか？」更新しますか？」小切手。

だから、rsyncまた、常に、場合でも、受信側でファイル全体のチェックサムを計算-c/ --checksumオプションが「オフ」です。

rsync -aPhW --protocol=28これらの大きなコピーをRSYNCで高速化するのに役立ちます。90GiBの途中であり、それが壊れているという考えがCPから私を怖がらせるので、私は常にrsyncに行きます

rsyncは優れていますが、ツリーをメモリに保存するため、非常に大きなディレクトリツリーに問題があります。このスレッドを見つけたときに、彼らがこの問題を修正するかどうかを確認するだけでした。

私も見つけました：

http://matthew.mceachen.us/geek/gigasync/

また、手動でツリーを分割し、複数のrsyncを実行することもできます。

このスレッドは非常に有用であり、結果を達成するためのオプションが非常に多かったため、それらのいくつかをベンチマークすることにしました。私の結果は、他の人がより速く働いたという感覚を持っているのに役立つと信じています。

1,753,200個のファイルに分散された532Gbのデータを移動するには、これらの時間がありました。

• rsync 232分かかりました
• tar 206分かかった
• cpio 225分かかりました
• rsync + parallel 209分かかった

私の場合、私はを使用することを好みましたrsync + parallel。この情報がより多くの人々がこれらの選択肢の中から決定するのに役立つことを願っています。

完全なベンチマークはここに公開されています

ローカルディレクトリのローカルコピーを行うとき、私の経験では、「cp -van src dest」はrsyncより20％高速です。再起動可能性に関しては、それが「-n」の機能です。部分的にコピーされたファイルをrmするだけです。ISOなどの場合を除き、苦痛はありません。

ARJはとても古い学校です!! 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初回実行時に追加して、さらに高速化することができます。

両方とも問題なく動作します。

tar 仕事もしますが、rsyncのように中断されることから再開しません。

ARJを使用するとどうなりますか？

arj a -jm -m1 -r -je filepack /source

どこ-jm -m1に圧縮レベルがあり-je、それを実行可能にします。これで、カプセル化されたファイルのbashができました。

次に、ターゲットマップへの抽出用

filepack -y  

ソースマップが作成される場所-y（常に受け入れ、上書き、スキップなど）

次に、可能であれば、ファイルパックをターゲット領域にscp ftpして実行します。

に適用できる高速化がいくつかありますrsync。

避ける

• -z/ --compress：転送はネットワーク上ではなくRAM上で行われるため、圧縮はCPUのみをロードします。
• --append-verify：中断された転送を再開します。これは良い考えのように聞こえますが、危険な障害の場合があります。ソースと同じサイズ（またはそれ以上）の宛先ファイルは無視されます。また、最後にファイル全体をチェックサムします--no-whole-file。これは、危険な障害ケースを追加する際に、速度が大幅に向上することを意味します。

つかいます

• -S/ --sparse：ヌルのシーケンスをスパースブロックに変換します
• --partialまたは-Pどちらか--partial --progress：将来の再開のために部分的に転送されたファイルを保存します。注：ファイルには一時的な名前がないため、コピー全体が完了するまで、他のユーザーが宛先を使用しないことを確認してください。
• --no-whole-file再送信が必要なものはすべてデルタ転送を使用します。部分的に転送されたファイルの半分を読み取ることは、多くの場合、再度書き込むよりもはるかに高速です。
• --inplace ファイルのコピーを回避します（ただし、転送全体が完了するまで宛先が何も読み取っていない場合のみ）