背景: 私たちは、オンプレミスの NFS ファイルシステムと Azure NFS ベースのファイル共有間のデータの同期を伴うデータ移行プロジェクトに取り組んでいます。目標は、データの整合性と効率性を維持しながら、オンプレミス環境から Azure へのシームレスな移行を実現することです。
背景：
ソース: オンプレミスの NFS ファイルシステム。
宛先: Azure NFS ベースのファイル共有。
データサイズ：約350GB。
ツールの使用法:
AzCopy (サポートされていません): 当初、データ移行に AzCopy を使用しようとしましたが、Azure NFS ファイル システムではサポートされていないことがわかりました。
Rsync (ストレージ増加の問題): 次に、データ同期に Rsync を使用しました。しかし、Azure の同期先でストレージが大幅に増加し、プロセスが完了しませんでした。ストレージは明らかな理由もなく増加し続け、Rsync プロセスを中止せざるを得ませんでした。
Fpsync (最初の試行は成功): ストレージ増大の問題に対処するために、データ同期に Fpsync を導入しました。最初の試行では、初期同期が正常に完了し、期待が持てました。
問題: 原因不明のストレージ増加: 主な課題は、特に Rsync を使用した場合の Azure NFS の宛先でのストレージ使用率の原因不明の増加です。ソース データのサイズが同じであっても、宛先のストレージが大幅に増加し、プロセスが管理不能になります。
目的: このストレージ増大の問題のトラブルシューティングと解決に役立つ洞察、アドバイス、またはソリューションをコミュニティから求めています。目標は、Azure の宛先で効率的なデータ同期と最小限のストレージ使用量を確保することです。
追加情報: 隠しファイルやディレクトリを含むソース データは、正しくフォーマットされ、名前が付けられています。
同期中は権限が保持されます。
最初の同期では Fpsync で初期的な成功が得られましたが、その後の同期ではストレージの増大に関する問題が依然として発生しました。この問題に関するご提案、ご意見、ご経験などがありましたら、ぜひお聞かせください。当社はこの課題を解決し、Azure NFS へのデータ移行を成功させることを目指しています。
アップデート：
今、rclone ユーティリティを使用しましたが、同じ問題が発生しました。
答え1
man rsync注意深く 読んでください。いくつかのオプションを試して、--dry-run --itemize-changes 実際に何が行われるかを確認してください。
削除オプションを指定しないと、ソースでの削除がターゲットに反映されません。アーカイブのユースケースには最適ですが、日付スタンプ付きのログ ファイルのように保存期間が制限されているものには適していません。また、man ページによると、ファイルを削除する場合は * ワイルドカードを避けてください。
--delete
This tells rsync to delete extraneous files from the receiving side (ones that aren't on the sending
side), but only for the directories that are being synchronized. You must have asked rsync to send
the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory's contents
(e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer
individual files, not the files' parent directory.
「デフォルトの動作では、関連する宛先ファイルと同じディレクトリに各一時ファイルを作成します。」これらの一時ファイルにより、転送を中止できますが、かなりの余分なスペースが必要になります。すべてを更新する必要がある最悪のシナリオに備えて、慎重にソースの 2 倍のサイズを想定してください。この動作を変更する方法のうち、おそらく最も積極的なのは、--inplaceファイルを直接上書きすることです。危険: これにより、宛先で使用中のファイルが破損します。アクティブ/アクティブの使用例には適していません。
パフォーマンスに関しては、ローカル システムとリモート システムの両方で制限要因となっているものを見つけます。最悪のケースを想定して考えると、100 IOPS の低速スピンドルで 100 万個のファイルを処理すると、ファイル リストを列挙して比較するだけで数時間かかる可能性があります。ただし、ファイル データをコピーする段階になると、ボトルネックはネットワーク帯域幅と、ssh および圧縮用の CPU に移行する可能性があります。
ファイル同期ツール以外の初期コピーの代替プランを考え出してください。たとえば、共有のローカル バックアップを取得し、NFS がマウントされた Azure のホストに復元します。増分ファイル同期と比較すると、ネットワーク経由でアーカイブ (.tar など) をコピーしてすべて抽出する方が高速かつ簡単です。
そういえば、最初のコピーの後に追いつくための増分として rsync が役立つかもしれません。比較にはまだ時間がかかりますが、変更率が低く、コピーするものがあまりない場合は、はるかに速くなります。