Synology DSM 4.3のデフォルトのrsync実装では「膨大な」量のデータを処理できず、バージョン管理や重複排除がうまくいかないというのは本当でしょうか？変数（詳細情報下記のような変更により、この状況はさらに困難になるのでしょうか?
編集: 私は上記の主張がナンセンスなのか、真実である可能性があるのかという答えだけを求めています。
詳細情報:
職場では、オフィスで Synology NAS を稼働させています。この NAS は、数人のデザイナーが直接作業する場所として使用されています。彼らは、高解像度のストック写真、大きな PSD、PDF などで構成されるプロジェクトを実行しています。現在実行中のプロジェクトのみで構成される、サイズが約 430 GB のフォルダーがあります。このフォルダーは、インターネット接続を介して毎週データセンターにバックアップされることになっています。
当社の IT はすべてサードパーティによって処理されていますが、そのサードパーティは、バックアップが一定サイズ (「100 GB 以上」) になり始めており、DSM (4.3) rsync のデフォルト実装では、オンライン バックアップ (データセンター内のマシンの 1 つ) への膨大な量のデータを処理できないと主張しています。rsync に「バージョン管理/重複排除」(保持期間: 30 日) の問題があり、うまく機能しないため、バックアップが約 10 TB のデータで構成されていると述べています。
このため、彼らは「プロフェッショナル オンライン バックアップ サービス」の使用を提案しますが、これによりオンライン バックアップの GB あたりのコストが大幅に増加します。
答え1
Rsync自体大きなファイルサイズでも詰まらないまたは「ファイルが多すぎる」。状況によっては、毎週の rsync ジョブが完了するまでに 1 週間以上かかる可能性があり (可能性は低いですが)、前の rsync ジョブが完了する前に新しい rsync ジョブが開始される可能性があります。
IT関係者の間では、大量の小さなファイルを転送すると、他の条件が同じ（インターネット速度、ネットワーク容量が同じ）であれば、非常に大きなファイルを数個転送するよりもはるかに時間がかかることは周知の事実です。額データなど...これを見てみましょう（"数百万枚の画像を転送") は Stack Overflow での議論の例として挙げられます。また、こちら ("複数の小さなファイルを転送するのと、少数の大きなファイルを転送するのとでは、どちらが速いですか? また、その理由は?") を例として、Serverfault で議論します。
したがって、問題は、rsync を実行する前にファイル/フォルダを圧縮し、圧縮されたファイルをオフサイトのデータ センターにコピーする必要があるということかもしれません。いずれにしても、これによりオフサイトのデータ ストレージ コストは節約できますが、別の問題が発生する可能性があります。
もちろん、最初のステップは、rsync ジョブの実行にかかる時間を把握することです。次に、事前にデータを圧縮するか、別のバックアップ ソリューションに移行するかして、バックアップ方法を変更する必要があるかどうかを判断します。
ちなみに、この記事の投稿時点では、Synology DSM 5.1 が最新バージョンで、5.2 はベータ版です。まだアップデートしていない場合は、DSM 5.1 にアップデートしてください。これによって状況が悪化することは絶対にありません。