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

本贴最后更新于 684 天前,其中的信息可能已经东海扬尘
前情提要:

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

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

但恢复体验“一地鸡毛”

设备信息

这次问题的背景是两台 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,竟然是一样的

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

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

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

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

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

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

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

  • 思源笔记

    思源笔记是一款隐私优先的个人知识管理系统,支持完全离线使用,同时也支持端到端加密同步。

    融合块、大纲和双向链接,重构你的思维。

    18130 引用 • 66881 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • 心疼楼主 1S

    改进建议的话, 提供两种历史恢复方案?

    1. 回滚单篇文档
    2. 回滚整个工作区到某个时间点
  • 其他回帖
  • 给你带来不便非常抱歉,这个问题我们后面会继续收集反馈看能否确认。

    数据历史功能后续再改进一下,向 @shuoying 提到的按时间点批量回滚应该能做到,先记录 Issue #4889 · siyuan-note/siyuan,尽量按原路径回滚应该也能做到 Issue #4890 · siyuan-note/siyuan,其他改进点暂时不行,后面再考虑,谢谢。

    最后你提到 device 相同的情况是正常的:新下载到数据后,/data/.siyuan/conf.json 里的 device 是和云端的一样的,但本地数据变更后会自动更新为当前设备的 ID。

    1 回复
  • rumengsiji

    有重复的 ID,目前的问题是我四月的笔记确实恢复了,但是我在文档树里找不到他的存在 😂。

    1 回复
  • rumengsiji 1

    恢复了,记录一下恢复过程。

    首先最重要的是不要慌 😳。我发现文档树里的笔记本和 data 里前缀是时间戳的文件夹数量是一致的。

    1. 所以,首先我先把我现存的数据复制一份打包留存做个备份,及时止损。
    2. 然后打开思源新建一个笔记本,此时对应文件夹里将多一个以时间戳前缀的文件夹。
    3. 我是 8:45 分丢失的数据,于是我在 history 找对于 8:45 时间点前一两个文件夹,我 8:45 前 history 里有个 8:39 的文件夹。
    4. 我将 history 里 8:39 之后每个时间段的文件夹都一一打开,将里面每条数据都复制到我的新笔记本对应的文件夹。由于我们不知道文件夹里哪条数据对应着我们想要的数据,所以我们只能通通恢复了。
    5. 打开思源笔记,数据就回来了。但是还是遇到 bug 了,这里需要 @D 大解决一下。看 gif 图
    6. 动画.gif
    1 回复
  • 查看全部回帖