起因

最近有两台群晖远程异地文件同步的需求，原计划是打算同步共享文件夹 “Docs”。一开始先想到的是群晖自家的 Cloud Station Server套件，于是开始测试：

  1. 群晖A安装Cloud Station Server套件，选中了 “Docs”的同步；
  2. 群晖B安装Cloud Station ShareSync，选中群晖A中的“Docs”。

设置完成后，发现群晖A的 Cloud Station Server会试图扫描整个共享文件夹 “Docs”（是由图纸图片文件组成约8TB的数据），导致Cloud Station Server的数据库和日志暴增，最终无法响应。之后在群晖官网找到了 Cloud Station Server的技术白皮书，发现现有的数据量已经远远超出了他们所设计的性能范围。

之后又无奈的测试了开源的同步软件Syncthing：功能看起来很好，跑起来发现问题还是挺多的，主要还是数据量太大造成的，不同的目录会经常出现不同的权限错误，扫描反复中断，并且内网穿透也是时断时续，看来还是不适合在生产环境中使用。

于是只能退而求其次，再次回到 Cloud Station Server的方案，打算只同步共享文件夹 “Docs”的子文件夹"Sync（约50GB）"，可惜新的问题又出现了：

因为群晖A的Cloud Station Server只能选择拟同步的“共享文件夹”（不能选择子文件夹），但在群晖B的Cloud Station ShareSync的高级设置中，可以在拟同步的文件夹中指定同步子文件夹"Sync1"）。设置完成后，发现群晖A的Cloud Station Server仍然试图扫描整个“Docs”共享文件夹，还是会导致数据库和日志暴增，最终无法响应。于是联系了群晖技术支持，答复如下：

“ Cloud Station Server 是一定要扫描整个共享文件夹，这是当前的设计。如果是双向同步，除了Cloud Station Server，没有其他替代的同步方案。建议新建一个共享文件夹，然后将这50GB的文件放进去，单独创建任务进行同步。”

这种答复，Mmm...如果新建共享文件夹然后单独创建同步任务，是不现实的，因为除了权限问题，还涉及到变更路径，多出一个共享文件夹也会影响用户习惯。

曲线救国

后来我想到一个曲线救国的方式，使用mount —bind命令，达到欺骗 Cloud Station Server 的目的，避免对整个“Docs”共享文件夹的扫描的目的。

实现方法如下：

  1. 新建一个“FakeSync”共享文件夹；
  2. 然后使用mount —bind命令，把“FakeSync”共享文件夹和真正要同步的子文件夹“Docs/Sync”连接起来。打开ssh，输入：sudo mount --bind /volume1/FakeSync/ /volume1/Docs/Sync，实现所有对后一个目录的访问其实都是对前一个目录的访问；
  3. 在群晖A的Cloud Station Server中创建任务，指定同步“FakeSync”；群晖B的Cloud Station ShareSync中指定群晖A的“FakeSync”；
  4. 再用VI到/etc/rc.local中添加一遍 sudo mount --bind /volume1/FakeSync/ /volume1/Docs/Sync，这样才能开机自动挂载，避免重启之后同步失效。

结语

  • 对中小企业，使用群晖入门级的企业存储产品是相对有性价比的方案。群晖的技术支持不错，但是解决不了太多问题，你就是反馈了某些需求，未来也大概率不能解决；
  • DSM系统愿景是美好的，缺点也有不少，比如没有ACL同步、用户和用户组的同步，用户列表和权限不能以表格形式导出（虽然可以备份用户配置然后再用数据库编辑软件打开）等等。现有的功能，实际用下来也或多或少有些问题（不知道未来的DSM7是否会有改善）；
  • 目前没有免费软件或者开源软件能够真正稳定地实现海量数据（10TB以上）的同步。至于商用软件，可能会有更好的，不太了解。