一次 Obsidian 仓库丢失与恢复：给 Agent 配置 CLI 的教训

2026 年 10 月 2 日，我想让 Codex 直接管理滴答清单和 Obsidian。原本只是安装 CLI、配置调用方式，最后却变成了一次笔记仓库恢复。

先把责任说清楚：这次仓库丢失发生在 Agent 执行 Obsidian 安装器升级之后。执行前没有完整备份仓库，也没有检查仓库是否放在程序安装目录内。这是 Agent 操作中的失误，不是用户主动删除了资料。

截至写作时，笔记和附件已经恢复，Obsidian 能打开原仓库，CLI 的查询也通过了验证。不过，插件配置是否与事故前每一项都一致，仍不能完全确认；同步连接和预演通过，也不等于实际双向同步已经完成验证。

一个容易忽略的目录关系

我的仓库放在 Obsidian 安装目录下面。隐去个人目录名后，结构大致如下：

D:\Obsidian\
├── Obsidian.exe
└── <仓库目录>\
    └── vault\
        ├── .obsidian\
        ├── diary\
        ├── Templates\
        └── 附件\

Agent 为了让官方 CLI 可用，更新了 Obsidian 的安装器。在执行升级前，只备份了应用的全局仓库登记配置，没有把整个 vault 及其中的 .obsidian 一起备份。

安装完成后，原来的 vault 目录消失，Obsidian 无法正常打开资料。这里能确认的是升级操作与仓库消失的时间关系，以及仓库位于安装目录内部的事实；此次没有审计安装器内部的清理代码，不能据此断言某一行安装脚本就是具体原因。

但操作责任没有疑问：在没有查清数据位置、没有完整备份的情况下执行安装目录内升级，是这次事故的关键失误。

第一步：保住还能找到的内容

发现问题后，恢复工作转向减少源盘写入，并把可用的应用数据库复制到另一个盘。重点检查了 Obsidian 的 IndexedDB、Local Storage，以及插件留下的缓存。

数据库缓存和原始文件不是一回事。一部分记录只保存文件路径、元数据或摘要，并没有完整正文。通过解析备份记录，最终得到 21 篇不同 Markdown 文件的可用快照。

这些快照有价值，但只能算部分恢复，不能因为数据库里有大量记录，就宣称全部笔记都找回来了。

第二步：磁盘扫描，不能只看文件名

随后使用 Windows File Recovery 读取原盘，把恢复结果写入另一个盘。

扫描结果里出现了很多文件，其中有 340 个 Markdown 文件。但检查内容后发现，183 个 Markdown 文件的内容全部由零字节组成，还有一些包含损坏数据。文件名存在、文件大小非零，都不能证明正文可读。

将扫描结果与事故前缓存中的 SHA-256 对比，确认了 98 个 Markdown 文件内容完全匹配。结合数据库快照，得到了一份部分恢复结果。

这一步没有完成完整恢复。零字节和损坏数据是实际观察到的结果，但此次没有取得足够证据证明某一种 SSD 机制就是唯一原因。

真正完整的副本，在本地 OneDrive 文件夹里

转折来自我提醒 Agent：资源管理器里的 OneDrive 目录不就已经在本地了吗？

前面的排查没有及时找到这份本地同步副本，反而先进行了复杂的数据库解析和磁盘扫描。这也是本次流程应当改进的地方。

最终找到的同步路径，隐去 Windows 用户名后，是：

C:\Users\<用户>\OneDrive\Apps\Graph 1\vault

这里保存着原仓库的完整同步副本，包括笔记、附件、.obsidian 配置和插件文件。对可能是占位文件的内容，通过实际读取和复制确认已经下载为独立本地文件，而不是只看资源管理器里的文件名。

先把这份副本复制到独立恢复目录，再校验内容，最后恢复到原仓库位置。恢复结果如下：

其中 465 个笔记有事故前的完整摘要可供比对；其余普通文件没有同样的历史摘要。这两种验证强度需要分开说明。配置和插件文件包含在 506 个文件中，不能把 506 理解成笔记篇数。

手机副本也需要核对，而不是直接覆盖

手机 Obsidian 中还有一份仓库。通过 USB 文件传输只读复制了日记目录，手机上的文件没有被修改。

手机和电脑各有 423 篇日记：422 篇的 SHA-256 一致，只有当天的日记有差异，双方没有独有的日记路径。当天日记的两个版本分别保留，没有自动合并，也没有拿手机版本覆盖电脑版本。

这个结果提供了额外的交叉验证，也说明恢复时不能简单认为“另一台设备上的版本一定更新”。

笔记回来后，设置并没有自动回到原样

恢复整个目录后，重新启动 Obsidian，原仓库和当天日记可以正常打开。官方 CLI 也能识别原仓库，仓库查询、文件统计、插件和设置查询均实测成功。

