Obsidian / Desain cadangan dan konfirmasi pemulihan

Tentukan rentang yang akan ditinggalkan dan keadaan yang dapat dikembalikan

Desain cadangan Obsidian
Git, Pemulihan File, peran penyimpanan terpisah

Halaman ini diterjemahkan secara otomatis dari bahasa Jepang. Baca versi asli berbahasa Jepang

Sebelum kehilangan catatan, tentukan teks dan pengaturan mana yang akan ditinggalkan dan dari mana harus kembali. Dengan contoh kecil yang dibuat oleh penulis, kami mengkonfirmasi pemulihan dari versi Git sebelumnya, badan lama Pemulihan File, dan salinan di luar brankas. Bagilah peran yang dimainkan oleh tiga metode dan ruang lingkup yang tidak dikonfirmasi dalam latihan ini.

Menulis: SimpleMemo Developer · Operasi aktual: 2026 9 30 UTC (waktu Jepang 1 Oktober) · Linux / Obsidian 1.13.7

Desain "Kembalikan ke versi sebelumnya" dan "Lokasi penyimpanan yang berbeda" secara terpisah

rencana cadangan, memutuskan apa yang harus ditinggalkan, ke titik mana harus kembali, ke mana harus disimpan, dan cara memeriksa konten yang sebenarnya telah dikembalikan. Saya tidak tahu apakah versi lama dan rentang penyimpanan yang Anda butuhkan hanya karena ada pengaturan sinkronisasi atau fakta bahwa file tersebut terlihat sekarang.

Versi sebelumnya dari GitMengambil satu teks yang disertakan dalam komit ke dalam file alias
Pemulihan FilePilih teks lama dari riwayat lokal aplikasi, pulihkan dan tampilkan ulang
Salin di luar brankasBuka tiga Markdown yang dipilih di lokasi baru dan berbeda

Ketiganya adalah contoh lokal yang benar-benar telah dikonfirmasi. Salinan di luar brankas bukan hasil dari penggunaan perangkat fisik independen atau awan dalam sistem file yang sama. Keberadaan tiga metode tidak diperlakukan sebagai bukti bahwa itu disimpan dalam tiga media independen.

Pertama, tentukan jarak yang akan ditinggalkan dan tujuan

Buat daftar apa yang Anda butuhkan di ruang penyimpanan Anda dan hubungkan ke item yang akan diperiksa di tujuan pemulihan. Berikut ini adalah item untuk rencana, bukan tabel yang mengatakan bahwa latihan ini telah menyelamatkan dan memulihkan semuanya.

Item untuk diputuskan	Isi yang akan dikonfirmasi	Demonstrasi ini
Teks catatan	Nama Markdown yang diperlukan, jalur relatif, dan teks pada titik waktu	Tiga restorasi salinan, satu riwayat Git, catatan Pemulihan File lainnya
Lampiran dan referensi	Di mana menyimpan gambar, PDF, dll. dan apa yang dapat direferensikan dari teks	Lampiran belum diverifikasi. Tautan internal hanya tiga Markdown dalam contoh salinan
Konfigurasi dan plug-in	Konfigurasi `.obsidian`, plug-in yang diperlukan, dan cakupan data disertakan	Pencadangan dan pemulihan pengaturan dan data plug-in belum diverifikasi
Simpan lokasi	Kemerdekaan dengan perangkat penyimpanan asli, otoritas yang dapat dibaca, metode penyimpanan	Sistem file yang dapat dieksekusi yang sama di luar brankas. Media dan cloud independen belum diverifikasi
Frekuensi dan retensi	Poin yang ingin Anda kembalikan, versi lama yang akan ditinggalkan, dan kebijakan penghapusan versi lama	Salinan sekali-tembakan, dua komit Git, dan dua penghematan alami Pemulihan File. Retensi jangka panjang dan operasi reguler belum diverifikasi
Latihan pemulihan	Prosedur dan jadwal untuk mengawinkan tujuan pemulihan lainnya, teks, pengaturan, lampiran, dan tautan	Konfirmasikan teks yang dipilih, jalur relatif, tautan aktual, dan tampilan ulang. Waktu pemulihan yang diperlukan dan pemulihan jika terjadi kegagalan belum diukur

