前情提要：
多设备数据同步导致数据回滚后的事故后，终于找回了一些关键文档
但恢复体验“一地鸡毛”
设备信息
这次问题的背景是两台 Win 主机，台式机主力，剩下笔记本电脑
笔记本 XPS 15 Windows 11，手攒的台式机 Windows 10
基本背景
最近为了防止笔记本版本跟不上，都是主动更新了笔记本到最新版
就是因为担心笔记编辑会担心扰乱历史记录，就故意没有打开任何笔记窗口
本打算笔记本就是同步一下最新数据就行可以的
结果下午回到台式机前，发现少了几个关键文档，再仔细一看昨晚整理移动的文档也都出来了，脑子瞬间大了
着急之下翻找历史记录，也没有看到，于是发帖
上传日志后 D 说是两台设备数据相互覆盖了，历史里可以找到
我当时就诧异了，因为近期我的笔记本电脑绝对没有编辑过，数据同步版本不可能超越台式机的
欢乐一刻
说到这里插播一个乐子，D 当时回复我的一个问题时，堪称“太极”典范，哈哈哈哈
D：根据你的日志是多设备覆盖了，你在历史数据里面找找，没找到是不是看错笔记本了？（大意如此）
我：可是我的笔记本最近就没编辑过啊，笔记本的版本号也不可能超过台式机的，难道是老的版本号可以覆盖新的版本号吗
D：云端的版本号理论上肯定是最新的，如果设备上比云端新就会执行上传到云端覆盖，如果设备上比云端旧就会执行下载覆盖本地。
这个回答妙啊，好像说了什么，明明又什么问题都没有解决
就好像
测试：这个现象是不是个 bug?
开发：理论上我的逻辑应该是这样…这样…的
测试：那你说这是个啥…
恢复之旅
不过恢复数据优先，终于在仔细查找后，找到了文档
然后就是恢复过程了，可惜自动恢复体验基本等于“没法用”的状态
这次涉及两个笔记本
-
Daily 笔记本
- 涉及 30 多个文档，最终恢复了 1 个，剩下的放弃
- 剩余的因为当时涉及格式调整，以及位置移动，就没法恢复，也找不到恢复的点，因为历史文档没有路径，又要分清哪个是最新版本，这个过程很麻烦
-
Resource 笔记本
- 据说有 4000 多文档，这也是重建索引时间过长的原因
- 历史记录里面涉及了 50 多文档，最近的涉及 8-9 个文档
- 系统恢复 3 个最近文档，6 个手动复制文本重建恢复
- 剩余 40 多个无力恢复
恢复期间遇到的问题
- 每次只能恢复一篇文档
- 每次恢复都会重建整个索引
- 每次重建后，数据都会进行数据同步
- 同步就会长时间阻塞大部分关键操作
有两个有关的不可抗因素
- 笔记本太大，Resource 在日志的 count 值有 3000 多
- 租房免费的 移 动 宽 带，每次同步都在 20s~30s 之间，凡同步必阻塞
也就是每恢复一篇文档就是 10s 查找，90s 重建索引，20s 同步阻塞下一次恢复，最少耗时 2 分钟
在恢复以上流程恢复了两三篇文档，心态崩溃后，果断选择将文本数据复制到 vs code 里，等待手动重建
最终因为自动恢复没法用，手动复制太麻烦，所以还是放弃了剩下的一些日记文件的拯救
“数据历史”功能难用
- 笔记本选择不够直观
- “数据历史”页面无法搜索，一点一点找，效率十分低
- 恢复多个文档无法自动化，单个恢复时间长，也不方便
- 恢复的数据有些不能回到原来的文档下，只能回到原来笔记本
- 没有文档的“生前”路径
- 恢复完就跳到主界面了，如果要恢复的文件很多，又不另找一个笔记软件记录情况下，就很容易忘记刚才恢复什么，哪些恢复了，还剩哪些没有恢复，也没有标记，也没回文档位置记忆
想起前几天更新，有一个“根据设备 ID 进行 diff”节省流量
联想到另一个“改进桌面端获取系统 ID 方式”
然后我就看了看 /data/.siyuan/conf.json 里面的 device，发现两台机器的设备 ID，竟然是一样的
我辗转反侧，这俩怎么算都不应该一样吧，设备不一样，系统也不一样
他俩一样有啥意义呢？会不会可能就是这个原因？
我有理由怀疑，但我没有证据…
那以后敢不敢再更新笔记本上的了呢…
想提点改进建议，可这也不知从何说起…
我想这应该是一场“完美风暴”的…
至此，今日的“一地鸡毛”落下帷幕
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于