上下文：我們正在進行一個資料遷移項目，涉及本地 NFS 檔案系統和基於 Azure NFS 的檔案共用之間的資料同步。目標是確保從本地環境無縫過渡到 Azure，同時保持資料完整性和效率。
背景：
來源：本機 NFS 檔案系統。
目標：Azure 基於 NFS 的檔案共用。
資料大小：約350GB。
工具使用：
AzCopy（不支援）：我們最初嘗試使用 AzCopy 進行資料遷移，但發現 Azure NFS 檔案系統不支援它。
Rsync（儲存成長問題）：然後我們轉向 Rsync 進行資料同步。然而，我們在 Azure 目的地遇到了顯著的儲存成長，並且該過程從未完成。儲存無明顯原因地不斷增加，迫使我們放棄 Rsync 進程。
Fpsync（第一次嘗試成功）：為了解決儲存成長問題，我們過渡到Fpsync進行資料同步。在第一次嘗試中，它表現出了希望，成功完成了初始同步。
問題：無法解釋的儲存成長：我們的主要挑戰是 Azure NFS 目標的儲存利用率無法解釋的成長，尤其是使用 Rsync 時。即使來源資料大小保持不變，目標儲存也會顯著增加，使流程難以管理。
目標：我們正在向社群尋求見解、建議或解決方案，以協助追蹤和解決此儲存成長問題。我們的目標是確保 Azure 目標端的高效資料同步和最少的儲存使用。
附加資訊：來源資料（包括隱藏檔案和目錄）的格式和命名正確。
同步期間會保留權限。
雖然我們在首次同步中使用 Fpsync 取得了初步成功，但後續同步仍然出現儲存成長問題。任何與此問題相關的建議、見解或經驗將不勝感激。我們正在尋求解決這項挑戰並確保資料成功遷移到 Azure NFS。
更新：
現在我使用了 rclone 實用程式並遇到了相同的問題。
答案1
仔細讀man rsync。嘗試一些選項， --dry-run --itemize-changes 看看到底會做什麼。
不提供任何刪除選項意味著來源上的刪除不會反映在目標上。非常適合歸檔用例，但不適合保留有限的內容（例如帶有日期標記的日誌檔案）。另外，如果要刪除文件，請避免使用 * 通配符，根據手冊頁：
--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.
“預設行為是在與關聯目標檔案相同的目錄中建立每個臨時檔案。”這些臨時檔案允許中止傳輸，但需要大量的額外空間。保守地，假設來源大小是來源的兩倍，以應對需要更新所有內容的最壞情況。在改變這種行為的方法中，最激進的可能是--inplace直接覆寫文件。危險：這會損壞目標上正在使用的文件，不適用於主動/主動用例。
關於效能，找出本地和遠端系統的限制因素。如果我編出最壞情況的數字，100 IOPS 慢速軸上的 100 萬個文件可能需要幾個小時才能列舉和比較文件清單。然而，當開始複製檔案資料時，瓶頸可能會轉移到網路頻寬以及用於 ssh 和壓縮的 CPU。
為初始副本提出非文件同步工具的替代計劃。例如，對共用進行本機備份，並將其還原到 Azure 中安裝了 NFS 的主機。與增量檔案同步相比，透過網路複製存檔（.tar 或其他內容）並將其全部提取更快、更簡單。
說到這裡，rsync 可能會作為增量有用，以趕上初始副本之後的情況。仍然需要一些時間進行比較，但如果變化率較低且沒有太多可複製的內容，則速度會更快。