actgadmin/Obsidian-Plugin
1
0
Fork 0
Code Issues Pull requests Projects Releases 20 Packages Wiki Activity Actions
20 releases 29 tags
  • v0.8.0 5a55bcf7d1

    v0.8.0 — Git-Backup im Server Stable

    actgadmin released this 2026-07-10 08:07:27 +02:00 | 209 commits to master since this release

    Diese Version erfordert einen Server-Deploy. Das Docker-Image installiert jetzt git. Das Plugin ist funktional unveraendert; die Versionsnummer laeuft nur mit.

    Der Server pusht, nicht das Plugin

    Der Server committet den Vault-Stand und pusht ihn in ein Repository. Er pusht nur und liest nie zurueck — der Server bleibt die einzige Wahrheit, Git ist Historie und Notfallkopie. Damit entsteht keine zweite Konfliktlogik neben dem Drei-Wege-Merge.

    Warum dort und nicht im Plugin: Der Server hat bereits alle Dateien, laeuft auf Node, hat ein echtes Dateisystem und existiert genau einmal. Kein Wettlauf zwischen Geraeten, die denselben Vault pushen; kein Mobil-Problem (auf iOS gibt es weder child_process noch ein git); kein halbes Megabyte isomorphic-git im Plugin-Bundle.

    Zwei Entscheidungen, die den Rest tragen

    Getrenntes --git-dir. Das Repository liegt unter <dataDir>/git/<vaultId>.git, der Arbeitsbaum ist der bestehende Dateibaum des Vaults. Ohne diese Trennung laege ein .git-Verzeichnis mitten zwischen den synchronisierten Dateien — ein Client koennte es ueberschreiben, und der Sync wuerde es verteilen.

    Der Token geht ueber http.extraHeader, nie in die Remote-URL. Eine URL mit eingebettetem Token landet in .git/config, in Fehlermeldungen und in jedem Log. Fehlertexte werden zusaetzlich um einen etwaigen Authorization-Header bereinigt.

    Konfiguration

    Variable Default Bedeutung
    OSYNC_GIT_REMOTE – Repo-URL. Leer = Backup aus
    OSYNC_GIT_VAULT_ID – Welcher Vault gesichert wird. Leer = Backup aus
    OSYNC_GIT_BRANCH main Ziel-Branch
    OSYNC_GIT_USERNAME – Nutzername (Basic-Auth)
    OSYNC_GIT_TOKEN – Access-Token
    OSYNC_GIT_DEBOUNCE_MS 15000 Ruhephase vor dem Commit

    Aktiv erst, wenn Remote und Vault-ID gesetzt sind — ein halb konfiguriertes Backup saehe sonst aktiv aus, ohne etwas zu tun. Ein Sync-Lauf schreibt viele Dateien; nach der letzten Aenderung wird DEBOUNCE_MS gewartet, dann entsteht ein Commit. Schlaegt der Push fehl, bleibt der Commit lokal und der naechste Lauf holt ihn nach; der Sync ist davon nie betroffen.

    Es wird genau ein Vault gesichert. Mehrere Vaults in denselben Branch desselben Repos zu pushen wuerde sie gegenseitig ueberschreiben.

    Tests

    12 Tests gegen ein echtes Git-Repository, darunter ein Ende-zu-Ende-Lauf: eine ueber die HTTP-API hochgeladene Datei taucht im Remote auf. Geprueft wird auch, dass kein .git im Arbeitsbaum entsteht, dass ohne Aenderung kein zweiter Commit faellt, dass ein unerreichbares Remote den Server nicht abbricht und dass der Token nirgends in der Repo-Konfiguration steht.

    Downloads