背景：我们正在开展一个数据迁移项目，涉及本地 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 慢速主轴上的一百万个文件可能需要几个小时才能枚举和比较文件列表。然而，当它开始复制文件数据时，瓶颈可能会转移到网络带宽，以及用于 ssh 和压缩的 CPU。
想出非文件同步工具的初始副本替代计划。例如，对共享进行本地备份，并将其还原到安装了 NFS 的 Azure 主机。与增量文件同步相比，通过网络复制存档（.tar 或其他）并提取所有内容更快、更简单。
说到这里，rsync 可能有助于在初始复制后以增量方式跟上进度。仍需要一些时间来进行比较，但如果变化率较低且没有太多内容需要复制，则速度会快得多。