最近这几天发现Garmin Connect在同步表盘设置的时候会失败，主要表现在同步之后表盘设置不会被应用，或者会直接初始化为最初版本。当前受到影响版本是4.22的版本，不确认这个问题是不是在之前就出现，所以上网找了一下原因，在这里记录下供大家参考。当然可能过几个版本之后，Garmin修复了错误，那就不用看本文了。

这个表盘设置同步失败的问题，其实并不是最近才出现的，三个月之前，就已经有人在社区中反馈类似的问题。开发者们发现了大量多用户反馈报错，后来才发现应该是Garmin软件本身的问题。当时的BUG主要体现在，如果表盘设定中有针对日期的设定，如果你没有进行设置的话，同步之后就会导致配置文件失败，然后就没有然后了。

只是没想到的是，这次的Garmin软件更新，直接把这个BUG扩大化了，所有的表盘几乎全部被波及。如果你没有修改过表盘设置，其实你感觉不到，但是如果你一旦修改了设置，或者更新了新版本的表盘，然后恭喜你，你就只能使用初始化表盘而且无法修改配置了。

而我们知道，Garmin Connect是必装的软件，所以这个BUG看似在系统更新前是无解了，不过聪明的网友似乎又找到了其他的办法。

其实你可以在应用商店中找到多个Garmin的APP，原本我们只要用左边这个就可以了，但是不知道为什么Garmin又搞了右边那个出来，而右边那个仅仅具备商店的功能而已。不过这就刚好成为了我们的备选之策，现在如果通过右边那个APP来同步表盘设置，是OK的！

好了，今天的文章就写到这里，其实用一句话就能讲清楚的事情，哈哈！

这段时间矿难不断，于是网上多了很多蜗牛星际的机器，虽然做工很渣颜值很烂，但是可玩度颇高。我在纠结了很久之后，最后还是买了一台…群晖。是不是很意外，其实到后来是自己懒得折腾，想着还是以安全可靠作为第一要素。

因为是副数据中心，就无所谓安全和冗余的问题了，出于空间和功耗的考量我选择了单盘的机器。在闲鱼逛了很久，终于一天找到一台还算不错的DS116，于是就下手购入了。这台DS116采用的是Armada385的1.8G双核处理器，同样的处理器也被用在了DS216(1.3G),DS218J(1.3G)等产品上面，而且这台DS116拥有傲人的1G 内存，虽然不知道内存多了对性能又多少改进，但是至少看着爽嘛！基本上来说，DS116已经是群晖Armada385处理器的极限了，再后来就改用了Realtek RTD1296的处理器了。当然这些处理器相对于X86的处理器都是渣渣，不过只是说堪用而已。

为了这个新的NAS，我拆掉了一块之前的Seageat Backup Plus Hub，里面是一块8T的希捷酷鱼硬盘，原来想无损拆卸的，但是因为做工太好直接让我暴走了，一阵操作猛于虎，硬盘出来了，盒子也算是废了。接下来遇到了另外一个大问题，就是怎么把原本在这块8T硬盘里面的数据挪走，我一下子家里找不出那么多的剩余空间，于是只好带去单位，整整花了一天的时间，终于将硬盘清空，放入机器进行初始化了。

说了这么一大堆废话，下面开始进入主题。群晖的备份有好几种方式，在我之前的那台218+上面，我启动了两个备份服务，一个是用于公有云盘的备份服务Cloud Sync，用来将我的dropbox和onedrive同步到群晖上面，另外一个就是Glacier Backup，这是用来将我的部分个人数据同步到Amazon Glacier上面去。

而在我的副中心上，其实没有必要全面同步我主数据中心的所有数据，但是同样要考虑部分数据的备份和一致性。所以，除了和主数据中心一样启动了Cloud Sync来进行公有云的同步服务之外，还要启动一个服务来实现两台群晖之间的数据同步。在系统的APP里面，有好几个应用看起来都很相似，所以我当时一脸懵逼，接下来我直接和大家说结果就好了。

