Obsidian의 백업 설계
Git·File Recovery·별도 저장 역할

자신의 보관함에서 필요한 항목을 목록화하고, 복원 대상에서 확인할 항목에 연결합니다. 아래는 계획을 위한 항목이며, 이 연습이 모든 것을 저장·복원했다는 표가 아닙니다.

「어떤 시점까지 변경이 남아야 하는지」와 「되돌리기까지 필요한 시간」도 자신의 용도에 따라 결정합니다. 이번에는 RPO/RTO 및 복구 시간 목표 달성을 측정하지 않았습니다. 복사 빈도를 결정하는 것과 과거 버전을 일정 기간 남길 수 있는 것은 별개의 확인 항목입니다.

Git 예제는 연습용 Git履歴メモ.md 하나를 대상으로 합니다. 최초 본문을 commit한 뒤 실제 Obsidian 편집기에서 확인 항목을 변경해 저장하고 두 번째 commit을 만들었습니다. 그런 다음 이전 commit의 실제 blob을 새 Git復元メモ.md로 추출해 실제 앱에서 열었습니다. 변경 후의 원본 파일은 유지했습니다.

두 개의 커밋은 부모와 자식 관계를 가지고 있으며, 본문의 blob도 다릅니다. Git에서 추적한 것은 이 하나의 Markdown뿐이며, 복원 대상인 새로운 노트와 File Recovery용 노트, 설정은 추적되지 않았습니다. 보관함 전체가 기록에 포함되어 있다는 결과가 아닙니다.

반환된 실 Markdown의 전체 텍스트입니다. 시연 이전의 blob, 복원 파일, 배포 원본은 동일한 98바이트의 UTF‐8였습니다.

# Git履歴メモ

著者作成の練習です。

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

손으로 확인하는 경우에는 먼저 대상의 상태와 이력을 읽고, 되돌리고 싶은 커밋과 경로를 선택합니다. 다음은 읽기 형태를 보여주는 예시입니다. <commit>은 자신의 기록 값으로 교체합니다.

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

꺼낼 대상은 원본 노트와 구별할 수 있는사용되지 않은 새로운 이름을 선택하고, 오래된 본문을 읽은 후 채택할 내용을 결정합니다. 이 시연의 Git 작업은 로컬 셸에서 수행되며, Obsidian Git 플러그인, remote, push/pull, 자동 commit, 다른 장치에 반영하는 것은 시도하지 않았습니다. Commit에 포함되지 않은 파일을 되돌릴 수 있다고는 처리하지 않습니다.

보충 시연의 설정 화면은 영어 UI입니다. 실제로 Settings → Core plugins → File recovery 스위치를 활성화하고 파일 복구 설정을 열었습니다. Snapshot interval의 초기값 5분을 검증용으로 일시적으로 0.05분으로 변경하고, 그 후 0.5분으로 변경하고 있습니다. History length는 7일이라고 표시되었지만, 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의 바이트 수로 사용하고 있지 않습니다. Restore 후에 복원한 A가 새로운 기록 행에도 추가되었습니다. 이 추가 행은 복원 작업에 의한 결과이며, 앞선 A·B의 자연 보존 증거와 구별됩니다.

복원된 A의 열매 Markdown 전체 텍스트입니다. 표시된 오래된 A와 최종 저장 파일은 동일한 110 바이트였습니다.

# 回復メモ

著者作成の練習です。

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

이 결과는 이번 로컬 프로필에 존재했던 기록에서 하나의 본문을 되돌린 것입니다. File Recovery의 기록이 독립된 백업 장치에 저장된 결과가 아닙니다. 프로필 이전, 앱 재설치, 히스토리 DB 손상, 장기 보관, 삭제된 파일 복구는 시도하지 않았습니다.

원본 복제 시연에서는 저자가 만든 세 개의 Markdown을 보관함 외부에 보관하고, 원본과는 다른 새로운 복원처로 되돌렸습니다. 索引.md에서 ノート/観察メモ.md와 ノート/確認メモ.md으로 연결하는 구성입니다. 파일 이름과 상대 경로를 유지했습니다.

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

복사 후, 검증자는 자신의 연습용 보관함에서만 하나의 본문을 수정하고, 하나의 노트를 삭제했습니다. 복사 측의 세 원문은 보존하고 있습니다. 복원은 원래 상태로 덮어쓰지 않고, 다른 새로운 장소에서 수행했습니다. 독자가 연습할 때도 원본 노트를 유지한 채 별도의 연습용 복사본과 복원 대상을 준비할 수 있습니다.

복원된 관찰 메모의 전체 내용입니다.

# 観察メモ

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

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

인덱스에서 확인 메모로 실제 링크를 클릭하면, 원래 제거한 대상이 복원 대상에 표시되었습니다. '색인으로 돌아가기'를 누르면 색인으로 돌아갈 수 있습니다. 그 후, 실제 파일 탐색기에서 인덱스를 다시 열어 세 개의 저장 Markdown이 변하지 않았는지 확인했습니다.

인덱스의 실제 Markdown도 전체를 게재합니다.

# 索引

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

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

대상은 세 개의 Markdown만이며, 설정 및 첨부 파일은 복사하지 않았습니다. 복사본은 보관함 밖에서도 동일한 실행 파일 시스템 내에 있습니다. 독립된 저장 장치와 클라우드, 고장·재해로부터 복구할 수 있는지는 백업 계획에 별도로 남아 있는 항목입니다.

여덟 개의 Markdown은 각 시연의 보존 원본입니다. 복사 예시의 세 개는 원래 일본어 이름으로 저장하고, 관찰 메모·확인 메모를 ノート 폴더 내부에 배치합니다. 브라우저는 해당 폴더를 자동으로 생성하지 않습니다. 비교용 파일과 Git·File Recovery의 예는 별명으로 저장하고, 세 개의 복원 세트에 덮어쓰지 않는 곳에서 읽어 비교합니다.

영문자 배포 URL은 상태를 구분하는 별명입니다. 복사 예시 본문 내 위키링크는 일본어 원본 상대 경로를 유지합니다. 영문 이름을 그대로 두는 경우에는 링크도 확인합니다. 배포 파일을 독자가 실제 애플리케이션에 가져오는 작업과 Git 기록 자체의 배포는 수행하지 않습니다.