解決策 1:
rsync は、何らかの理由で中断された場合に、ほとんどコストをかけずに簡単に再起動できることを意味するため、rsync を使用します。また、rsync であるため、大きなファイルの途中で再起動することもできます。他の人が言及しているように、ファイルを簡単に除外できます。ほとんどのものを保存する最も簡単な方法は、 -a を使用することです フラグ – 「アーカイブ」。だから:
rsync -a source dest
UID/GID とシンボリック リンクは -a まで保持されますが、 (-lpgo を参照) ）、あなたの質問は、フルが必要かもしれないことを意味します ファイルシステム情報のコピー。と -a ハードリンク、拡張属性、または ACL (Linux の場合) または上記の も も含まれません リソース フォーク (OS X 上)。したがって、ファイル システムの堅牢なコピーを作成するには、これらのフラグを含める必要があります。
rsync -aHAX source dest # Linux
rsync -aHE source dest # OS X
デフォルトの cp が再び開始されますが、-u フラグは「ソース ファイルが宛先ファイルよりも新しい場合、または宛先ファイルが見つからない場合にのみコピーします」 .そして -a (アーカイブ) フラグは、再起動してアクセス許可を保持する必要がある場合、ファイルを再コピーするのではなく、再帰的になります。そう:
cp -au source dest
解決策 2:
ローカル ファイル システムにコピーするとき、私は次のオプションを指定して 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 -)
解決策 3:
大量のデータをコピーする必要がある場合は、通常、tar と rsync を組み合わせて使用します。最初のパスは、次のように tar することです:
# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
通常、大量のファイルでは、何らかの理由で tar が処理できないものがあります。または、プロセスが中断されるか、ファイルシステムの移行の場合は、実際の移行手順の前に初期コピーを実行することをお勧めします。とにかく、最初のコピーの後、rsync ステップを実行してすべてを同期します。
# cd /dst; rsync -avPHSx --delete /src/ .
/src/ の末尾のスラッシュに注意してください 重要です。
解決策 4:
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 -
これらはすべてローカル コピー用であることに注意してください。
解決策 5:
このスレッドは非常に役に立ちました。結果を達成するためのオプションが非常に多かったため、そのうちのいくつかをベンチマークすることにしました。私の結果は、何がより速く機能したかの感覚を持っている他の人に役立つと信じています.
532Gb を移動するには 1,753,200 ファイルに分散されたデータ そんな時がありました:
rsync232 分かかりましたtar206 分かかりましたcpio225 分かかりましたrsync + parallel209分かかりました
私の場合、 rsync + parallel を使用することを好みました .この情報が、より多くの人々がこれらの選択肢の中から決定するのに役立つことを願っています.
完全なベンチマークはここで公開されています