十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
如果一份笔记已经删掉，后来服务器从旧备份恢复，它会不会又出现在账号里？
做日语随记与陪练的学习同步时，这个问题让我意识到：有备份，只回答了“能不能拿回过去的一份数据”，还没回答“恢复以后是不是用户现在应该看到的状态”。
这里讨论单独开启同步后的学习资料。没有开启的本机内容，以及仍留在 Mac 上的朗读录音，不因为这篇文章就进入同一套云端备份。
一份备份，先要读得出来#
最基本的检查是文件完整、内容可读取、数据库内部一致。如果备份只是生成了一个文件名，或者上传后从没实际下载检查，就很难知道它出问题时是否能用。
数据库还可能一边运行一边发生修改。以 SQLite 为例，应该使用能形成一致快照的备份方式，不能随手只复制一个看起来最像数据库的文件，就假设所有事务都在里面。SQLite 的备份文档解释了在线备份的用途。
我会在独立位置恢复，保留当前资料，先检查摘要与可读性，再进行后续验证。恢复演练不需要拿真实用户的学习照片公开展示，合成账号和虚构笔记也能验证关键行为。
恢复的是旧快照，还得补上后来发生的删除#
用一个自编例子看：周一备份里有笔记 A，周二用户删除 A，周三需要恢复周一的快照。如果只把文件放回去就开放服务，A 会重新出现。
所以恢复之后、重新让用户访问之前，还要按当前有效的删除状态处理这份旧数据。删除账号、清理资料和旧请求迟到，也要避免把已经删除的内容重新建立起来。
保存必要的删除凭据，目的在于防止旧内容复活；它与继续保留用户正文是不同事情。具体保留和清理范围，应当由产品的数据说明交代。
我会怎样写一张恢复验收表#
至少放两个人的合成资料，分别验证恢复后的内容和账号隔离。再安排一份“备份之后已经删除”的资料，确认恢复后不会重新出现。
| 检查 | 不能只看什么 |
|---|---|
| 文件可以读取 | 不能只看下载请求成功 |
| 数据库状态一致 | 不能只看文件体积正常 |
| 删除仍然生效 | 不能只看旧笔记能读回来 |
| 账号仍然隔离 | 不能只用一个账号完成演练 |
| 用户路径可用 | 不能只看进程启动成功 |
已有的一次合成账号恢复演练核对了旧快照和后续删除状态。但这份结果有自己的范围，不能据此声称所有灾难、所有客户端和所有用户数据都已经覆盖。
回滚代码，和恢复数据，也应分开#
程序版本退回上一版，不代表数据会跟着回到过去；把旧数据放回去，也不应撤销用户后来提出的删除。
我会分别记代码回滚、数据库恢复、删除状态追赶和用户路径检查。每一步都保留具体结果，避免一句“已经回滚”让下一位接手的人误解现场。
公开文章可以讲这些关系，不需要公布备份位置、访问方式、加密凭据、内部周期或真实资料。对读者更有用的，是一份能检验恢复是否正确的清单。