Obsidian / バックアップ設計と復元の確認
残す範囲と、戻せる状態を決めるObsidianのバックアップ設計
Git・File Recovery・別保存の役割
ノートを失う前に、どの本文や設定を残し、どの場所から戻せるかを決めます。著者作成の小さな例で、Gitの以前の版、File Recoveryの古い本文、保管庫外のコピーからの復元を確認しました。三つの方法が果たす役割と、この演習で確かめていない範囲を分けます。
「以前の版へ戻す」と「別の保存場所」を分けて設計する
バックアップの計画では、何を残すか、どの時点へ戻すか、保存先がどこか、実際に戻した内容をどう確認するかを決めます。同期の設定があることや、ファイルが今見えることだけでは、必要な旧版と保存範囲がそろっているかは分かりません。
- Gitの過去版commitへ含めた一つの本文を、別名のファイルへ取り出す
- File Recoveryアプリのローカル履歴から古い本文を選び、復元して再表示
- 保管庫外のコピー選んだ三つのMarkdownを、新しい別の場所で開く
三つとも実際に確認した局所的な例です。保管庫外のコピーも同じファイルシステム内で、独立した物理装置やクラウドを使った結果ではありません。三つの方法があることを、三つの独立した媒体に保存できた証拠としては扱いません。
先に、残す範囲と保存先を決める
自分の保管庫で必要なものを一覧にし、復元先で確認する項目へつなげます。以下は計画のための項目で、この演習がすべてを保存・復元したという表ではありません。
| 決める項目 | 確認する内容 | 今回の実演 |
|---|---|---|
| ノート本文 | 必要なMarkdownの名前、相対パス、どの時点の本文か | 三つのコピー復元、一つのGit履歴、別のFile Recoveryノート |
| 添付と参照 | 画像・PDFなどの保存場所と、本文から参照できること | 添付は未検証。内部リンクはコピー例の三つのMarkdownのみ |
| 設定・プラグイン | .obsidianの設定、必要なプラグインとそのデータを含める範囲 | 設定やプラグインデータのバックアップ・復元は未検証 |
| 保存場所 | 元の保存装置との独立性、読み出せる権限、保管方法 | 保管庫外でも同じ実行ファイルシステム。独立媒体・クラウドは未検証 |
| 頻度と保持 | 戻したい時点、残す旧版、古い版を消す方針 | 単発コピーと二つのGit commit、File Recoveryの二回の自然保存。長期保持や定期運用は未検証 |
| 復元の練習 | 別の復元先、本文・設定・添付・リンクを照合する手順と日程 | 選んだ本文・相対パス・実リンク・再表示を確認。復旧所要時間や故障時の復旧は未測定 |
「どの時点までの変更が残ればよいか」と「戻すまでに必要な時間」も、自分の用途で決めます。今回、RPO/RTOや復旧時間の目標達成は測っていません。コピー作成の頻度を決めることと、過去の版を一定期間残せることは別の確認項目です。
1. Git：commitした本文の以前の版を、別名へ取り出す
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に含めなかったファイルを戻せたとは扱いません。
2. File Recovery：ローカル履歴の古い本文を選んで戻す
補足実演の設定画面は英語UIです。実際にSettings → Core plugins → File recoveryのスイッチを有効にし、File recoveryの設定を開きました。Snapshot intervalの初期値5分を、検証用にいったん0.05分、その後0.5分へ変更しています。History lengthは7日と表示されましたが、七日間の保持は検証していません。
0.5分は履歴間の最短間隔の設定で、30秒ごとに必ず保存するという意味には読み替えません。この版の実コアには60秒の保留再保存タイマーがあり、今回は実エディタで保存したA・Bが保留状態になり、その自然なタイマーで履歴へ入ることを確認しました。履歴DBへ検証者が書き込んだり、履歴作成APIを呼んだりしていません。
- Aを実エディタで保存。「先に残した本文を確認する」を含むAを入力。保存ファイルを照合し、保留状態と、まだAの履歴がないことを確認しました。
- 自然保存を確認。約60秒後にAが履歴へ入りました。次にBへ実編集して保存し、約58秒後の別の自然保存でBが入りました。二回の観測で、普遍的な所要時間を保証しません。
- 古い本文を画面で選ぶ。
Viewを押して回復メモを検索し、最新のBと、以前のAをそれぞれ選んで本文を読みました。 - Restoreして再表示。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破損、長期保持、削除したファイルの回復は試していません。
3. 保管庫外のコピー：本文・階層・リンクを別の場所で確かめる
元のコピー実演では、著者作成の三つのMarkdownを保管庫外へ保存し、元とは別の新しい復元先へ戻しました。索引.mdから、ノート/観察メモ.mdとノート/確認メモ.mdへリンクする構成です。ファイル名と相対パスを保ちました。
索引.md
ノート/
観察メモ.md
確認メモ.mdコピー後、検証者は自分の練習用保管庫だけで一つの本文を変更し、一つのノートを削除しました。コピー側の三つの原文は保持しています。復元は元の状態へ上書きせず、別の新しい場所で行いました。読者が練習するときも、元のノートを保持したまま別の練習用コピーと復元先を用意できます。
復元した観察メモの全文です。
# 観察メモ
コピー前の本文です。これは実際の利用者のデータではありません。
関連する確認は [[ノート/確認メモ|確認メモ]] に残します。
索引から確認メモへの実リンクを押すと、元では取り除いた対象が復元先で表示されました。「索引へ戻る」を押すと索引へ戻れます。その後、実ファイルエクスプローラーから索引を開き直し、三つの保存Markdownが変わらないことを確認しました。
索引の実Markdownも全文を掲載します。
# 索引
著者作成の復元練習です。
- [[ノート/観察メモ|観察メモを開く]]
- [[ノート/確認メモ|確認メモを開く]]
対象は三つのMarkdownだけで、設定や添付はコピーしていません。コピーは保管庫の外でも同じ実行ファイルシステム内です。独立した保存装置やクラウド、故障・災害から戻せることの確認は、バックアップ計画で別に残る項目です。
自分の保管庫で復元の練習をする順番
- 保存対象を書き出す。Markdownだけか、設定・添付・必要な履歴も含めるかを決め、名前と相対パスを控えます。
- 保存先と旧版を確認する。どこへ残すか、元の装置から独立しているか、戻したい時点の版が残るかを確認します。
- 元を保持して別の場所で試す。新しい復元先で、選んだ本文・設定・添付が必要な状態へ戻るかを読みます。
- リンクと再表示を確かめる。本文から参照先を開き、ファイルを開き直して、保存された内容を照合します。
- 結果と未確認項目を残す。使った版、保存範囲、保存先、戻した時点、必要だった時間を記録し、定期的に確認する日程を決めます。
これは読者自身が計画するための手順です。読者の保管庫、定期バックアップ、同期サービス、独立媒体をこの演習で検証したことにはなりません。同期との組合せを調べる入口はObsidianの同期方式ガイドです。
原本を保存して、版と本文を比べる
八つのMarkdownは、各実演の保存原本です。コピー例の三つは元の日本語名で保存し、観察メモ・確認メモをノートフォルダ内へ置きます。ブラウザはそのフォルダを自動作成しません。比較用ファイルとGit・File Recoveryの例は別名で保存し、三つの復元セットへ上書きしない場所で読み比べます。
| 実演・状態 | 配布原本と保存名 |
|---|---|
| コピー復元：索引.md | 索引.md |
| コピー復元：ノート/観察メモ.md | 観察メモ.md |
| コピー復元：ノート/確認メモ.md | 確認メモ.md |
| 比較専用：変更後の観察メモ | 変更後-観察メモ.md |
| Git：過去blobから別名へ戻した本文 | Git復元メモ.md |
| Git：二つ目のcommitの変更後本文 | Git変更後-履歴メモ.md |
| File Recovery：古いA（最終復元と一致） | FileRecovery旧版-回復メモ.md |
| File Recovery：変更後B | FileRecovery変更後-回復メモ.md |
英字の配布URLは状態を区別する別名です。コピー例の本文内wikilinkは日本語の元の相対パスを保ちます。英字名のまま置く場合はリンク先も確認します。配布ファイルを読者が実アプリへ取り込む操作と、Gitの履歴そのものの配布は行っていません。
よくある質問
同期が動いていれば、バックアップの確認は不要ですか？
GitとFile Recoveryは、実際に使って確認しましたか？
保管庫全体や故障時の復旧まで確認済みですか？
配布Markdownは、どの名前と場所で保存しますか？
検証方法と、結果の範囲
- 実アプリ：Linux版Obsidian 1.13.7。設定のGeneral画面でapp/installerを確認し、著者作成の日本語ノートを使用。コミュニティプラグインは使っていません。
- コピー例：選んだMarkdownの用意、コピー、練習用本文の変更・削除、別の復元先へのコピーはshell操作。実GUIで本文・リンク・再表示を確認しました。
- Git：seedとローカルGitのcommit/過去blobの取出しはshell。変更は実エディタで保存し、復元先を実ファイルエクスプローラーから開いて読みました。Gitプラグインやremoteは未使用です。
- File Recovery：有効化と設定は実UI。A/Bは実エディタで入力・保存し、自然なコアタイマーの履歴を実画面で選んでRestore、保存と再表示を確認しました。
- 補助と原本：profile初期構成は直接設定、アプリ状態・保留状態・履歴内容の照合は読み取りAPIです。検証者による履歴作成APIやDB書込みはありません。掲載PNGは無加工の実画面、Markdownは原本と同じbytesです。
- 残る範囲：保管庫全体、設定・添付、独立装置、クラウド、長期保持、故障、同期、複数端末、iOS/Android/macOS、SimpleMemo配送、速度・生産性・流入効果は検証していません。
検証記録と原本の対応に、コピー実演と補足実演の原本、実UIと補助、初期の操作selectorの問題や終了確認の範囲を記録しています。正常終了を保持した試行を、終了コードの残っていない初期試行へさかのぼって適用していません。
本サイトは株式会社ユリカが運営し、独立アプリ「Obsidian連携シンプルメモ」を紹介しています。Obsidian公式による記事ではありません。