"Berapa lama perubahan harus tetap ada" dan "waktu yang dibutuhkan untuk kembali" juga ditentukan oleh tujuan Anda sendiri. Kali ini, kami belum mengukur tujuan RPO/RTO dan waktu pemulihan. Menentukan frekuensi penyalinan dan kemampuan untuk meninggalkan versi sebelumnya untuk jangka waktu tertentu adalah item konfirmasi yang terpisah.

1. Git: Ambil versi sebelumnya dari teks yang dikirimkan ke alias

Contoh Git adalah untuk satu latihan Git履歴メモ.md. Setelah melakukan teks pertama dan mengubah serta menyimpan item konfirmasi di editor Obsidian yang sebenarnya, saya membuat komitmen kedua. Selain itu, Saya mengeluarkan gumpalan sebenarnya dari komitmen sebelumnya ke Git復元メモ.md baru dan membukanya dengan aplikasi asli. File asli setelah perubahan disimpan.

Kedua komit memiliki hubungan orang tua-anak, dan gumpalan teks juga berbeda. Hanya Markdown yang satu ini yang telah dilacak di Git, dan catatan baru yang akan dipulihkan, catatan untuk Pemulihan File, dan pengaturannya belum dilacak. Bukan hasil bahwa seluruh lemari besi ada dalam sejarah.

Buka memo pemulihan Git, dan item untuk membaca teks sebelum menyimpan ditampilkan di memo riwayat Git sebelumnya — Dalam catatan alias baru, teks dari komit sebelumnya benar-benar ditampilkan. Alasan mengapa judul nama file di bagian atas dan badannya berbeda adalah karena itu diambil ke alias tanpa mengubah badannya. Buka gambar asli

Ini adalah teks lengkap dari buah yang dikembalikan Markdown. Gumpalan demonstrasi sebelumnya, file yang dipulihkan, dan distribusi asli adalah 98 byte UTF-8 yang sama.

# Git履歴メモ

著者作成の練習です。

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

Jika Anda ingin memeriksanya di tangan, pertama-tama baca status dan riwayat target, dan pilih komit dan jalur yang ingin Anda kembalikan. Berikut ini adalah contoh dari bentuk membaca. Ganti <commit> dengan nilai riwayat Anda.

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

Pilih nama baru yang tidak digunakan yang dapat dibedakan dari catatan asli, baca teks lama, lalu putuskan apa yang akan diadopsi. Operasi Git dari demonstrasi ini adalah shell lokal, dan plug-in Obsidian Git, remote, push/pull, komit otomatis, dan refleksi ke terminal lain belum dicoba. Itu tidak diperlakukan sebagai dapat mengembalikan file yang tidak termasuk dalam komit.

2. Pemulihan File: Pilih dan kembalikan teks lama dari riwayat lokal

Layar pengaturan untuk demonstrasi tambahan adalah UI bahasa Inggris. Saya benar-benar mengaktifkan sakelar Settings → Core plugins → File recovery dan membuka pengaturan pemulihan File. Nilai awal Snapshot interval 5 menit telah diubah menjadi 0.05 menit untuk verifikasi, dan kemudian 0.5 menit. History length menunjukkan 7 hari, tetapi retensi tujuh hari belum diverifikasi.

Interval Snapshot pada layar pengaturan pemulihan File adalah 0.5, panjang Riwayat adalah 7, dan tombol Lihat ditampilkan — UI konfigurasi aktual. Menit 0.5 adalah nilai yang diubah dalam latihan ini. Itu tidak disajikan sebagai nilai default atau pengaturan yang disarankan. Buka gambar asli

Pengaturan 0.5 menit adalah interval minimum antarentri riwayat; ini tidak berarti salinan pasti disimpan setiap 30 detik. Inti versi ini memiliki pengatur waktu 60 detik untuk mencoba ulang penyimpanan tertunda. Kami memastikan bahwa versi A dan B yang disimpan melalui editor sebenarnya masuk ke status tertunda, lalu ditambahkan ke riwayat oleh pengatur waktu normal tersebut. Penguji tidak menulis ke basis data riwayat atau memanggil API pembuatan riwayat.

