Rsyncクライアントは10時間以上かかります

Rsyncクライアントは10時間以上かかります

rsync バージョン 3.1.3-6 プロトコル バージョン 31 cifs-utils/stable 2:6.8-2 amb64 nfs-common/stable 1:1.3.4-2.5 Debian Linux 10 Buster FreeNAS 11.3-U3.2 (IxSystems FreeNAS Mini)

私はいくつかのリモート施設をバックアップするために小さな仮想Debian Linuxサーバーを使用しています。私はDebianサーバーを使用しています。 FreeNAS(FreeBSD)を使用して大量の混乱なしにcifs共有を一貫してマウントすることはできないので、私はLinuxにもっと慣れていて、FreeNASのフードの下で遊び心がありません。回避できる場合 - Debainがcifを一貫して安定してマウントできるようにし、NFSを使用してFreeNASサーバーをマウントできる場合 - 数ヶ月間うまくいきました。だから私の小さなDebianバックアップサーバーはFreeNASサーバーとクライアントコンピュータの間のブリッジとして機能します。

Debian - 起動時にFreeNASにマウントしてNFSを共有 - 永久に問題は発生しません。 Debian - 6時間ごとに小さなバッチスクリプトを実行してターゲットクライアントWindows PCをマウントし、マウントされたcifs共有のデータをマウントされたnfs共有にrsyncします。

これは問題かもしれないと思いましたが、これを見つけました。郵便はがきユーザーが指摘した場所

rsyncに関する限り、2つのローカルファイルツリー間でコピーされるため、ほとんどの最適化(有名なデルタアルゴリズムを含む)は無効になります。

だから私の質問は、2つのローカルファイルシステムと見なされても最適化を強制する方法はありますか?その記事で彼らは削除しようとしましたが、私はそうではありませんでした。私は、すべてのユーザーの備蓄をバックアップしただけです。

答え1

このフラグを使用して最適化を強制することはできますが、--no-whole-file転送プロセスを遅くする以外に何もすることはほとんど不可能です。

このオプションを考慮する前に、ファイルの変更時間が保持されるように--archive-a)または--times()フラグを使用してください。-tファイルサイズと組み合わせると、「クイックrsyncチェック」がファイルを再コピーするのではなくスキップするのに十分であることを確認するのに役立ちます。

--no-whole-fileこれが悪い考えである理由は次のとおりです。

デルタアルゴリズムはファイルのブロックを調べて、どのブロックを転送する必要があるかを確認します。小さな変更の場合は、ブロックを1つだけ変更すればよいので、非常に魅力的です。ただし、どのブロックが変更されたかを確認するには、ソースファイルとターゲットファイルの両方を読み取る必要があります。 2つの異なるシステムがある場合は、2つの独立したプロセッサ/ディスクの組み合わせを使用してこれを並行して実行できます。ただし、2つのローカルファイルシステムがある場合でも、2つのファイルを読み取る必要がありますが、プロセッサとディスクの競合が発生します。

最悪の場合、変更されたブロックを書き込むには、2つのファイルを最初から最後まで読み取らなければならないという意味だ。ただし、この時点では、とにかくターゲットファイルの一部または全部を書き換える必要があるため、1つを読んで別のものに書き込むことができます。

関連情報