我选用的是Cloud Station ShareSync这个程序来进行同步，而在我的主数据中心，需要启动一个Cloud Station Server，不过恶心的是这个Cloud Station Server 和那个Drive的程序是互斥的，为了使用这个Server，只能将那个Drive的程序给卸载了。反正我也不怎么用。

在主机上配置好Station Server，指定同步目录即可。在客户机上通过QuickConnect ID进行连接，然后根据自己的需要来选择要同步的目录，同时选择同步方式，包括双向同步和单向同步。我的建议是，软件类的服务可以采取双向同步，而个人数据类则可以选择单向同步，确保数据的单向流动，从而确保不会因为副中心的问题导致主中心的数据发生损毁。

等一切配置完成之后，选择同步就可以交给群晖自己去跑了。不过现在电信提供的网络，虽然达到了1000M下行，但是上行还是苦逼的30M，我同步了一天都没有什么进展，一怒之下，我就带了硬盘直接过去拷贝了！哈哈哈！

基本就是这样了，然后要说一下群晖还提供一个叫做Hyber Backup的应用，这个应用也可以对多个群晖之间进行同步，不过它采用的是计划任务的方式，就有点像那个Glacier的意思，而我现在使用的这个ShareSync则是双向实时同步，所以还是建议大家选择这个。不过Hyber Backup可以用于多个公有云之间的备份，你可以这么理解，Hyber相当于前面Cloud Sync和这个StationSync的定时任务版就对了。

好了，今天要写的就是这么多，因为内容文件实在是太多，即便是我拷贝到了本地，仍然需要漫长的时间来进行两台机器之间的文件校验，我可以明显的看到现在正在校验的过程中，因为现在DS116上面的CPU负载增加，但是网络带宽基本纹丝不动。如果是下载的话，网络带宽能妥妥的跑满30M 就是了。

这两天丧心病狂的买了快30T的硬盘，应该可以安稳一段日子了。

之前我们说到了群晖买软件送硬件。正因这样，所以要把它的软件功能充分的运用起来。虽然新版本的Synology Drive功能实现了基本上私有云盘的所有功能，但是很多时候，我们还是希望能将现有的云盘和群晖服务器进行有效的同步。之前我用的很多收费云盘，最后还是用回了最初选择的Dropbox，虽然空间小一点，但是同步效率非常高。

所以，接下来我们就来说说如何实现群晖和Dropbox的同步，前提是你的群晖服务器可以访问到Dropbox的相关资源就可以。但是这一点在国内，就显得没有那么容易了。下面的措辞我尽量含蓄一些，大家听明白就好。

首先，我想在群晖上安装酸奶机客户端，但是网上的资料中，大部分都是酸奶机服务器的安装Docker，单独的客户端反而没找到。因为所有的机器都已经升级到R版本，所以这个方法就先没走通。

然后，那就只能在出口路由上设置酸奶机了。我一直在家庭网络环境中选择终端配置而非路由配置的原因，是因为手头有多台酸奶机，在终端上配置可以快速进行切换，而在路由上配置的话，更新切换起来会比较麻烦。于是，我就把最稳定的一台配置到了路由器上，并将路由器设置为功夫模式。于是乎，Cloud Sync就顺利的运行了起来。

问题接着又出现了，就是在手工暂停之后，再启动同步的时候，系统可以有效实现同步，但是在日常10秒轮询的时候，一直会显示连接中，而无法同步。肯定是某个地址设置有问题，在网上找了一圈，的确找到了说明。但是我根据说明将 *dropbox*.com配置到列表当中，依然搞不定这个问题，于是乎我一气之下，将路由器模式设置为国内白名单模式，对于所有国外网站启用代理，这下马上就好了。

也就是说，某些地址列表并没有被酸奶机归类进来而已，其实这种方式，通过抓包的方式是可以捕获到的，不过我早上一直在远程操作，懒得抓包了。不过也正因为如此，我后来修改了路由器上的配置，仅仅对于这台群晖启用白名单模式，而其他所有终端设置为直连。这样的话，可以有效减轻路由器的负担就是了。

随后，把Cloud Sync的同步频率从10秒降低到3600秒（一小时），毕竟没有那么实时性的同步需求，这样的话，就算全部搞定了。