记一次数据恢复的“一地鸡毛”

前情提要：

丢文档了，问题很严重，现在头很大，日后该怎么用有些迷茫

多设备数据同步导致数据回滚后的事故后，终于找回了一些关键文档

但恢复体验“一地鸡毛”

设备信息

这次问题的背景是两台 Win 主机，台式机主力，剩下笔记本电脑

笔记本 XPS 15 Windows 11，手攒的台式机 Windows 10

基本背景

最近为了防止笔记本版本跟不上，都是主动更新了笔记本到最新版

就是因为担心笔记编辑会担心扰乱历史记录，就故意没有打开任何笔记窗口

本打算笔记本就是同步一下最新数据就行可以的

结果下午回到台式机前，发现少了几个关键文档，再仔细一看昨晚整理移动的文档也都出来了，脑子瞬间大了

着急之下翻找历史记录，也没有看到，于是发帖

上传日志后 D 说是两台设备数据相互覆盖了，历史里可以找到

我当时就诧异了，因为近期我的笔记本电脑绝对没有编辑过，数据同步版本不可能超越台式机的

欢乐一刻

说到这里插播一个乐子，D 当时回复我的一个问题时，堪称“太极”典范，哈哈哈哈

D：根据你的日志是多设备覆盖了，你在历史数据里面找找，没找到是不是看错笔记本了？（大意如此）

我：可是我的笔记本最近就没编辑过啊，笔记本的版本号也不可能超过台式机的，难道是老的版本号可以覆盖新的版本号吗

D：云端的版本号理论上肯定是最新的，如果设备上比云端新就会执行上传到云端覆盖，如果设备上比云端旧就会执行下载覆盖本地。

这个回答妙啊，好像说了什么，明明又什么问题都没有解决

就好像

测试：这个现象是不是个 bug?

开发：理论上我的逻辑应该是这样…这样…的

测试：那你说这是个啥…

恢复之旅

不过恢复数据优先，终于在仔细查找后，找到了文档

然后就是恢复过程了，可惜自动恢复体验基本等于“没法用”的状态

这次涉及两个笔记本

• Daily 笔记本

  • 涉及 30 多个文档，最终恢复了 1 个，剩下的放弃
  • 剩余的因为当时涉及格式调整，以及位置移动，就没法恢复，也找不到恢复的点，因为历史文档没有路径，又要分清哪个是最新版本，这个过程很麻烦

• Resource 笔记本

  • 据说有 4000 多文档，这也是重建索引时间过长的原因
  • 历史记录里面涉及了 50 多文档，最近的涉及 8-9 个文档
  • 系统恢复 3 个最近文档，6 个手动复制文本重建恢复
  • 剩余 40 多个无力恢复

恢复期间遇到的问题

1. 每次只能恢复一篇文档
2. 每次恢复都会重建整个索引
3. 每次重建后，数据都会进行数据同步
4. 同步就会长时间阻塞大部分关键操作

有两个有关的不可抗因素

1. 笔记本太大，Resource 在日志的 count 值有 3000 多
2. 租房免费的 移 动 宽 带，每次同步都在 20s~30s 之间，凡同步必阻塞

也就是每恢复一篇文档就是 10s 查找，90s 重建索引，20s 同步阻塞下一次恢复，最少耗时 2 分钟

在恢复以上流程恢复了两三篇文档，心态崩溃后，果断选择将文本数据复制到 vs code 里，等待手动重建

最终因为自动恢复没法用，手动复制太麻烦，所以还是放弃了剩下的一些日记文件的拯救

“数据历史”功能难用

1. 笔记本选择不够直观
2. “数据历史”页面无法搜索，一点一点找，效率十分低
3. 恢复多个文档无法自动化，单个恢复时间长，也不方便
4. 恢复的数据有些不能回到原来的文档下，只能回到原来笔记本
5. 没有文档的“生前”路径
6. 恢复完就跳到主界面了，如果要恢复的文件很多，又不另找一个笔记软件记录情况下，就很容易忘记刚才恢复什么，哪些恢复了，还剩哪些没有恢复，也没有标记，也没回文档位置记忆

想起前几天更新，有一个“根据设备 ID 进行 diff”节省流量

联想到另一个“改进桌面端获取系统 ID 方式”

然后我就看了看 /data/.siyuan/conf.json 里面的 device，发现两台机器的设备 ID，竟然是一样的

我辗转反侧，这俩怎么算都不应该一样吧，设备不一样，系统也不一样

他俩一样有啥意义呢？会不会可能就是这个原因？

我有理由怀疑，但我没有证据…

那以后敢不敢再更新笔记本上的了呢…

想提点改进建议，可这也不知从何说起…

我想这应该是一场“完美风暴”的…

至此，今日的“一地鸡毛”落下帷幕