是否Synology DSM 4.3的默认rsync实施不能处理“庞大”的数据量，并可能导致版本控制/重复数据删除？ 难道是任何variables（见下面的详细信息 ）可以使这变得更加困难？
编辑：如果上述索赔是无意义的或可能是真的，我只是在寻找答案。
详细信息 ：
在工作中，我们有一台Synology NAS在办公室运行。 这个NAS是由一些devise师直接使用的。 他们有运行的项目，包括高分辨率的股票照片，大PSD，PDF和什么不是。 我们有一个大约是一个文件夹。 大小430GB，只包含当前正在运行的项目。 这个文件夹应该每周通过我们的networking连接备份到数据中心。
我们所有的IT都由第三方处理，声称我们的备份开始形成一定的大小（“100GB +”），DSM（4.3）rsync的缺省实现无法处理大量的数据在线备份（在他们的数据中心的一台机器上）。 他们说备份包含大约10TB的数据，因为rsync在“版本/重复数据删除”（保留时间：30天）方面存在问题，并且无法使用。
正因为如此，他们build议使用“专业在线备份服务”，这大大提高了每GB的成本。
Rsync本身不会阻塞大文件或“太多”的文件。 根据您的情况，可能（但不太可能）每周的rsync作业需要超过1周的时间才能完成，导致在之前的rsync作业完成之前开始新的rsync作业。
IT人士的常识是，传输大量小文件比传输几个非常大的文件（等同的网速，相同的数据量等等）要花费更多的时间。看看这个（ “ 传输数以百万计的图像 ”）作为一个关于堆栈溢出的例子讨论，以及这个（“ 哪个更快，为什么：传输几个小文件或几个大文件？ ”）。
所以问题可能是您应该在运行rsync之前压缩文件/文件夹，然后将压缩文件复制到异地数据中心。 这样可以节省您的异地数据存储成本，虽然它确实打开了另一个蠕虫。
当然，您的第一步是确定运行rsync作业需要多长时间。 然后确定是否需要通过预先压缩数据或转移到备用备份解决scheme来更改备份方法。
顺便说一句，截至本文，Synology DSM 5.1是最新版本，5.2版本正在testing中。 如果您尚未更新到DSM 5.1，则应该更新。 这肯定不会伤害你的情况。