目前的优化的话，我能想到的就是类似于 Duplicati（某备份工具），他也是增量备份，他的逻辑是

1. 第一个文件：把元数据的一些映射关系做了信息映射；
2. 别的文件就是加密后的元数据，同样也是进行了分片，但是他多了一个步骤，就是

压缩，我觉得这个压缩很有搞头

3. 每次增量备份，只多备份新的修改的元数据对照和压缩的元数据

他这个备份工具也支持加密，也是一样的，我个人体验同步速度算快的，毕竟他压缩的大小能指定，比如说 650MB（CD 大小），元数据足够大的话，就会有很多的 650MB 的压缩包，上传起来比思源现在的上传小文件肯定会快很多；

然后就是映射关系，他本地也有一个数据库，保存的是映射关系和日志，相当于是缓存，可以删因为云端也有，这种同步的话，除了第一次同步这个日志数据库慢点，其余时间都比思源快很多。

加密上传后的的目录：能看到精简了很多

随便说两点，第一，你拿 ob 的 livesync 实时同步来比较，并不恰当，因为 livesync 的同步是挂在服务器上，其本质就跟你部署在 docker 上，访问网页应用类似；

当然，这并不是思源同步慢的真正原因，真正的原因是：

1. 可能存在线程或者文件并行同步的数量限制；
2. 加密，你应该考虑思源是加密了的，也就是说存在类似于 Cryptomator 那样的加密措施，导致文件和文件夹众多，可以直接在对象存储平台查看加密后的文件夹就会发现非常多
3. 文件和文件夹的深度和数量都会极其影响同步、复制等速度，这个使用过 npm 以及复制 jar 包的同学应该都深有体会

我目前每次同步的速度大概在 3s 左右，如果有重大改变，可能会在十几秒左右，但是我觉得这个同步速度其实还好，因为有个 30s 自动同步的机制，所以我平时也很少手动同步，但是每次启动的时候的加载才是让我头痛的，每次都要等待封面，这个有点无语。

你如果非要对比的话，应该对标是 ob 的 remotely save 插件，记得加上加密，其次，ob 的该插件似乎不会分割文件，所以还是有一定的区别，但是会比你说的 livesync 更接近对比效果。

如果说解决的话，你要么就不用思源的官方同步，直接用三方同步工具同步 data 文件夹，这个也是可以的，我尝试过，只是不优雅。或者说用 docker 部署，这个优雅，但是只能用浏览器访问。

语法中说明了的，如果你需要打出这些 markdown 中的编码字符，请先打个转义字符反斜杠，再打你需要的字符。比如你说的*就是打

\*

就 ok 了

ok，已添加。可能是思源客户端的问题，那张图片也是本地的，可能是被替换后出现了异常。

s3 成本低，最方便，webdav 国内没有好的服务提供商，不建议，如果是自己搭建，可以使用。docker 主要是方便网页 web 访问，但是不能客户端同步，所以看你自己需求。

这里的意思是，服务器部署了，再配置 s3，保证数据有备份，增加数据丢失容错。

请参考我这篇文章 docker 部署思源（超详细） ，宿主机目录映射到容器的目录上，然后将 workspace 的目录设置成映射的容器这个目录，之后使用相同的命令就可以了。由于数据是映射在宿主机上的，数据持久化了。