但我随后发现 Remotely Save 的设置还是变了。这说明“文件恢复”与“应用状态恢复”是两项不同的检查。

进一步比对发现：

• Templater 和批量重命名插件的配置与独立恢复副本一致，插件文件也完成了核对。
• Templater 的模板目录仍是 Templates，新文件自动套用模板仍开启。
• Remotely Save 副本中的定时同步是关闭状态，当前配置却变为每 10 分钟一次；已备份当前配置，并恢复为关闭状态、停止现有定时器。
• 同步副本中的旧登录凭证已经过期，因此保留了当前有效凭证，没有整份覆盖回旧配置。

Remotely Save 的只读预演能够连接 OneDrive，没有报错。计划中有 501 项内容一致、5 项配置冲突，冲突全部位于 .obsidian，没有笔记正文冲突。

需要特别说明：预演会更新插件显示的状态，但它没有执行真正的文件同步。因此不能仅凭“同步成功”的状态栏文字，就宣称实际上传、下载都已验证成功。

另外，OneDrive 配置副本可能不包含事故前电脑上的每一项最新设置。手机后来断开连接，手机插件配置的进一步核对也尚未完成。当前可以确认笔记和附件恢复、应用可打开、CLI 查询可用，但不能写成所有历史设置已百分之百恢复。

后续补查：开启了配置同步，旧设置还能找回来吗？

恢复后，我又让 Agent 查找配置文件夹，因为我记得曾在 Remotely Save 中开启“同步配置文件夹”。这次检查确认，我的记忆没有错：当前开关是 syncConfigDir=true，事故前的同步数据库中也有 .obsidian 和插件配置文件的同步记录。

OneDrive 中的配置目录就在 Apps\Graph 1\vault\.obsidian，已经包含在首次恢复的完整副本里。Obsidian 当前读取的也是原仓库中的 .obsidian；“后来找到配置目录”不意味着此前只恢复了笔记、没有应用任何配置。

为了寻找更接近事故前状态的设置，继续检查了磁盘恢复结果，并查询 OneDrive 中 12 个 JSON 配置文件的版本列表，实际下载保存了 12 份历史配置。文件名相同也要检查正文：磁盘找回的 Templater、批量重命名、快捷键和模板配置均为有效 JSON，摘要与独立恢复副本一致；无法有效解析的候选文件没有拿来覆盖设置。

下面是实际下载的历史版本及云端记录的修改时间，全部转换为北京时间。这些时间不是本次下载时间。

其中 5 份是 2025 年保留的版本，与首次恢复的独立副本一致；另外 7 份是当天恢复后产生的版本。此次可查到的历史中，没有找到更接近事故发生前的配置。版本号是各文件自己的序号，不应跨文件比较；云端记录的修改时间也不一定按版本号严格递增。

这 12 份历史配置只是下载到独立恢复目录留存，没有覆盖当前应用设置。尤其不能把旧 Remotely Save 配置整份替换回去，否则其中过期的登录凭证可能让连接再次失效。

桌面布局没有恢复，则有一个明确的代码依据：当前安装的 Remotely Save 在遍历配置目录时，显式跳过 workspace 和 workspace.json。所以勾选“同步配置文件夹”，并不意味着桌面标签页和工作区布局也会同步。云端副本和已检查的磁盘恢复结果都没有找到原 workspace.json，当前文件是恢复后重新生成的。

这次补查确认了配置同步确实存在，也把“应用了恢复副本”和“找回了事故前全部最新设置”区分清楚。后者仍没有足够证据，不能为了让复盘看起来完整就宣称已全部恢复。

这次给 Agent 配置 CLI 的教训

在这次事故中，Agent 应当在执行安装器之前完成的检查，实际上是在事故之后才做：

1. 查清程序目录、真实仓库目录及两者的包含关系。
2. 备份整个 vault，包括 .obsidian、附件和插件设置，而不仅是全局配置文件。
3. 将备份放在安装目录之外，实际读取并校验备份内容。
4. 出现数据丢失时，优先检查本地同步目录、其他设备和已有备份，再选择磁盘恢复路径。
5. 恢复后分别验证正文、附件、插件设置、同步行为和 CLI，明确哪些已经实测、哪些仍有不确定性。

同步副本在这次事故中救回了资料，但同步可能传播删除和错误修改，不能代替独立、可回溯的备份。此次完整恢复的来源是 OneDrive 中仍保存的副本，而不是磁盘扫描奇迹般找回了全部资料。

让 Agent 管理本地知识库，意味着它触碰的是长期积累的数据。执行效率不能替代目录检查和完整备份；事故发生后，恢复结果也必须靠内容校验来证明，而不能靠一句“已经恢复正常”。

本文记录的是 2026 年 10 月 2 日当次操作和验证结果。文中路径已做隐私处理，不包含日记正文、账户凭证或私人截图。