什么情况?!思源也丢失笔记???

昨天整理笔记,发现自己写的个人文章大概十几篇不见了,父页面插入的目录,可以看到子页面的标题,也就是我的文章的标题,但是,鼠标放上去,提示“未找到 ID 为.......的内容块”。

本以为是自己误删除了,但是想一想,父页面都还在,父页面下面的十几个子页面自己误删除的可能性太小了。心痛,还是以为是自己的操作问题。

今天再打开软件整理,发现另外一个笔记本下面的一个父页面,父页面下面的子页面又不见了,只在父页面里面能够看到插入的目录(即文章标题),大家可以看截图。鼠标放上去,提示“未找到 ID 为.......的内容块”。

这种情况不可能是误删除!但是什么情况导致的文章丢失,我也不知道,我用了十多年的为知笔记,今年开始用的思源笔记。

快照的话之前清理过一次,因为思源软件提示“快照过多建议删除已提高速度”等提示,我当时就执行过一次快照删除,所以文章什么时候丢失的我也不知道,平时每天不可能检视所有文章在不在,只有隔一段时间整理归纳。

关键是有十几篇文章是自己一个一个字敲打出来的感悟。

  • 思源笔记

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

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

    20153 引用 • 77705 回帖 • 2 关注

相关帖子

优质回帖
  • zxhd86 2 赞同

    那我觉得最好是改进一下快照保存策略,依照快照距今时间,近的每天,远一点的每个星期,再远一点每个月分级保存,一年以上再完全撤销,而不是简单的删除了事。

  • 88250 1 赞同

    你提到的数据同步稳定性的两个方面(数据损坏和数据丢失),就目前我们收集到的用户反馈和官方云端存储检测报告来看,数据损坏的问题比例已经非常低,并且还在继续降低,已经确认呈现收敛趋势;数据丢失的问题近期出现在 Android 14 上,新版本上线时间较短,还需要时间观察是否彻底解决。

    另外,同步功能和备份功能是有区别的,同步功能主要是为了数据同步,所以只提供非常有限时间的数据历史,如果需要较长时间的数据历史,应该使用备份功能。

    将云端数据对象实际占用作为云端存储占用大小的话对于用户来说是不公平的,因为实际上从同步的角度考虑,只有最新快照是有用的,这也是上面提到数据同步的使用场景。

  • openAI 1 赞同

    还是我之前说的那个方案来避免快照过多,逻辑很简单,取并集,同时保留最近 N 个快照和最近 M 天的快照。

    这样即防止快照过多,又防止快照时间久远被删除。

    现在完全根据时间来保留快照会出现的问题就是,如果用户长时间不写笔记,不打开软件,那云端的快照直接清零了。

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...
  • lbdoc

    2.png

    1.png

  • powehi

    什么版本呀,有一个排查方法:看云端快照,比较两个快照的差异,看一下是哪个客户端出了问题,我这边也会遇到问题,多看看吧,并且可以多看看设置里面的资源存不存在没有引用的,发现的话及时回滚,我这边的问题是出在移动端

    1 回复
  • lbdoc

    补充一下:我使用的是思源官方的同步方式

  • lbdoc

    云端快照清理过一次。我也不知道是清理之前出的问题还是清理之后。回滚的话刚试了一下,还是没有,截图的丢失了 4 篇,这些是摘录,丢了就算了,关键是还有个页面下面有 10 几个子页面,是我自己写的读书感悟,这真.......

    我已经在看其他软件了。哎......焦人。

    1 回复
  • powehi

    也是,丢了笔记肯定糟心,可能恢复的概率比较小了,多做备份吧,之前听了一个老哥的建议,git、s3 双备份,更安全一些,

  • 88250

    请上传所有参与同步的设备日志,我们看看是否能找到问题,谢谢。

    1 回复
  • lbdoc

    马上上传。能得到您的回复也挺感谢。

    我现在不知道是清除快照之前丢失的还是之后。目前最早的快照是 1 月 29 号。我恢复过,笔记是丢失状态。头几天是操作过一个软件建议清除数据仓库清理的提示,就清除过一次,所以再早之前的快照没有。

    目前丢失的是页面都没了。而不是页面里面的内容。相当于一个文件夹(父页面)下面有几十或者上百的文档,而这个文件夹下面的所有的文档都没了,只在父页面看到各个子页面的标题.....。

    systemlog.zip

    1 回复
  • 88250

    从这份日志上看可能是因为 1 月 29 号同步 Android 端时删除了文件导致,这次同步时 Windows 端文件数为 6335,Android 端文件数为 6301:

    I 2024/01/29 15:10:36 ref.go:50: got local latest [device=b51c0846-0eb7-4f16-bb9f-2bb9a919fb36/windows, id=9de37ae703ca2af41a68e934efa0335d7e902fd8, files=6335, size=381 MB, created=2024-01-29 15:03:57]
    I 2024/01/29 15:10:36 repo.go:595: walk data [files=6335] cost [421.6098ms]
    I 2024/01/29 15:10:36 ref.go:50: got local latest [device=b51c0846-0eb7-4f16-bb9f-2bb9a919fb36/windows, id=9de37ae703ca2af41a68e934efa0335d7e902fd8, files=6335, size=381 MB, created=2024-01-29 15:03:57]
    W 2024/01/29 15:11:01 repository.go:1563: index data repo before cloud sync elapsed [25444ms]
    I 2024/01/29 15:11:01 ref.go:50: got local latest [device=b51c0846-0eb7-4f16-bb9f-2bb9a919fb36/windows, id=9de37ae703ca2af41a68e934efa0335d7e902fd8, files=6335, size=381 MB, created=2024-01-29 15:03:57]
    I 2024/01/29 15:11:02 siyuan.go:138: downloaded object [siyuan/1654744605978/repo/main/refs/latest]
    I 2024/01/29 15:11:02 siyuan.go:138: downloaded object [siyuan/1654744605978/repo/main/indexes/b917d8b6eeb90a12f4846f1d8503779558ebf579]
    I 2024/01/29 15:11:02 sync.go:1592: got cloud latest [device=revxpfuj5rsn/android, id=b917d8b6eeb90a12f4846f1d8503779558ebf579, files=6301, size=381 MB, created=2024-01-29 01:38:48]
    I 2024/01/29 15:11:02 siyuan.go:138: downloaded object [siyuan/1654744605978/repo/main/objects/3e/e28ee1518ae9dc191ece1738e569bc1aff9e00]
    I 2024/01/29 15:11:02 siyuan.go:138: downloaded object [siyuan/1654744605978/repo/main/objects/8f/0d561d5f65fb9b35474563c23b2de89ae494b3]
    I 2024/01/29 15:11:02 siyuan.go:138: downloaded object [siyuan/1654744605978/repo/main/objects/2d/f0ca3ab191b8c156ef5b50dd4614d59df0e4b8]
    

    随后在 15 点时进行过本地快照清理,这个不影响数据:

    I 2024/01/29 15:14:49 store.go:61: purging data repo [E:\思源笔记工作空间\SiYuan\repo\]
    I 2024/01/29 15:16:49 store.go:229: purged data repo [E:\思源笔记工作空间\SiYuan\repo\], [1646] indexes, [6095] objects, [114425448] bytes
    

    所以你说的数据丢失很有可能是同步 Android 数据快照的时候被删除的,请上传一下 Android 端日志以便进一步定位问题。

    目前可以考虑使用云端快照恢复看看,即在 数据历史 - 数据快照 - 云端快照 中找到 1 月 29 号 15 时 10 分之前的一个快照下载到本地,然后再到本地快照中回滚。

    1 回复
  • lbdoc

    找回来了,确实吓尿了。不知道怎么丢失的,一个页面下面几十个子页面,不可能是误删除,因为父页面还在,里面还有各个子页面的标题(插入目录插件生成的)

    个人写的感悟几十篇找回来了。还有个摘录的网上的资料,也不知道哪天的快照才能回滚回来,不找了。哎

    1 回复
  • lbdoc

    好的,马上操作。

  • 88250

    请上传 Android 端日志以便进一步定位问题,谢谢。

  • 多端同步,尤其是加入手机端后,确实容易出错。

  • lbdoc

    systemlogmobile.zip

    这是手机端的 log。

    应该不是 29 号的问题。我测试了很多个快照,一直到 1 月 15 日,才找回文章。

    1 回复
  • 88250

    麻烦发一下快照 ID。

  • 88250

    不好意思,不需要找快照 ID 了,通过日志已经能够确认问题了,这是 v2.12.4 之前出现在 Android 14 上的 bug:

    上个月 17 号发布 v2.12.4 后已经修复该问题 Issue #10205 · siyuan-note/siyuan

  • aronsept

    我的手机端只读、只下载、不上传,就怕同步太混乱

  • 确实会丢失, 我确信我丢了好多笔记, 但是忘记写在哪个目录, 什么时候丢的了. 但是看了 D 大描述刚刚找回来了..这种就怕不知道什么时候丢的, 找回来就很麻烦了, 得尝试各个云端时间点的快照

    1 回复
  • 88250

    你的也是 Android 14 吗?是的会请升级最新版。

    1 回复
  • @88250 快照的翻页能否优化一下, 云端 100 多页很难翻呀, 还有对比按钮能不能加个悬浮提示, 比如: 请选择标记的快照进行对比, 不然我说按钮怎么按不了, 快照也不能点选

    1 回复
  • 我的安卓 13, 刚查到是 10 月份丢的, 过于久远, 也懒得纠结什么问题了 😂

    1 回复
  • 88250

    云端快照后续不会保留那么多,可能最多只会保留最近一个月或者两周的。快照对比的交互暂时不动了,感谢反馈。

    1 回复
  • 88250

    好的,建议尽量保持使用最新版。

  • 这不是更糟了吗?现在是快照太多,想翻到数据不丢失的快照需要很多时间,减少保留数量后直接变成数据丢失了。

    我觉得治本的方案还是改进交互,如果暂时忙不过来那起码不动为妙。

    1 回复
  • 88250

    云端成本有限,只能保留一段时间的自动同步快照,如果需要长期保存,可以用标记快照。

    1 回复
  • zxhd86 2 赞同

    那我觉得最好是改进一下快照保存策略,依照快照距今时间,近的每天,远一点的每个星期,再远一点每个月分级保存,一年以上再完全撤销,而不是简单的删除了事。

    1 回复
  • 88250 1 评论

    最长保留时间估计最多只能做到 1 个月,1 个月里面再分的话意义不是太大了。

    1 回复
    取并集吧,最近 N 个快照和最近 M 天的快照都保留
    openAI
  • 但是官方订阅的快照策略要是保留期限太短的话,那就会显著差于自定义第三方同步了……在数据安全的保障上,标记快照是没有太大意义的,毕竟用户总是后知后觉数据损坏和丢失了。

    所以我的意思是,官方的优化方案尽量是在不压缩用户体验甚至提升体验的情况下进行的。如果实在不行,那可以在使用空间计算上把云端快照的实际占用也算上,让用户自己去控制云端快照空间的使用。

    自动删除 1 个月以上的云端快照,我觉得不到万不得已还是不要使用比较好。这可能是实现上最简单的方案,但可能同时也是最不受欢迎的方案。

    1 回复
  • 88250 1 赞同

    你提到的数据同步稳定性的两个方面(数据损坏和数据丢失),就目前我们收集到的用户反馈和官方云端存储检测报告来看,数据损坏的问题比例已经非常低,并且还在继续降低,已经确认呈现收敛趋势;数据丢失的问题近期出现在 Android 14 上,新版本上线时间较短,还需要时间观察是否彻底解决。

    另外,同步功能和备份功能是有区别的,同步功能主要是为了数据同步,所以只提供非常有限时间的数据历史,如果需要较长时间的数据历史,应该使用备份功能。

    将云端数据对象实际占用作为云端存储占用大小的话对于用户来说是不公平的,因为实际上从同步的角度考虑,只有最新快照是有用的,这也是上面提到数据同步的使用场景。

    2 回复
  • 数据损坏不仅仅包括软件问题造成的损坏,还有可能是用户误操作造成的损坏,软件自身的迭代最多解决前者,在这种情况下,一个长期的快照还是很有必要的。

    在这里,区分同步功能和备份功能没有太大意义,因为用户就是需要一个安全的,能从云端恢复长久历史文档的功能,而且不需要用户知道数据完整的情况下预先准备好这一份快照。无论你说他是同步功能还是备份功能,总之是需要这一个功能。以往来说,这个功能是在同步的云端快照里面提供了。假如以后不提供自动的长期云端快照了,实际上就是把这个功能给砍了。

    最后,关于这个公不公平,用户接不接受的问题,我觉得还是需要进行投票,问用户本身。

    2 回复
  • openAI 1 赞同

    还是我之前说的那个方案来避免快照过多,逻辑很简单,取并集,同时保留最近 N 个快照和最近 M 天的快照。

    这样即防止快照过多,又防止快照时间久远被删除。

    现在完全根据时间来保留快照会出现的问题就是,如果用户长时间不写笔记,不打开软件,那云端的快照直接清零了。

    1 回复
    1 操作
    openAI 在 2024-02-02 22:22:11 更新了该回帖
  • 88250

    支持长期的数据历史成本上无法控制,据我所知同类产品中也没有能够提供长期保存的(比如 Obsidian 对于资源文件仅提供两周的历史)。

    另外,数据安全不能仅靠云端,也需要用户自己养成定期备份的习惯,只有这样数据才能更可靠。

    说到底就是两点,第一,如果不计成本那一直保存就行,但我们不可能不计成本;第二,云端存储的可用性不是 100%,所以想依靠云端存储做灾难恢复并不可靠。

  • 88250 1 赞同

    可以考虑保留最近 1 个月并至少保留 7 个同步快照。

  • 我也丢文件了,因为丢的文件目前没发现特别重要的,最近又忙就没死磕去恢复。

    1 回复
  • 88250

    有空的话麻烦上传日志和反馈丢失的时间或者文件路径,我们排查看看。

    1 回复
  • xnyshu

    没有启用云端同步和备份功能的不会有这个问题吧?

    1 回复
  • 88250

    应该不会。

  • systemlog.zip

    日志已上传。目前发现是部分关联了数据库的文档不见了,具体什么时候丢的不确定,至少有一周。

    1 回复
  • 88250

    我搜索了 1 月 29 号到今天的日志,没有发现云端同步时删除文件,也没有发现 Android/iOS 端同步,所以可以排除最近 Android 14 的那个 bug 引起的丢失。

    因为快照比较多,所以只是大致扫了一下,从这段时间的快照中的文件数量看没有减少,只有增加,所以如果需要排查具体丢失的话请给一下快照 ID 或者文件路径,谢谢。

    1 回复
  • image.png

    路径涉及工作信息,不大方便发。目前发现是这些文档丢失,看插件显示的引用到这些文档的块最后编辑时间是十月了,所以不好说是什么时候丢的。

    比较奇怪的是前面同期创建的文档都还在,两者的区别是丢失的文档很久没编辑过了,保留的文档近期有编辑过。

    但是 1 月 17 号我引用了丢失的文档,当时还在,后来具体什么时候丢的我就不知道了。

    信息太少,损失也不大,下次如果遇到数据丢失我会及时导出日志再来反馈。

    1 回复
  • 88250

    好的,谢谢。

  • yikexiaoyao

    本地有记录吗,有的会顶多算上传文件失效或丢失,但是本地还能找回,本地要是也没有的话。那问题就大了

