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的履歷本身的分發。