A di editor asli. Masukkan A termasuk "Periksa teks yang tersisa sebelumnya". Saya memeriksa file yang disimpan dan memastikan bahwa mereka ditahan dan belum ada riwayat A.
Konfirmasi pelestarian alami. Tentang 60 detik kemudian, A memasuki riwayat. Selanjutnya, saya mengeditnya menjadi B dan menyimpannya, dan B dimasukkan dalam pelestarian alami lainnya setelah sekitar 58 detik. Dua pengamatan tidak menjamin waktu universal yang dibutuhkan.
Pilih teks lama di layar. Tekan View untuk mencari catatan pemulihan, pilih B terbaru dan A sebelumnya, lalu baca teksnya.
Pulihkan dan tampilkan ulang. Saya menekan Restore yang sebenarnya saat memilih A. File yang disimpan cocok dengan A, dan setelah pindah ke catatan lain, saya membuka kembali memo pemulihan di penjelajah file yang sebenarnya, dan teksnya sama.

Pilih baris B terbaru dari Pemulihan File dan centang teks setelah perubahan yang diinginkan ditampilkan — Pilih B terbaru di layar yang sebenarnya. Ini adalah teks setelah perubahan penulis. Buka gambar asli

Pilih baris A sebelum Pemulihan File, periksa teks yang tersisa sebelumnya, dan tombol Pulihkan ditampilkan — Saya memilih A sebelumnya di layar asli dan memulihkan teks ini. Buka gambar asli

Di UI, A ditampilkan sebagai "44 B" dan B sebagai "47 B". UTF-8 yang sebenarnya digunakan untuk mencocokkan file distribusi adalah A adalah 110 byte dan B adalah 119 byte. Nilai tampilan UI tidak digunakan sebagai jumlah byte UTF-8. Setelah Pulihkan, A yang dipulihkan juga ditambahkan ke baris riwayat baru. Garis tambahan ini adalah hasil dari operasi pemulihan dan membedakannya dari bukti pelestarian alami A dan B sebelumnya.

Setelah memulihkan di Pemulihan File, teks ditampilkan yang mengatakan untuk membuka kembali catatan pemulihan dan memeriksa teks yang tersisa sebelum — Dibuka kembali di penjelajah file asli. Teks yang dipilih sebelum restorasi, asli yang disimpan, dan SHA256 setelah ditampilkan ulang cocok. Buka gambar asli

Ini adalah teks lengkap dari Markdown asli A yang dipulihkan. A lama yang ditampilkan dan file terakhir yang disimpan adalah byte 110 yang sama.

# 回復メモ

著者作成の練習です。

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

Hasil ini adalah mengembalikan teks dari riwayat yang ada di profil lokal kali ini. Ini bukan hasil dari kemampuan untuk menyimpan riwayat pemulihan file ke perangkat cadangan terpisah. Saya belum mencoba memigrasi profil, menginstal ulang aplikasi, merusak riwayat DB, retensi jangka panjang, atau memulihkan file yang dihapus.

3 Salinan di luar brankas: Periksa teks, hierarki, dan tautan di tempat lain

Dalam demonstrasi salinan asli, tiga Markdown yang dibuat oleh penulis disimpan di luar lemari besi dan dikembalikan ke tujuan restorasi baru yang berbeda dari aslinya. Ini adalah konfigurasi yang menghubungkan dari 索引.md ke ノート/観察メモ.md dan ノート/確認メモ.md. Nama file dan jalur relatif telah dipertahankan.

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

Setelah menyalin, pemverifikasi hanya mengubah satu teks di brankas latihannya dan menghapus satu catatan. Tiga teks asli di sisi salinan dipertahankan. Restorasi tidak ditimpa ke keadaan semula dan dilakukan di lokasi baru lainnya. Bahkan ketika pembaca berlatih, Anda dapat menyiapkan salinan latihan lain dan mengembalikan tujuan sambil menyimpan catatan asli.

Tautan ke teks sebelum menyalin dan memo konfirmasi ditampilkan di memo pengamatan tujuan pemulihan lainnya — Isi memo pengamatan sebelum menyalin sebenarnya ditampilkan di tujuan pemulihan lain. Tiga Markdown yang dipulihkan cocok dengan yang asli dan byte/hash awal. Buka gambar asli

Ini adalah teks lengkap dari memo pengamatan yang dipulihkan.

# 観察メモ

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

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

Ketika saya menekan tautan yang sebenarnya dari indeks ke memo konfirmasi, objek yang awalnya dihapus ditampilkan di tujuan pemulihan. " Anda dapat kembali ke indeks dengan menekan "Kembali ke Indeks". Setelah itu, saya membuka kembali indeks dari penjelajah file asli dan mengonfirmasi bahwa tiga Markdown yang disimpan tidak berubah.

