Synology DSM 4.3 的默认 rsync 实现是否无法处理“大量”数据，并且可能会搞乱版本控制/重复数据删除？可能是因为以下任何变量（请参阅详细信息（见下文）会让事情变得更加困难吗？
编辑：我只不过是在寻找一个答案，看看上述说法是否无稽之谈或者可能是真的。
详细信息：
在工作中，我们在办公室运行着一台 Synology NAS。一些设计师直接在办公室使用这台 NAS 进行工作。他们正在进行的项目包括高分辨率库存照片、大型 PSD、PDF 等等。我们有一个大约 430GB 大小的文件夹，里面只包含当前正在运行的项目。这个文件夹应该每周通过我们的互联网连接备份到数据中心。
我们所有的 IT 都由第三方处理，他们声称我们的备份开始形成一定规模（“100GB+”），而 DSM (4.3) rsync 的默认实现无法处理在线备份（在其数据中心的一台机器上）的大量数据。他们说备份包含大约 10TB 的数据，因为 rsync 在“版本控制/重复数据删除”（保留：30 天）方面存在问题并且出现故障。
因此，他们建议使用“专业在线备份服务”，这会大大提高我们每 GB 的在线备份成本。
答案1
Rsync 本身不受大文件大小限制或“太多”文件。根据您的情况，每周的 rsync 作业可能（但不太可能）需要超过 1 周的时间才能完成，从而导致新的 rsync 作业在前一个 rsync 作业完成之前开始。
IT 人员都知道，在其他条件相同的情况下（相同的互联网速度、相同的数量数据等...看看这个（“传输数百万张图片“）作为 Stack Overflow 上的示例讨论，以及这个（“哪个更快，为什么：传输几个小文件还是传输几个大文件？“) 作为 Serverfault 上的示例讨论。
因此，问题可能是您应该在运行 rsync 之前压缩文件/文件夹，然后将压缩文件复制到异地数据中心。这无论如何都会为您节省异地数据存储成本，尽管这确实会带来另一个麻烦。
当然，您的第一步是确定 rsync 作业需要多长时间才能运行。然后确定是否需要更改备份方法，方法是预先压缩数据或转向其他备份解决方案。
顺便说一句，截至本文发布时，Synology DSM 5.1 是最新版本，而 5.2 处于测试阶段。如果您还没有更新到 DSM 5.1，您应该更新到它。这肯定不会对您的情况造成影响。