最近我看到一种与网盘协同使用来实现 Obsidian 笔记同步的方案，选择使用 Remotely Save 插件来同步 Obsidian 笔记。
恰好我的 Obsidian 仓库由于已经达到了近 2GB，导致首次拉取到本地时出现困难。于是我在“拆分仓库”和“更换同步方式”之间做了一些研究。决定尝试一下用 Remotely Save 插件进行同步。
这篇文章不完全是一篇使用教程，因为插件的配置非常简单，我更想聊聊使用这款插件的实际感受。
我把当前仓库复制了一份，删去了与 Git 有关的目录，作为一个全新的库配置了这款插件，以便更好地模拟真实的使用场景。
安装步骤
插件配置很简单，远比 Git 方案容易配置得多，这是我的第一感受。
你需要按以下步骤进行操作。
- 备份现有仓库（这很重要！）
- 在商店中搜索 Remotely Save 安装插件。
- 同意免责声明。
- 在插件配置中选择合适的同步协议，添加配置。
- 在配置好的设备上，导出配置代码。
- 在另一台设备上，导入配置代码。
这样即可完成最基本的配置，并且在两台设备上实现笔记同步。
在这些步骤中，需要注意的是“选择同步协议”这一步。
Remotely Save 支持的协议很丰富，它支持了 S3、Dropbox、OneDrive 个人版、WebDAV、Webdis 这几项同步协议。如果为插件付费，还可以再解锁 Google Drive、Box、Yandex Disk 等其他网盘。
其中的 WebDAV 和 S3 协议都是可以自己在 NAS 上部署的，也有不少网盘和服务商支持这两种协议。可以实现完全免费的同步。因此还是很有吸引力的。
以我自己为例，我用的同步方案是在 NAS 上部署了 minio 服务，minio 可以提供 S3 同步功能。你也可以选择部署一个 Alist 服务，来更便捷地开启 S3 服务。而我选择使用 S3 同步的理由是，S3 相比 WebDAV 同步有更好的性能表现。因为 S3 支持多并发同步，还可以降低同步的错误率。
如果你只有 WebDAV，那么直接使用 WebDAV 服务也是可以的。其他的公有云服务如 OneDrive、Dropbox 我暂时没有测试。但考虑到网络速度、代理、公有云本身的限制，应该是远不如自己部署的服务的，所以应该能探索到这款插件的上限。
优点
接下来我觉得可以分为“优点”和“缺点”两个部分来讲讲使用感受。
配置极其简单
这个插件配置起来很简单，手机端也能很轻易地完成配置工作，更符合常规用户的使用习惯。比 Git 方案简化了很多。
Git 的配置相对复杂，不了解 Git 的朋友在首次配置的时候多多少少遇到一些问题。而且手机端也很不容易配置 Git 服务。
同步很直观
插件的同步按钮很直观，点击一下按钮就可以同步。如果你同时配置了 5 分钟自动同步一次，那么同步体验就像 Evernote 那样，使用起来还是非常容易的。
这比 Git 方案下的 Control View 要容易理解很多。
无需考虑图片和文件问题
Git 方案的一个问题是，关于图片和大文件的处理不够好。你需要通过启用 Git LTS 来解决这个问题，这进一步增加了 Git 方案的复杂性。
而 Remotely Save 插件本身就是基于文件同步的，你可以方便地实现图片和文件的同步。在手机上可以选择“忽略大文件”来避免把过大的文件同步到手机端。
端到端加密
Remotely Save 支持端到端加密，你只需要配置一个密码，同步到云端的文件无须担心文件被第三方网盘窃取和审查。
不必手动处理冲突
Remotely Save 插件免费版中，提供的是基础的处理冲突功能。提供了付费的智能处理冲突的功能。
基础的处理冲突功能是什么意思呢？就是简单用“编辑时间”来判断，以最新的一次更新为准。覆盖所有老的更新。
这种自动处理，在多数情况下也够用了。
但你需要防止在同步完成前更新文件，否则其他设备上的文件可能会被你的最新操作给覆盖。比如你在 PC 上更新了文件并进行了同步。然后马上拿起手机修改了一些内容。然后在手机端触发同步，这时候你会发现 PC 上做的修改丢失了。因为手机的修改时间是最新的。
顺着这个话题，我就要讲讲它的缺点了。
缺点
直到我发掘完了上面这些优点之前，我都差点认为这是一个全方面优于 Git 的方案。
但在我深入使用 + 实际评估了一段时间后发现，其实这个同步插件还是存在不少问题的。
无法同步配置
Remotely Save 插件目前无法同步配置。
下面这段话摘自插件的文档原文：
By default, all files or folder starting with
.(dot) or_(underscore) are treated as hidden files, and would NOT be synced. It's useful if you have some files just staying locally. But this strategy also means that themes / other plugins / settings of this plugin would neither be synced.默认情况下，所有以 .（点）或
_（下划线）开头的文件或文件夹都被视为隐藏文件，并且不会被同步。如果你有一些文件只需保留在本地，这个功能会很有用。但这种策略也意味着主题、其他插件或此插件的设置都不会被同步。
即使启用了最新的实验性质功能“同步配置文件夹”，仍然无法无法同步大部分的插件配置。
In the latest version, you can change the settings to allow syncing
_files or folders, as well as.obsidianspecial config folder (but not any other.files or folders).在最新版本中，你可以更改设置，以允许同步
_文件或文件夹，以及 .obsidian 特殊配置文件夹（但不包括其他以 . 开头的文件或文件夹）。
这导致很多插件在同步完成后，需要在新的设备上全部重新配置一遍，比如与模板有关的设置、主题有关的设置等等。最容易忽略的一个配置是“文档和附件默认存放的位置”，这会导致我添加的新图片默认放到根目录下，很是烦人。
所以，每次在新设备上配置的时候，都需要手动操作一下所有的插件配置，如果忘记配置某个插件，就要忍受错误配置带来的后果。这让我难以在所有设备上保持完全一致的工作环境。
作为对比，Git 同步方案可以完整同步 Obsidian 插件、插件的配置信息。
难以看到数据的变动情况
Git 能够记录历史版本这个优点，也许有人会觉得这个对自己意义不大。哪怕是我，也很少经常翻看一个文档的历史记录。
但当 Remotely Save 插件出现同步冲突的时候，我又发现无比需要这个功能。
因为一旦“自动判断冲突”导致丢失了数据，我都无法明确鉴别到底是哪一步数据出现了不同步。也无法确定到底丢失了哪些文件。只能硬着头皮稀里糊涂地继续用下去。直到某一天凭记忆发现丢了些文字甚至文件。
而在 Git 方案下，关于处理冲突有一套很完善的机制，如果出现了较多的冲突，你需要手动处理这些冲突后才能进行后续操作。不会自作主张用“最新数据进行覆盖”导致数据丢失。
无法正确识别对于文件的操作
这其实是上一个问题引申出来的问题。
举个实际的例子，当我在 PC 端删除或者移动 A 文件后执行同步，此时云端没有 A 文件了。
但如果此时我在手机端再次操作了一下 A 文件（比如查看时点到一下属性，Obsidian 也会认为是进行了修改，会更新修改时间），插件会认为这个文件被更新了一下，又将这个文件上传到云端了。
这就导致“你认为的删除操作，其实没有生效”、“你认为的查看操作，导致了被删除的文件再次被上传”。这对于追求文件一致性的笔记工具来说，是相当致命的问题。
与 Git 方案无法兼容
在这个问题的基础上，可能有人会认为，“同时使用 Git 和 S3 同步不就解决问题了吗？”
首先，我写过一篇文章专门讨论过这个问题，关于为什么不要同时用两种同步方案——
其次，Remotely Save 插件与 Git 方案不兼容，官方文档中明确提到“插件会自动创建一个 .gitignore 文件”并且“不会同步除了 .obsidian 目录以外的隐藏文件，包括 .git 目录和 .gitignore 等文件”。因此不建议在仓库中建立 git 结构。
文档原文如下：
It's usually NOT a good idea to check the file into version control. By default, the plugin tries to create a
.gitignorefile inside the plugin directory if it doesn't exist, for ignoringdata.jsonin thegitversion control. If you know exactly what it means and want to remove the setting, please modify the.gitignorefile or set it to be empty.通常来说，将该文件检入版本控制并不是一个好主意。默认情况下，该插件会尝试在插件目录内创建一个
.gitignore文件（如果该文件不存在），以在git版本控制中忽略data.json文件。如果你确切知道这样做的含义，并且想要移除这个设置，请修改.gitignore文件或者将其设置为空。
大仓库同步时间较长
这个问题也许不是每个人都会遇到。但如果仓库较大，还是挺影响体验的。
比如我有 4000 个文件，点击同步后，需要持续同步约 1 分钟左右，才会开始同步第 4001 个文件。这说明前面的 1 分钟是在校验现有的文件是否有变化。然后再开始继续同步新增的文件。再结合上面提到的情况。我在这 1 分钟里完全不敢做任何操作，生怕影响到数据一致性。 所以几乎就没有同步的必要了。如果我一定要在手机上做同步，我可能更愿意选择开一个小一点的仓库单独同步。
Git 则是根据每次的变动，增量同步新文件。
种种缺点，导致我个人在提心吊胆地用了一段时间 Remotely Save 后，最终还是回归到了 Git 同步方案下。（我很庆幸当初是用了仓库的副本进行的插件测试，而不是直接在原仓库上测试。）
至于在 Git 仓库变的过大时怎么处理，我更愿意选择拆分当前仓库、分离附件文件夹来解决这个问题。后期我会写一篇文章来介绍如何使用自建的 S3 存储来分离。
小结
考虑到 Remotely Save 插件是一款社区自制的插件，它能够在 Obsidian 现有的插件框架下实现“同步”本身就已经很了不起了。
虽然上面提到了很多缺点。但瑕不掩瑜，Remotely Save 这个插件确实能够很好的解决 PC 和手机端同步的问题，能够实现不借助外部工具，仅在 Obsidian App 内自动同步，这是 Git 方案无法实现的。尤其对于 Android 用户而言，相比想方设法去解决 Git 同步的问题，远不如直接用一个 Remotely Save 来的简单。
我还是很推荐大家去试试这个插件的，也许能够解决很多人一直以来关于 Obsidian 同步的困扰。
如果担心文中提到的数据覆盖问题，我的另一个建议是，新开一个同步 Obsidian 仓库，专门用于与手机的同步，从而避免影响到现有的大型仓库。