解決策 1:
現在、rsync でこれを行う公式の方法があります (バージョン 3.1.0 プロトコル バージョン 31、Ubuntu Trusty 14.04 でテスト済み)。
#> ./rsync -a --info=progress2 /usr .
305,002,533 80% 65.69MB/s 0:00:01 xfr#1653, ir-chk=1593/3594)
/usr で試してみました ファイルシステム全体を転送するためにこの機能が必要だったので、フォルダと /usr 良い代表的なサンプルのようです.
--info=progress2 部分的な値であっても、全体のパーセンテージが適切に表示されます。実際、私の /usr フォルダが 6 GB を超えています:
#> du -sh /usr
6,6G /usr/
そして rsync すべてをスキャンするのに多くの時間がかかりました。したがって、私が見たほとんどの場合、パーセンテージは約 90% 完了していましたが、それでも何かがコピーされているのを見ると安心します :)
参照:
- https://stackoverflow.com/a/7272339/1396334
- https://download.samba.org/pub/rsync/NEWS#3.1.0
解決策 2:
以下は rsync バージョン 3.0.0 以降に適用されます。以下で説明するオプションは、2008 年 3 月 1 日のリリースで導入されました。
--info=progress2 とともに --no-inc-recursive も使用できます オプション (またはその短い --no-i-r エイリアス) を追加して増分再帰を無効にします。
これにより、転送が進むにつれてより多くのファイルを段階的に検出するのではなく、最初にファイル リスト全体が構築されます。開始前にすべてのファイルを認識しているため、全体的な進行状況についてより適切なレポートが得られます。これはファイルの数に適用されます。ファイル サイズに基づく進行状況は報告されません。
これにはトレードオフが伴います。事前にファイル リスト全体を作成すると、メモリの消費量が増え、実際の転送の開始が大幅に遅れる可能性があります。ご想像のとおり、ファイルが多いほど、遅延が長くなり、より多くのメモリが必要になります。
以下は rsync マニュアルからのものです (ソース - http://rsync.samba.org/ftp/rsync/rsync.html ):
<ブロック引用>-r, --recursive
これは、ディレクトリを再帰的にコピーするよう rsync に指示します。 --dirs (-d) も参照してください。 rsync 3.0.0 以降、使用される再帰的アルゴリズムは、以前よりもはるかに少ないメモリを使用するインクリメンタル スキャンになり、最初のいくつかのディレクトリのスキャンが完了した後に転送を開始します。このインクリメンタル スキャンは、再帰アルゴリズムにのみ影響し、非再帰転送を変更しません。また、転送の両端が少なくともバージョン 3.0.0 である場合にのみ可能です。
一部のオプションでは、完全なファイル リストを知るために rsync が必要なため、これらのオプションは増分再帰モードを無効にします。これらには、--delete-before、--delete-after、--prune-empty-dirs、および --delay-updates が含まれます。このため、接続の両端が少なくとも 3.0.0 の場合、 --delete を指定したときのデフォルトの削除モードは --delete-during になりました (この改善された削除モードを要求するには、 --del または --delete-during を使用します)明示的に）。 --delete-after を使用するよりも優れた選択肢である --delete-delay オプションも参照してください。
--no-inc-recursive を使用して増分再帰を無効にすることができます オプションまたはその短い --no-i-r エイリアス。
特定のバージョンの違いについては、https://rsync.samba.org も参照してください (下にスクロールして、リリース ニュースのリンクを確認してください)。
解決策 3:
'pv' (apt-get install pv Debian と ubuntu を使用)。転送されたデータの量はファイルのサイズと相関しているのではなく、転送元と転送先の間の差分であるため、転送されたファイルの数を監視することをお勧めします。また、ファイルをカウントすると、1 つの大きなデルタと小さなデルタの別のファイルに対して同じ進行状況がカウントされます。つまり、いずれにせよ、ETA の推定値はかなりかけ離れている可能性があります。サイズベースの ETA は、宛先が空の場合にのみ機能します。この場合、デルタ ==ソースのサイズです。
一般的な考え方は、rsync から「転送された」ファイルごとに 1 行を発行し、それらの行を「pv」でカウントすることです:
rsync -ai /source remote:/dest | pv -les [number of files] >/dev/null
私はファイルシステム全体をバックアップする傾向があります (いくつかの理由から)。この場合、はるかに安価な df を使用できます。 ファイル数を取得する (du ではなく) または find rsync が実行した後、もう一度ソース階層をトラバースします)。 -x オプションは、rsync が同じソース ファイルシステムにとどまるようにする (他の内部マウントに従わない) ように見えます:
rsync -aix /source remote:/dest | pv -les $(df -i /source | perl -ane 'print $F[2] if $F[5] =~ m:^/:') >/dev/null
一般的な方法で /source 内のファイルをカウントする場合は、find /source|wc -l を使用します (再度警告:I/O が遅く、重くなる可能性があります)。
解決策 4:
ダナキムは正しいです。合計進行状況インジケーターを追加する簡単な方法はありません。
これは、rsync が同期するファイルのリストを参照するときに、どのファイルを変更する必要があるかを前もって認識していないためです。デルタ転送を行っている場合は、実行する必要がある作業の全体像を把握するために、デルタ自体を事前に計算する必要があります。
つまり、どれだけの作業が必要かを計算する最も簡単な方法は、実際に作業を行うことです。
解決策 5:
長い転送の場合、du -s を実行して満足しています 両側に。 watch -n1 du -s でも 、もし私が本当に不安を感じたら。
watch コマンドを実行します (du -s ここでは) 定期的に (ここでは 1 秒ごとに) 出力をフルスクリーンで表示します。