请输入回帖内容 ...

推荐标签 标签

  • 外包

    有空闲时间是接外包好呢还是学习好呢?

    26 引用 • 232 回帖
  • OAuth

    OAuth 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是 oAuth 的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此 oAuth 是安全的。oAuth 是 Open Authorization 的简写。

    36 引用 • 103 回帖 • 16 关注
  • etcd

    etcd 是一个分布式、高可用的 key-value 数据存储,专门用于在分布式系统中保存关键数据。

    5 引用 • 26 回帖 • 499 关注
  • Log4j

    Log4j 是 Apache 开源的一款使用广泛的 Java 日志组件。

    20 引用 • 18 回帖 • 22 关注
  • MyBatis

    MyBatis 本是 Apache 软件基金会 的一个开源项目 iBatis,2010 年这个项目由 Apache 软件基金会迁移到了 google code,并且改名为 MyBatis ,2013 年 11 月再次迁移到了 GitHub。

    170 引用 • 414 回帖 • 400 关注
  • Laravel

    Laravel 是一套简洁、优雅的 PHP Web 开发框架。它采用 MVC 设计,是一款崇尚开发效率的全栈框架。

    19 引用 • 23 回帖 • 702 关注
  • QQ

    1999 年 2 月腾讯正式推出“腾讯 QQ”,在线用户由 1999 年的 2 人(马化腾和张志东)到现在已经发展到上亿用户了,在线人数超过一亿,是目前使用最广泛的聊天软件之一。

    45 引用 • 557 回帖 • 162 关注
  • 心情

    心是产生任何想法的源泉,心本体会陷入到对自己本体不能理解的状态中,因为心能产生任何想法,不能分出对错,不能分出自己。

    59 引用 • 369 回帖
  • Bootstrap

    Bootstrap 是 Twitter 推出的一个用于前端开发的开源工具包。它由 Twitter 的设计师 Mark Otto 和 Jacob Thornton 合作开发,是一个 CSS / HTML 框架。

    18 引用 • 33 回帖 • 680 关注
  • 大数据

    大数据(big data)是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合,是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

    89 引用 • 113 回帖
  • Ant-Design

    Ant Design 是服务于企业级产品的设计体系,基于确定和自然的设计价值观上的模块化解决方案,让设计者和开发者专注于更好的用户体验。

    17 引用 • 23 回帖 • 3 关注
  • 深度学习

    深度学习(Deep Learning)是机器学习的分支,是一种试图使用包含复杂结构或由多重非线性变换构成的多个处理层对数据进行高层抽象的算法。

    41 引用 • 40 回帖
  • 博客

    记录并分享人生的经历。

    272 引用 • 2386 回帖
  • Jenkins

    Jenkins 是一套开源的持续集成工具。它提供了非常丰富的插件,让构建、部署、自动化集成项目变得简单易用。

    51 引用 • 37 回帖 • 3 关注
  • 链书

    链书(Chainbook)是 B3log 开源社区提供的区块链纸质书交易平台,通过 B3T 实现共享激励与价值链。可将你的闲置书籍上架到链书,我们共同构建这个全新的交易平台,让闲置书籍继续发挥它的价值。

    链书社

    链书目前已经下线,也许以后还有计划重制上线。

    14 引用 • 257 回帖
  • Kafka

    Kafka 是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 这种动作(网页浏览,搜索和其他用户的行动)是现代系统中许多功能的基础。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

    35 引用 • 35 回帖
  • ActiveMQ

    ActiveMQ 是 Apache 旗下的一款开源消息总线系统,它完整实现了 JMS 规范,是一个企业级的消息中间件。

    19 引用 • 13 回帖 • 641 关注
  • Spark

    Spark 是 UC Berkeley AMP lab 所开源的类 Hadoop MapReduce 的通用并行框架。Spark 拥有 Hadoop MapReduce 所具有的优点;但不同于 MapReduce 的是 Job 中间输出结果可以保存在内存中,从而不再需要读写 HDFS,因此 Spark 能更好地适用于数据挖掘与机器学习等需要迭代的 MapReduce 的算法。

    74 引用 • 46 回帖 • 556 关注
  • 倾城之链
    23 引用 • 66 回帖 • 121 关注
  • RabbitMQ

    RabbitMQ 是一个开源的 AMQP 实现,服务器端用 Erlang 语言编写,支持多种语言客户端,如:Python、Ruby、.NET、Java、C、PHP、ActionScript 等。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗。

    49 引用 • 60 回帖 • 395 关注
  • 宕机

    宕机,多指一些网站、游戏、网络应用等服务器一种区别于正常运行的状态,也叫“Down 机”、“当机”或“死机”。宕机状态不仅仅是指服务器“挂掉了”、“死机了”状态,也包括服务器假死、停用、关闭等一些原因而导致出现的不能够正常运行的状态。

    13 引用 • 82 回帖 • 52 关注
  • WebSocket

    WebSocket 是 HTML5 中定义的一种新协议,它实现了浏览器与服务器之间的全双工通信(full-duplex)。

    48 引用 • 206 回帖 • 378 关注
  • sts
    2 引用 • 2 回帖 • 167 关注
  • Python

    Python 是一种面向对象、直译式电脑编程语言,具有近二十年的发展历史,成熟且稳定。它包含了一组完善而且容易理解的标准库,能够轻松完成很多常见的任务。它的语法简捷和清晰,尽量使用无异义的英语单词,与其它大多数程序设计语言使用大括号不一样,它使用缩进来定义语句块。

    536 引用 • 672 回帖
  • SendCloud

    SendCloud 由搜狐武汉研发中心孵化的项目,是致力于为开发者提供高质量的触发邮件服务的云端邮件发送平台,为开发者提供便利的 API 接口来调用服务,让邮件准确迅速到达用户收件箱并获得强大的追踪数据。

    2 引用 • 8 回帖 • 446 关注
  • 新人

    让我们欢迎这对新人。哦,不好意思说错了,让我们欢迎这位新人!
    新手上路,请谨慎驾驶!

    51 引用 • 226 回帖
  • 创业

    你比 99% 的人都优秀么?

    83 引用 • 1398 回帖