Catatan konfirmasi tujuan pemulihan menunjukkan teks yang mengonfirmasi teks asli dan tautan serta tautan kembali ke indeks — Memo konfirmasi dibuka dengan tautan asli dari indeks tujuan yang dipulihkan. Saya sedang memeriksa jalur relatif dan tujuan tautan. Buka gambar asli

Buka kembali indeks tujuan pemulihan dan tampilkan tiga catatan dan dua tautan internal — Menampilkan ulang indeks dari penjelajah file asli. Tiga teks yang disimpan tidak berubah. Buka gambar asli

Teks lengkap dari indeks Markdown asli juga akan diposting.

# 索引

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

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

Targetnya hanya tiga Markdown, dan pengaturan serta lampirannya belum disalin. Salinan berada dalam sistem file yang dapat dieksekusi yang sama di luar brankas. Konfirmasi bahwa itu dapat dipulihkan dari perangkat penyimpanan independen, cloud, kegagalan, dan bencana adalah item terpisah yang tersisa dalam rencana cadangan.

Urutan praktik restorasi di ruang penyimpanan Anda sendiri

Ekspor target yang disimpan. Putuskan apakah akan menyertakan hanya Markdown atau pengaturan, lampiran, dan riwayat yang diperlukan, dan simpan nama dan jalur relatif.
Periksa alamat penyimpanan dan versi lama. Periksa di mana harus meninggalkannya, apakah itu independen dari perangkat asli, dan apakah versi pada titik yang ingin Anda kembalikan tetap ada.
Simpan yang asli dan coba di tempat lain. Baca apakah teks, pengaturan, dan lampiran yang dipilih diperlukan untuk kembali ke tujuan pemulihan baru.
Periksa tautannya dan tampilkan kembali. Buka referensi dari badan, buka kembali file, dan bandingkan konten yang disimpan.
Tinggalkan hasil dan item yang belum dikonfirmasi. Catat versi yang digunakan, jangkauan penyimpanan, tujuan penyimpanan, waktu pengembalian, waktu yang diperlukan, dan tentukan jadwal yang akan diperiksa secara teratur.

Ini adalah prosedur bagi pembaca untuk merencanakan sendiri. Latihan ini tidak memverifikasi brankas pembaca, cadangan reguler, layanan sinkronisasi, dan media independen. Pintu masuk untuk memeriksa kombinasi dengan sinkronisasi adalah panduan metode sinkronisasi Obsidian.

Simpan yang asli dan bandingkan versi dan teksnya

Delapan Markdown adalah yang asli dari setiap demonstrasi. Simpan tiga contoh salinan dengan nama asli Jepang, dan letakkan memo pengamatan dan memo konfirmasi di folder ノート. Browser tidak secara otomatis membuat folder. Simpan file perbandingan dan contoh Git/File Recovery sebagai alias, lalu baca dan bandingkan di tempat di mana mereka tidak ditimpa oleh tiga set pemulihan.

Demonstrasi dan status	Nama asli dan tersimpan yang didistribusikan
Pemulihan salinan: 索引.md	索引.md
Pemulihan salinan: ノート/観察メモ.md	観察メモ.md
Pemulihan salinan: ノート/確認メモ.md	確認メモ.md
Hanya perbandingan: Memo pengamatan setelah perubahan	変更後-観察メモ.md
Git: Teks dikembalikan dari gumpalan masa lalu ke alias	Git復元メモ.md
Git: Teks setelah mengubah komit kedua	Git変更後-履歴メモ.md
Pemulihan File: A Lama (cocok dengan pemulihan terakhir)	FileRecovery旧版-回復メモ.md
Pemulihan File: B setelah modifikasi	FileRecovery変更後-回復メモ.md

Distribusi karakter bahasa Inggris URL adalah alias yang membedakan negara bagian. Tautan wiki di badan contoh salinan menyimpan jalur relatif asli bahasa Jepang. Jika Anda membiarkan nama bahasa Inggris apa adanya, periksa tautannya juga. Pembaca tidak mengimpor file distribusi ke dalam aplikasi yang sebenarnya, dan riwayat Git itu sendiri tidak didistribusikan.

Pertanyaan umum

Jika sinkronisasi sudah berjalan, apakah cadangan masih perlu diperiksa?

