Moritz Conjé
Im Beitrag über den zweiten Umzug habe ich angekündigt, dass das Wiki künftig lokal auf einer SSD liegen und sich mit dem NAS abgleichen soll. Wie sich das in der Praxis schlägt, blieb einer späteren Fortsetzung vorbehalten. Hier ist sie: Schritt für Schritt von der leeren Platte bis zum bestandenen Test in beide Richtungen, dazu eine Messung, die zeigt, was der Umbau für die Suche bringt und was nicht.
Ausgangslage: ein Wiki, viele Zugriffe
Mein Second Brain ist eine große Sammlung von Notizen: gut 20.000 Dateien, knapp ein Gigabyte. Sie liegt auf dem NAS. Der Windows-Rechner mit Obsidian arbeitet direkt dort, ebenso die Remote-Umgebung mit Claude Code. Die Dienste von VectorSearch laufen dagegen auf einem eigenen kleinen Server mit zwei Containern. Der eine liest das Wiki und schreibt Ergebnisse zurück, etwa die nächtliche Einleseroutine. Der andere zeigt es nur an. Beide griffen bisher über eine Netzwerkfreigabe auf das NAS zu.
Das funktioniert, ist aber keine gute Basis für einen Abgleich zwischen mehreren Geräten. Ein Abgleichsprogramm muss mitbekommen, wann sich eine Datei ändert. Dafür fragt es nicht ständig alles ab, sondern lässt sich vom Betriebssystem benachrichtigen, einem sogenannten Dateiwächter. Über eine Netzwerkfreigabe meldet das Betriebssystem Änderungen, die ein anderes Gerät macht, nicht zuverlässig. Diese Erfahrung stammt aus früheren Sync-Versuchen. Daraus folgt der Plan: Das Wiki liegt lokal auf dem Server, und das Abgleichsprogramm läuft direkt auf beiden Seiten, ohne Freigabe dazwischen.
Schritt 1: Die SSD vorbereiten
Eine externe SSD mit rund 240 Gigabyte hing bereits am Server. Zuerst habe ich geprüft, dass sie leer ist, indem ich sie nur lesend eingebunden habe. Danach habe ich sie mit dem Linux-Dateisystem ext4 formatiert. Es kennt echte Dateirechte und feine Zeitstempel, anders als das vorinstallierte exFAT, und ist für den Abgleich robuster. Eingebunden wird sie über ihre eindeutige Kennung statt über einen Gerätenamen, mit der Option nofail. Sie sorgt dafür, dass ein fehlendes Laufwerk den Start des Servers nicht blockiert.
Schritt 2: Wiki kopieren und Container umhängen
Das Wiki habe ich vom NAS auf die SSD kopiert und danach Dateizahl und Größe gegen die Quelle verglichen. Beides stimmte überein. Kopiert wurde nur der eigentliche Wiki-Ordner, ohne Archive und Exporte, die auf dem NAS liegen bleiben.
Beim Umhängen der Container gilt eine Regel: Die alte Verbindung darf nie verschwinden, bevor die neue geprüft ist. Sonst liefe die nächtliche Einleseroutine gegen einen leeren Ordner. Deshalb lief der Wechsel in zwei Stufen. Zuerst habe ich die SSD zusätzlich unter einem Testpfad eingebunden. Technisch ist das ein Bind-Mount: Ein Verzeichnis des Servers wird einem Container durchgereicht, als läge es in ihm. Der Container für die Anzeige bekam die SSD nur lesend, der für VectorSearch lesend und schreibend, inklusive Schreibtest. Erst als beide Container dieselbe Dateizahl sahen wie über die Freigabe, habe ich den echten Pfad umgestellt und den alten Eintrag auskommentiert, nicht gelöscht. Der Rückweg ist dokumentiert. Danach war der Endpunkt der Suche erreichbar, und es gab keine fehlgeschlagenen Dienste.
Schritt 3: Syncthing auf beiden Seiten
Syncthing gleicht Ordner direkt zwischen Geräten ab, ohne zentralen Server. Jedes Gerät führt Buch über seine Dateien und deren Prüfsummen. Ändert sich etwas, überträgt Syncthing nur das Neue. Auf dem Server habe ich es aus der Paketverwaltung installiert, als Dienst gestartet und die Weboberfläche nur lokal erreichbar gelassen. Der Wiki-Ordner dort ist die SSD, mit Dateiwächter und einem Papierkorb: Gelöschte oder überschriebene Dateien bleiben 30 Tage in einem Versionsordner.
Auf dem NAS gibt es Syncthing als App aus dem Katalog. Vor der Installation habe ich einen Snapshot des Datensatzes angelegt, einen Schnappschuss des Dateistands, zu dem ich jederzeit zurückkehren kann. Im Installationsformular waren drei Entscheidungen wichtig:
- Speicher: Das Wiki wird als vorhandener Ordner des NAS eingebunden. Die Voreinstellung würde einen neuen, leeren Speicher anlegen, und das Wiki würde nie abgeglichen.
- Rechte: Die App läuft mit dem Benutzer, dem der Wiki-Ordner ohnehin gehört, und ändert keine Zugriffsrechte.
- Sync-Ports: Eigene Ports nach außen, damit sich die Seiten gezielt finden.
Schritt 4: Beide Seiten koppeln
Normalerweise finden sich Syncthing-Geräte im Heimnetz selbst. Hier ließ sich der Sync-Port der NAS-App nicht auf den Standard legen, deshalb habe ich beiden Seiten die Adresse der Gegenseite fest eingetragen. Der Ordner wurde auf dem NAS zunächst pausiert angelegt, damit vor dem ersten Abgleich alles stand. Dazu gehört eine Ignorier-Liste, die nur den Wiki-Ordner durchlässt, weil auf dem NAS darüber noch anderes liegt. Es gilt die erste passende Zeile:
!/<wiki-ordner>
/*Die erste Zeile erlaubt den Wiki-Ordner, die zweite ignoriert alles Übrige. Zusätzlich habe ich den Rechte-Abgleich abgeschaltet. Die SSD-Dateien trugen durch die frühere Freigabe alle die gleichen offenen Rechte, und die sollten nicht auf das NAS übertragen werden. Erst danach habe ich den Ordner freigegeben.
Der erste Abgleich
Nach rund anderthalb Minuten zeigten beide Seiten den Zustand idle (alles abgeglichen), und es fehlte nichts mehr. Das ging so schnell, weil beide Seiten schon befüllt waren: Syncthing verglich im Wesentlichen Prüfsummen und übertrug kaum Daten. Dass die Versionen 2.x auf dem NAS und 1.x auf dem Server problemlos zusammenarbeiten, war eine angenehme Nebenbeobachtung.
Weil Syncthing das echte Dateisystem liest, förderte der erste Abgleich ein paar Abweichungen zutage, die ich geprüft und bereinigt habe. Seitdem überwacht eine stündliche Übersicht den Bestand an Konfliktdateien. Sie arbeitet nur lesend, schlägt Maßnahmen vor und löscht nichts. Ihr Ergebnis zeigt eine Ampel im Dashboard des Second Brains, samt Begründung pro Konflikt. Erledigte Fälle lassen sich dort auf die letzten vier Wochen, drei oder sechs Monate eingrenzen, offene Konflikte erscheinen immer vollständig. Nach dem Aufräumen standen beide Seiten bei gut 20.000 Dateien, ohne offene Konflikte.
Der Test in beide Richtungen
Ob ein Abgleich taugt, zeigt sich im Alltag. Deshalb habe ich Testdateien auf der SSD und direkt auf dem NAS angelegt, geändert und gelöscht und jeweils die Zeit bis zur Ankunft auf der Gegenseite gemessen:
| Aktion | SSD nach NAS | NAS nach SSD |
|---|---|---|
| Anlegen | 12 s | 10 s |
| Ändern | 10 s | 10 s |
| Löschen | 12 s | 10 s |
Zehn Sekunden davon sind die Wartezeit, die ich dem Dateiwächter nach einer Änderung eingestellt habe. Die beiden Container sahen neue Dateien nach einer Sekunde, weil sie direkt auf die SSD zugreifen. Konflikte gab es keine. Die gelöschten Testdateien liegen 30 Tage im Papierkorb. Damit entsteht der Weg, den ich mir vorgenommen hatte: Eine Änderung im Windows-Rechner oder in der Remote-Umgebung landet auf dem NAS und kurz darauf auf der SSD. Was die nächtlichen Dienste auf der SSD schreiben, erscheint genauso auf dem NAS und in Obsidian.
Neustart und Absicherung
Zum Alltag gehört, dass Dienste neu starten. Den Abgleichsdienst auf dem Server habe ich dafür testweise neu gestartet: Nach fünf Sekunden war er wieder mit dem NAS verbunden, nach zehn war alles abgeglichen. Eine Schwachstelle lag in der Einbindung. Wegen der Option nofail startet der Server auch dann, wenn die SSD nicht erkannt wird, und die Container würden einen leeren Ordner statt des Wikis sehen. Deshalb starten die beiden Container jetzt nur noch, wenn die SSD eingebunden und das Wiki darauf vorhanden ist. Fehlt sie, bleiben sie gestoppt, statt mit leerem Wiki zu laufen. Das dafür nötige kleine Startskript des Virtualisierungssystems habe ich mit eingebundener und mit fehlender SSD getestet (die fehlende habe ich simuliert) und beide Container damit einmal normal gestartet.
Was sich für die Suche ändert
Die ehrliche Antwort lautet: nicht viel, und das ist zu erwarten. Eine Suchanfrage läuft gegen die Datenbank mit den Vektoren, nicht gegen Dateien. Ob das Wiki auf der SSD oder hinter einer Freigabe liegt, spielt dafür keine Rolle. Erreichbar bleibt die Suche wie zuvor über das zentrale Gateway: Eine Anfrage nach dem Umbau lieferte wie gewohnt Treffer. Das Wiki liest vor allem die nächtliche Einleseroutine. Beim Dateizugriff direkt zeigt sich aber ein deutlicher Unterschied, den ich auf dem Server gemessen habe:
| Messung | Über die Freigabe | SSD |
|---|---|---|
| Dateiliste über das ganze Wiki | 0,59 s | 0,03 s |
| Alle rund 15.300 Notizen komplett lesen | 21,2 s | 0,4 s |
Das ist eine Größenordnung von etwa Faktor 20 bis 50, aber kein exakter Wert. Es war ein einzelner Tag mit einer Messreihe, und der SSD-Wert dürfte zum Teil aus dem Zwischenspeicher des Betriebssystems stammen. Für die Nachtläufe gibt es einen Ausgangswert: Die gesamte Routine (Einlesen, Verknüpfungen und Aktualisierung der Zusammenhänge) brauchte zuletzt über die Freigabe 47 Sekunden, davon 38 für das Einlesen. Der erste Lauf von der SSD steht noch aus. Ich rechne nur mit kleinen Unterschieden, denn sie lägen im Sekundenbereich, und bei vielen neuen Notizen dauert das Erzeugen der Vektoren ohnehin länger, unabhängig vom Speicherort. Das Ergebnis trage ich nach.
Was ich anderen mitgeben würde
- Snapshot vorab: Vor jedem Eingriff in den Datenbestand einen Schnappschuss anlegen. Er kostet fast nichts und ist die Rückfahrkarte.
- Pausiert starten: Neue Sync-Ordner zunächst pausiert anlegen und die Ignorier-Liste vor dem Start setzen.
- Erstbefüllung dem Sync überlassen: Wer Daten vorab kopiert, sollte mit einem Abgleich auf dem echten Dateisystem rechnen und währenddessen schreibende Prozesse anhalten.
- Rechte nicht mitschleppen: Bei vorbefüllten Daten den Rechte-Abgleich abschalten.
- Feste Adressen: Wenn die automatische Suche nach Geräten nicht durchkommt, die Adresse der Gegenseite eintragen.
- Zugang absichern: Nach der Installation ein Passwort für die Weboberfläche setzen und temporäre Zugangsschlüssel nach der Einrichtung wieder löschen.
Fazit
Aus der Ankündigung ist ein laufender Aufbau geworden: Das Wiki liegt lokal auf einer SSD, beide Container arbeiten direkt darauf, und Syncthing hält sie in beide Richtungen mit dem NAS synchron, in rund zehn Sekunden und ohne Konflikte. Der Wechsel lief ohne längeren Ausfall, weil der alte Weg bis zur Prüfung des neuen bestehen blieb und nur die beiden Container kurz neu starten mussten. Fehlt die SSD einmal, laufen sie nicht mit leerem Wiki weiter. Für die Suche selbst bringt der Umbau wenig, für alles drumherum aber ein belastbares Fundament: schnellerer Dateizugriff, ein Abgleich, der zuverlässig mitbekommt, was sich ändert, und ein Stand, den jedes Gerät sehen kann.
Ausblick
Bisher sind nur NAS und Server gekoppelt. Als Nächstes sollen Handy und Laptop als weitere Geräte dazukommen. Wie sich der erste Nachtlauf von der SSD schlägt, steht dann als Nachtrag hier.
