Obsidian diseño de copia de seguridad
Git, recuperación de archivos, rol de almacenamiento separado

Haga una lista de lo que necesita en su repositorio y conéctela a los elementos que se comprobarán en el destino de restauración. El siguiente es un elemento para el plan, no una tabla que dice que este ejercicio ha guardado y restaurado todo.

"Hasta qué punto se debe dejar el cambio" y "el tiempo requerido para regresar" también se deciden por su propio propósito. Esta vez, no hemos medido el objetivo de RPO/RTO y el tiempo de recuperación. Determinar la frecuencia de copia y poder dejar versiones pasadas durante un cierto período de tiempo son elementos de confirmación separados.

Un ejemplo de Git es para una práctica Git履歴メモ.md. Después de confirmar el primer texto y cambiar y guardar los elementos de confirmación en el editor Obsidian real, hice una segunda confirmación. Además de eso, Saqué el blob real de la confirmación anterior al nuevo Git復元メモ.md y lo abrí con la aplicación real. El archivo original después de que se mantenga el cambio.

Los dos commits tienen una relación padre-hijo, y el blob del texto también es diferente. Solo este Markdown ha sido rastreado en Git, y la nueva nota que se restaurará, la nota para la recuperación de archivos y la configuración no se ha rastreado. No es el resultado que toda la bóveda está en la historia.

Este es el texto completo del Markdown real devuelto. El blob anterior de la demostración, el archivo restaurado y la distribución original eran el mismo byte 98 UTF-8.

# Git履歴メモ

著者作成の練習です。

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

Para comprobar en cuestión, primero lea el estado y el historial del objetivo, y seleccione la confirmación y la ruta que desea devolver. El siguiente es un ejemplo de la forma de lectura. Reemplace <commit> con el valor de su historial.

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

Seleccione el nuevo nombre no utilizado que se pueda distinguir de la nota original, lea el texto antiguo y decida qué adoptar. La operación Git de esta demostración es un shell local, y el complemento Obsidian Git, el control remoto, el push/pull, la confirmación automática y la reflexión a otro terminal no se han probado. No se trata como poder devolver archivos que no estaban incluidos en la confirmación.

La pantalla de configuración de la demostración complementaria es una interfaz de usuario en inglés. De hecho, activé el interruptor Settings → Core plugins → File recovery y abrí la configuración de recuperación de archivos. El valor inicial de Snapshot interval 5 minutos se ha cambiado a 0.05 minutos para verificación, y luego 0.5 minutos. History length mostró 7 días, pero no se ha verificado la retención de siete días.

El ajuste de 0.5 minutos es el intervalo mínimo entre entradas del historial; no significa que se guarde necesariamente una instantánea cada 30 segundos. El núcleo de esta versión tiene un temporizador de 60 segundos para reintentar los guardados pendientes. Confirmamos que las versiones A y B, guardadas en el editor real, pasaron al estado pendiente y se añadieron al historial mediante ese temporizador normal. El evaluador no escribió en la base de datos del historial ni llamó a una API de creación de historial.

1. Guarda A en el editor real. Introduzca A incluyendo "Compruebe el texto que queda antes". Revisé los archivos guardados y confirmé que estaban en espera y que aún no había historial de A.
2. Confirmar la conservación natural. Aproximadamente 60 segundos después, A entró en el historial. A continuación, lo edité a B y lo guardé, y B se incluyó en otra preservación natural después de aproximadamente 58 segundos. Dos observaciones no garantizan un tiempo universal requerido.
3. Seleccione el texto antiguo en la pantalla. Presione View para buscar notas de recuperación, seleccione la última B y la A anterior respectivamente, y lea el texto.
4. Restaurar y mostrar de nuevo. Presioné el Restore real mientras seleccionaba A. El archivo guardado coincidía con A, y después de pasar a otra nota, volví a abrir la nota de recuperación en el explorador de archivos real, y el texto era el mismo.

UI muestra "44 B" como A y "47 B" como B. El UTF-8 real utilizado para hacer coincidir el archivo de distribución es A es 110 bytes y B es 119 bytes. El valor de visualización de la interfaz de usuario no se utiliza como el número de bytes de UTF-8. Después de la restauración, la A restaurada también se agregó a la nueva línea de historial. Esta línea adicional es el resultado de la operación de restauración y la distingue de la evidencia de preservación natural de los anteriores A y B.

Este es el texto completo de la fruta A restaurada Markdown. La antigua A mostrada y el último archivo guardado eran los mismos bytes 110.

# 回復メモ

著者作成の練習です。

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

Este resultado es para devolver un texto del historial que existía en este perfil local. No es el resultado de poder guardar el historial de recuperación de archivos en un dispositivo de copia de seguridad separado. No he intentado migrar perfiles, reinstalar aplicaciones, dañar el historial de la base de datos, la retención a largo plazo o recuperar archivos eliminados.

En la demostración de copia original, tres Markdown creados por el autor se almacenaron fuera de la bóveda y se devolvieron a un nuevo destino de restauración diferente del original. Es una configuración que enlaza de 索引.md a ノート/観察メモ.md y ノート/確認メモ.md. El nombre del archivo y la ruta relativa se han conservado.

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

Después de copiar, el verificador cambió solo un texto en su bóveda de práctica y eliminó una nota. Se conservan los tres textos originales en el lado de la copia. La restauración no se sobrescribió al estado original y se hizo en otra ubicación nueva. Incluso cuando el lector practica, puedes preparar otra copia de práctica y restaurar el destino mientras conservas las notas originales.

Este es el texto completo de la nota de observación restaurada.

# 観察メモ

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

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

Cuando presioné el enlace real a la nota de confirmación del índice, el objeto que se eliminó originalmente se mostró en el destino de recuperación. " Puede volver al índice presionando "Volver al índice". Después de eso, volví a abrir el índice desde el explorador de archivos real y confirmé que los tres Markdown guardados no cambiaron.

El Markdown real del índice también publicará el texto completo.

# 索引

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

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

El objetivo es solo tres Markdown, y la configuración y los archivos adjuntos no se han copiado. La copia está en el mismo sistema de archivos ejecutable fuera de la bóveda. La confirmación de que se puede restaurar desde dispositivos de almacenamiento independientes, nubes, fallas y desastres es un elemento separado que queda en el plan de respaldo.

Los ocho Markdown son los archivos originales guardados de cada demostración. Guarda los tres ejemplos de copia con sus nombres originales en japonés y coloca las notas de observación y comprobación dentro de carpeta ノート. El navegador no crea esa carpeta automáticamente. Guarda los archivos de comparación y los ejemplos de Git y File Recovery con otros nombres, en una ubicación donde no sobrescriban ninguno de los tres conjuntos de restauración, y compáralos allí.

Distribución de caracteres en inglés URL es un alias que distingue a los estados. El enlace wiki en el cuerpo del ejemplo de copia mantiene la ruta relativa original del japonés. Si dejas el nombre en inglés como está, revisa también el enlace. El lector no importa el archivo de distribución a la aplicación real, y el historial de Git en sí no se distribuye.