Obsidian的备份设计
Git・File Recovery・单独保存的作用

将自己的保管库中需要的东西列为列表，并连接到在复原处确认的项目。 以下是用于计划的项目，不是这个练习保存、恢复所有内容的表格。

还应按自己的用途确定“需要保留到什么时间点的更改”以及“恢复所需的时间”。本次没有测量是否达到 RPO/RTO 或恢复时间目标。确定制作副本的频率，与确认能否将旧版本保留一定时间，是两项独立的检查。

Git的例子，以一个练习用Git履歴メモ.md为对象。 第一个正文commit，在实际的Obsidian编辑器中更改并保存确认项目后，制作了第二个commit。 在此基础上，将上一个commit的实blob取出到新的Git復元メモ.md，用实软件打开。 保留变更后的原始文件。

两个commit有亲子关系，本文的blob也不同。 在Git上追踪的只有这个Markdown，恢复目的地的新笔记，File Recovery用笔记，设置未被追踪。 并不是整个保管库都进入了履历的结果。

返回的实Markdown的全文。 演示之前的blob、恢复文件、分发原件是相同的98字节的UTF-8。

# Git履歴メモ

著者作成の練習です。

- 確認項目: 保存前の本文を読む。

在手边确认时，首先读取目标的状态和履历，选择想要返回的commit和路径。 接下来是显示读取形式的例子。 <commit>替换为自己的履历值。

git status --short -- "Git履歴メモ.md"
git log --oneline -- "Git履歴メモ.md"
git show "<commit>:Git履歴メモ.md"

取出的目的地是选择可以与原来的笔记本区分的未使用的新名字，阅读旧的正文后决定采用的内容。 这个演示的Git操作是本地shell，没有尝试Obsidian Git插件、remote、push/pull、自动commit、其他终端的反映。 不处理没有包含在commit中的文件可以恢复。

补充演示的设定画面是英文UI。 实际上激活了Settings → Core plugins → File recovery的开关，打开了File recovery的设置。 Snapshot interval的初始值5分，为了验证暂时改为0.05分，之后改为0.5分。 History length显示为7天，但是没有验证七天的保留。

0.5分钟设置的是历史记录之间的最短间隔，不能理解为一定每30秒保存一次。该版本的核心有一个60秒的待处理保存重试计时器。本次确认了：在实际编辑器中保存的A、B进入待处理状态，然后由正常运行的计时器加入历史记录。测试者没有写入历史数据库，也没有调用创建历史记录的API。

1. A在实际编辑器中保存。 输入包含“先确认留下的正文”的A。 核对了保存文件，确认了保留状态和还没有A的履历。
2. 确认自然保存。 大约60秒后A进入了履历。 接下来对B进行实际编辑并保存，大约58秒后的另一个自然保存进入了B。 两次观测不能保证普遍的所需时间。
3. 在画面上选择旧的正文。 按View搜索恢复备忘录，分别选择最新的B和以前的A阅读了正文。
4. 恢复后重新显示。 在选择A的状态下按下了实际的Restore。 保存文件与A一致，移动到其他笔记后，在实际文件浏览器中重新打开恢复备忘录也是同样的正文。

UI显示A为“44 B”，B为“47 B”。 用于核对分发文件的实际UTF-8是A是110字节，B是119字节。 UI的显示值没有作为UTF-8的byte数使用。 Restore之后，恢复的A也被添加到了新的履历行中。 这个附加行是恢复操作的结果，与前面A・B的自然保存证据有区别。

复原的A的实Markdown全文。 显示的旧A和最终保存的文件是相同的110字节。

# 回復メモ

著者作成の練習です。

- 保存する項目: 先に残した本文を確認する。

这个结果是从这次本地profile中存在的履历中返回的正文。 File Recovery的履历不是可以保存到独立的备份设备的结果。 没有尝试过profile的转移、应用程序的重新安装、历史DB损坏、长期保留、删除的文件的恢复。

在原始副本演示中，将作者制作的三个Markdown保存在保管库外，回到与原始不同的新复原处。 从索引.md到ノート/観察メモ.md和ノート/確認メモ.md的连接构成。 保留了文件名和相对路径。

索引.md
ノート/
  観察メモ.md
  確認メモ.md

复制完成后，验证者仅在自己的练习用笔记库中修改了一份正文并删除了一条笔记，副本中的三份原始正文均予以保留。恢复在另一个新位置进行，没有覆盖原有状态。读者练习时也可以保留原始笔记，另行准备练习副本和恢复位置。

这是恢复的观察备忘录的全文。

# 観察メモ

コピー前の本文です。これは実際の利用者のデータではありません。

関連する確認は [[ノート/確認メモ|確認メモ]] に残します。

点击从索引到确认备忘录的真实链接，原来删除的对象显示在恢复目的地。“ 按“返回索引”可以返回索引。 之后，从真实文件浏览器重新打开索引，确认了三个保存Markdown没有变化。

索引的实Markdown也刊登全文。

# 索引

著者作成の復元練習です。

- [[ノート/観察メモ|観察メモを開く]]
- [[ノート/確認メモ|確認メモを開く]]

对象只有三个Markdown，没有复制设置和附件。 副本在保管库外也同样在执行文件系统中。 独立的保存装置、云、故障、灾害的确认可以恢复，是备份计划中单独留下的项目。

八个Markdown是各个演示的保存原件。 复制例子中的三个以原来的日语名字保存，观察备忘录、确认备忘录放在ノート 文件夹内。 浏览器不会自动创建那个文件夹。 比较用文件和Git・File Recovery的例子用别名保存，在不覆盖三个恢复集的地方进行比较。

英文字母的分发URL是区分状态的别名。 复制例的正文内wikilink保留日语的原始相对路径。 如果原封不动地放英文名字的话，也会确认链接。 没有将分发文件导入到读者实际应用程序的操作和Git的履历本身的分发。