Saya tidak tahu apakah saya dapat kembali ke teks sebelumnya atau apakah ada tujuan penyimpanan independen berdasarkan fakta bahwa saya mengatur sinkronisasi. Periksa riwayat metode yang digunakan, rentang yang dapat dikembalikan, dan lokasi penyimpanan. Latihan ini tidak menggunakan sinkronisasi dan belum mencoba memulihkan Obsidian Sync atau iCloud.

Apakah Anda benar-benar menggunakan Git dan Pemulihan File untuk mengonfirmasinya?

Di Git, saya membuat dua komit untuk satu latihan Markdown, mengembalikan gumpalan sebelumnya ke file alias baru, dan membacanya dengan Obsidian asli. Dalam Pemulihan File, A dan B yang disimpan di editor asli memasukkan riwayat dengan pengatur waktu alami, pilih A lama di layar untuk Memulihkan, dan konfirmasikan penyimpanan dan tampilan ulang. Pencadangan Git otomatis, jarak jauh, dan retensi jangka panjang belum diverifikasi.

Sudahkah Anda memeriksa seluruh penyimpanan dan pemulihan jika terjadi kegagalan?

Contoh salinan hanya tiga Markdown, dan pengaturan serta lampiran tidak disertakan. Tujuan penyimpanan juga berada dalam sistem file yang dapat dieksekusi yang sama. Kami belum mencoba memulihkan perangkat fisik independen, cloud, kegagalan, bencana, periode retensi riwayat, dan seluruh penyimpanan. Periksa hasil restorasi lokal Git dan File Recovery dan pemulihan seluruh brankas secara terpisah.

Apa nama dan lokasi Anda menyimpan distribusi Markdown?

Tempatkan 索引.md untuk contoh salinan, dan tempatkan 観察メモ.md dan 確認メモ.md di folder ノート. Browser tidak secara otomatis membuat folder. File perbandingan yang dimodifikasi, contoh Git dan File Recovery, disimpan dengan alias yang dapat dibedakan dan tidak ditimpa ke set pemulihan. Jika Anda ingin menggunakan nama distribusi bahasa Inggris, silakan periksa juga tautan dalam teks.

Metode verifikasi dan rentang hasil

Aplikasi asli:Versi Linux Obsidian 1.13.7. Periksa aplikasi/penginstal di layar Umum pengaturan dan gunakan catatan bahasa Jepang yang dibuat oleh penulis. Saya tidak menggunakan plug-in komunitas.
Salin contoh: Mempersiapkan, menyalin, mengubah, dan menghapus teks untuk latihan, dan menyalin ke tujuan pemulihan lain dari Markdown yang dipilih adalah operasi shell. Saya memeriksa teks, tautan, dan tampilan ulang dengan GUI yang sebenarnya.
Git:Penghapusan seed dan lokal Git commit/past blob adalah shell. Saya menyimpan perubahan di editor asli dan membuka tujuan pemulihan dari penjelajah file asli untuk membacanya. Plug-in Git dan remote tidak digunakan.
Pemulihan File: Aktivasi dan pengaturan adalah UI asli. A/B dimasukkan dan disimpan di editor yang sebenarnya, dan riwayat pengatur waktu inti alami dipilih di layar yang sebenarnya untuk memulihkan, menyimpan, dan menampilkan kembali.
Tambahan dan asli: Konfigurasi awal profil diatur secara langsung, dan status aplikasi, status tertunda, dan konten riwayat dibaca API. Tidak ada pembuatan riwayat API atau penulisan DB oleh pemverifikasi. PNG yang diposting adalah layar nyata yang belum diproses, dan Markdown adalah byte yang sama dengan aslinya.
Rentang yang tersisa: Seluruh penyimpanan, pengaturan dan lampiran, perangkat independen, cloud, retensi jangka panjang, kegagalan, sinkronisasi, beberapa terminal, iOS/Android/macOS, pengiriman SimpleMemo, kecepatan, produktivitas, dan efek aliran masuk belum diverifikasi.

Catatan verifikasi dan korespondensi asli, demonstrasi salinan asli dan demonstrasi tambahan, UI aktual dan tambahan, masalah pemilih operasi awal, dan cakupan konfirmasi penghentian dicatat. Upaya yang memegang akhir normal tidak diterapkan secara surut ke upaya awal tanpa kode akhir.

Situs ini dioperasikan oleh YURIKA, K.K. dan memperkenalkan aplikasi independen "SimpleMemo". Ini bukan artikel resmi oleh Obsidian.