如何在两台macOS设备间用rsync同步大二进制文件？增量同步失效如何解决

你观察到的“极少量修改依然触发全量传输、耗时和初次全拷贝一致”的现象完全符合现有环境下的行为特征，核心原因来自三个可叠加的问题点：

• 两台设备搭载的macOS 10.15.7自带的rsync 2.6.9版本存在已知功能缺陷：
• 对--inplace参数的逻辑处理存在先天设计缺陷：该版本在实现--inplace功能时，默认假设目标文件和源文件大小完全一致，因此只要检测到源端、目标端的文件大小不一致，就认为差量计算的开销大于直接全量传输的收益，直接跳过delta差量计算流程，强制触发全量文件传输——这和你“本地追加几字节、文件大小小幅变化后就全量拉取”的场景完全匹配
• 该版本的差量算法不具备偏移自适应匹配能力：默认从文件开头按固定块大小切分做校验，一旦文件尾部追加内容，后续所有块的起始偏移都会错位，无法识别已经和源端一致的块，进一步放大了全量传输的触发概率
• 针对130GB级别的大文件，该版本为了避免校验计算的CPU开销，会自动降级为全量传输模式，不再做差量计算
• 你当前命令中的-a归档参数，会默认尝试同步扩展属性、ACL、属主、属组信息，老版本rsync在遇到这类属性同步失败时，也会直接触发目标文件的全量重新拷贝
• 130GB文件在当前以太网环境下的传输耗时约20分钟，和你观察到的同步时长完全吻合，进一步验证了流程是直接全量拷贝，没有用到差量同步机制

• 优先替换系统自带的老旧rsync 2.6.9版本，更换为3.2.x以上的稳定版本。新版本针对大文件差量传输做了全方面优化：
• 修复了--inplace参数下的大小差异跳过差量计算的bug
• 引入了滑动窗口的块匹配逻辑，哪怕文件内任意位置出现非对齐的修改，也能精准识别已一致的块，只传输改动的部分
• 针对大文件自动计算最优块大小，130GB的虚拟磁盘文件仅需几秒的校验时间，不会出现自动降级全量传输的问题
• 临时不更换版本时，可通过调整参数规避现有bug，优化后的参考命令为：

rsync -av --partial --inplace --progress --no-whole-file --block-size=4194304 --no-xattrs --no-acls --no-owner --no-group user@ip:"source/file" "destination/file"

• --no-whole-file：强制开启差量传输，禁止自动降级为全量拷贝
• --block-size=4194304：手动指定4MB的块大小，和多数虚拟机虚拟磁盘的块大小对齐，提升校验匹配效率
• 关闭不必要的属性同步逻辑，避免属性同步失败触发的全量重传
• 场景化优化提示：
• 虚拟磁盘本身是按固定块分配空间的，哪怕你只修改了块内的几个字节，只要块的偏移和大小匹配，差量同步时仅需传输实际改动的几个块，130GB的文件修改少量内容时，同步耗时通常在几秒到十几秒，不会再出现20分钟的全量传输
• 两台设备处于同一以太网环境下，不需要额外调整网络参数，传输改动块的速度完全没有瓶颈

内容的提问来源于stack exchange，提问作者Kevin Delord