Wissensinseln konsolidiert mit Obsidian & lokalem Git-Sync

Zwei inkompatible Notizformate vereinheitlicht, in ein offenes Markdown-System überführt und ohne Cloud-Abhängigkeit über Geräte synchronisiert.

Wissensinseln konsolidiert mit Obsidian & lokalem Git-Sync

Ausgangslage

Ein Kunde hatte sein Wissen über zwei Systeme verteilt: Auf Android wurden Kurznotizen mit FastNotepad gepflegt (Export in einem proprietären, JSON-ähnlichen Blockformat). Auf dem Desktop lief ein gewachsenes Wissensarchiv in Zim (Textdateien in Zim-Wiki-Syntax, teils mit Anhängen).

Das Ergebnis waren klassische Wissensinseln: unterschiedliche Formate, keine zuverlässige Synchronisation und ein hoher Reibungsverlust beim Wechsel zwischen Geräten. Zusätzlich sollten Cloud-SaaS-Lösungen (z. B. Notion) bewusst vermieden werden, weil sensible Inhalte die eigene Infrastruktur nicht verlassen sollten.

Zielbild & Anforderungen

Gesucht war eine konsolidierte Wissensbasis, die offline funktioniert, versionierbar ist und langfristig nicht von einem proprietären Datenmodell abhängt. Obsidian war hier ein pragmatischer Fit: Markdown-Dateien als Datenbasis, moderne UI, erweiterbar über Plugins, breite Community und verfügbar auf Desktop und Android.

  • Einheitliches Zielformat: Obsidian-kompatibles Markdown (eine Notiz pro Datei)
  • Migration aus beiden Quellen ohne „Copy-Paste-Projekt“ (inkl. Anhänge aus Zim)
  • Keine Cloud-Abhängigkeit: Sync über ein lokales Git-Repository auf dem NAS
  • Automatischer Hintergrund-Sync auf Desktop und Android

Rahmenbedingungen: Offline-Nutzung muss möglich bleiben, Daten bleiben on-premise, Migration muss wiederholbar und rückrollbar sein.

Lösungsweg

Der Weg war bewusst „low-tech“ im besten Sinne: offene Textformate, klare Regeln, keine Spezial-Infrastruktur. Entscheidend war, die Migration als reproduzierbaren Prozess zu bauen und den späteren Betrieb so einfach zu halten, dass er im Alltag nicht nervt.

  1. Zielstruktur definieren: Obsidian-Vault als Ordnerstruktur aus Markdown-Dateien
  2. Konverter bauen: FastNotepad-Export und Zim-Notebook nach Markdown überführen
  3. Regeln deterministisch machen (Dateinamen, Kollisionen, Anhänge, Frontmatter/Tags)
  4. Git als Sync-Transport: NAS-Repository als zentrale Quelle der Wahrheit
  5. Auto-Sync auf allen Geräten: Desktop per Obsidian Git Plugin, Android per GitSync

Umsetzung

Für die Migration entstanden zwei kleine Python-Utilities: Eines liest das FastNotepad-Exportformat und erzeugt pro Notiz eine Markdown-Datei. Das zweite konvertiert Zim-Seiten nach Obsidian-Markdown und übernimmt Anhänge (z. B. Bilder oder PDFs) in eine kompatible Ordnerstruktur.

Die Tools sind bewusst schlank gehalten (CLI, lokal ausführbar) und wurden so umgesetzt, dass sie für ähnliche Migrationen wiederverwendbar sind. Der Quellcode ist öffentlich dokumentiert: fastnotepad-to-obsidian und zim-to-obsidian.

Konkret (vereinfacht)
# 1) FastNotepad (Android) -> Obsidian Vault
fastnotepad2obsidian FastNotepad_Export.txt Vault/Inbox --by-category --tag

# 2) Zim (Desktop) -> Obsidian Vault (inkl. Anhänge)
zim2obsidian ~/Notebooks/Zim ~/Vault --dry-run
zim2obsidian ~/Notebooks/Zim ~/Vault --overwrite

# 3) Sync ohne Cloud: lokales Git-Repository auf dem NAS
cd ~/Vault
git init
git remote add origin ssh://nas.example/notes.git
git add .
git commit -m "Initial vault migration"
git push -u origin main

Wichtig ist das Prinzip: das Repository liegt on-premise, Zugriff per SSH, und die Clients synchronisieren automatisch im Hintergrund.

Ergebnis / Impact

  • Alle Notizen liegen in einem konsistenten Obsidian-Vault auf Basis von Markdown
  • Geräteübergreifende Nutzung: Desktop und Android arbeiten am selben Datenbestand
  • Keine Cloud-SaaS notwendig, trotzdem Auto-Sync im Hintergrund

Validierung über Git-Diffs, Stichproben im Vault und reproduzierbare Konvertierungsläufe (dry-run und kontrolliertes Überschreiben).

Validierung & Qualität

Bei Migrationen ist nicht die „Einmaligkeit“ entscheidend, sondern die Wiederholbarkeit. Deshalb wurden die Konvertierungsregeln deterministisch gehalten und die Migration so aufgesetzt, dass sie iterativ gefahren werden kann.

  • Deterministische Dateinamen-Regeln (Slugging plus Kollisionsauflösung)
  • Dry-Run-Mode und nachvollziehbare Logs für Review vor dem Schreiben
  • Git als Kontrollinstrument: nachvollziehbare Änderungen, einfache Rollbacks

Betrieb & Rollout

Der Cutover war schrittweise: erst konvertieren, dann im Vault prüfen, dann committen. Anschließend wurde der laufende Sync automatisiert. Auf dem Desktop übernimmt das Obsidian Git Plugin Pull/Commit/Push. Auf Android hat sich das Plugin in der Praxis als weniger stabil erwiesen, daher synchronisiert dort GitSync im Hintergrund.

  • Migration in Etappen: Import, Review, Commit, Sync
  • Konflikte minimieren: kurze Sync-Intervalle und klare Arbeitsregeln
  • Backup-Effekt: Git-Historie als zusätzliche Sicherheitsleine

Was heute anders ist

Statt Wissensinseln gibt es eine konsolidierte, offene Wissensbasis. Neue Geräte lassen sich schnell anbinden, Inhalte bleiben on-premise, und durch Markdown bleibt die Exit-Option erhalten, falls sich die Tool-Landschaft in ein paar Jahren wieder ändert.

Kurzinfo

Dauer

5 Tage

Rolle

Konzept, Tooling (Python), Migration, On-Premise Sync-Betrieb

Werkzeuge

Python, Obsidian, Git, NAS, SSH, Obsidian Git Plugin, GitSync (Android)