Im ersten Umzug landete der Stack auf dem NUC 2, der ihn mit anderen Diensten teilen musste und dafür nur knapp dimensioniert war. Die Folgen zeigten sich beim Chunking: ein Ingest, der auf der Maschine zweistellige Stunden gedauert hätte. Ob der NUC 2 die Endstation war? Nein. Am selben Tag, an dem eine neu angeschaffte, ausschließlich für die Second-Brain-Dienste bestimmte Maschine für Proxmox bereit war, stand der nächste Umzug an.
Warum nicht einfach die Dateien kopieren?
Eine Datenbank lässt sich auf zwei Wegen umziehen. Entweder werden die rohen Dateien des Datenspeichers kopiert, oder die Datenbank erzeugt eine Momentaufnahme, einen Dump, den die Zielmaschine wieder einliest. Der erste Weg ist schnell, kann aber mitten im Betrieb inkonsistente Zustände erwischen und ist an die genaue Software-Version gebunden. Der zweite garantiert einen sauberen, in sich stimmigen Stand. Ich habe bewusst den Dump gewählt, und zwar einen frischen. Im Ordner des Stacks lagen noch mehrere Dump-Dateien aus früheren Wochen. Eine davon zu nehmen, wäre bequem gewesen, hätte aber einen veralteten Stand ohne Chunking und Nachträge migriert.
Der Ablauf
Der Compose-Stack wurde unverändert auf die neue Maschine übertragen, so wie der portable Ansatz es von Anfang an vorsah. Danach wurde der Dump wieder eingespielt und das Embedding-Modell neu geladen. Beim Modell geht nichts verloren, denn es ist nur ein Programmbaustein und enthält keine eigenen Daten. Der Stack bekam dabei deutlich mehr Luft: vier Rechenkerne und 8 GB Arbeitsspeicher statt zwei Kerne und 3 GB auf dem NUC 2.
Die Rolle der neuen Maschine
Die neue Maschine ist kein weiterer Rechner für alles Mögliche, sondern der feste Platz für die gesamte Second-Brain-Dienstfamilie. Es handelt sich um einen kompakten Mini-PC mit Ryzen-5-Prozessor, auf 32 GB Arbeitsspeicher aufgerüstet und mit einer schnellen NVMe-Festplatte. Das vorinstallierte Windows musste der Virtualisierungsumgebung Proxmox weichen. Dort gilt wie im restlichen Homelab das Muster, jedem Zweck eine eigene, schlanke Container-Umgebung zu geben. Neben der Suche sind vorgesehen:
- Ein Dashboard als Übersicht über den Zustand des Second Brains.
- Ein zentrales Gateway, das den Zugang zu den Werkzeugen absichert. Das ist das Thema des nächsten Teils.
- Die Rollen des Redakteurs und des Prozess-Agenten als weitere Werkzeuge, die eine KI-Sitzung aufrufen kann.
- Ein Web-Clip-Dienst, der Webseiten direkt vom Smartphone als Notiz ablegt.
Eine Grafikkarte fehlt bewusst. Alle Aufrufe großer Sprachmodelle laufen weiterhin extern über deren Schnittstellen, lokal wird nur das kleine Embedding-Modell aus dem Modellvergleich berechnet. Getrennt bleibt außerdem die Umgebung für den Fernzugriff des Redakteurs, damit private Ordner nicht versehentlich mit eingebunden werden. Der Nutzen der eigenen Maschine: Die Dienste konkurrieren nicht mehr mit anderen Servern um Ressourcen, und jeder Zweck lässt sich einzeln sichern und zurücksetzen.
Nicht glauben, sondern zählen
Ob ein Umzug gelungen ist, sagt "lief durch" nicht. Ich habe deshalb nachgezählt: In der Datenbank steht in jeder Zeile ein Chunk. Auf der alten und der neuen Instanz zählte ich 16.729 zu 16.729 Zeilen, exakt identisch. Die Zahl ist deutlich höher als die rund 1.750 Notizen aus früheren Teilen, weil aus jeder Notiz seit dem Chunking mehrere Zeilen geworden sind. Ein anschließender Suchtest über den MCP-Server lieferte reale, relevante Treffer.
Sicherheitsnetz und Aufräumen
Die Client-Anbindung des Redakteurs wurde auf die neue Adresse umgestellt. Für ihn ändert sich sonst nichts, nur die Geschwindigkeit. Die alte Instanz blieb zunächst als Rückfallebene stehen. Geprüft habe ich es später: Die nächtlichen Einleseläufe der neuen Maschine liefen vom ersten in der Nacht nach dem Umzug bis zum 14. September fehlerfrei, die alte Instanz war zu diesem Zeitpunkt nicht mehr erreichbar. Außerdem ist die Verbindung zur Netzwerkfreigabe des NAS auf der neuen Maschine dauerhaft eingerichtet und nicht mehr pro Sitzung von Hand.
Der nächste Ausbau: eine SSD für das Wiki
Bisher liegt das Wiki ausschließlich auf dem NAS, und jeder Dienst greift per Netzwerkfreigabe darauf zu. Für die neue Maschine kommt deshalb ein weiterer Baustein dazu: Eine externe SSD (rund 240 GB) soll das Wiki lokal vorhalten und wechselseitig mit dem NAS abgeglichen werden. Sie ist inzwischen geliefert und wird in den nächsten Tagen initialisiert und im Abgleich erprobt. Eine Änderung auf einer Seite kommt dann automatisch auf der anderen an. Die Dienste lesen lokal statt übers Netz, und die Maschine kann später selbst Notizen schreiben, ohne dass sie in einem Silo enden. Die Reihenfolge ist dabei bewusst gewählt:
- Dateisystem: Die SSD wird mit einem Linux-Dateisystem (ext4) formatiert statt mit exFAT, das weder echte Dateirechte noch feine Zeitstempel kennt.
- Kopieren und prüfen: Das Wiki umfasst rund 670 MB und 17.200 Dateien, klein genug für einen direkten Kopiervorgang. Danach werden Dateizahl und Größe gegen die Quelle verglichen.
- Umhängen: Die SSD wird unter demselben Pfad eingebunden, den die Dienste bisher für die Netzwerkfreigabe nutzen. Erst wenn das geprüft ist, wird die alte Verbindung entfernt. Andernfalls liefe die nächtliche Einleseroutine gegen einen leeren Ordner.
- Abgleich einrichten: Dafür ist Syncthing vorgesehen, auf beiden Seiten direkt auf dem jeweiligen Gerät, nicht mit einer Netzwerkfreigabe dazwischen. Aus früheren Sync-Versuchen stammt die Lektion, dass Änderungen über eine Freigabe nicht zuverlässig sofort erkannt werden.
- Test in beide Richtungen: Eine Änderung auf dem NAS muss auf der SSD ankommen, eine Änderung auf der SSD zurück auf dem NAS.
Der Pfad bleibt in allen Schritten stabil. An den Diensten und an der Anbindung des Redakteurs ändert sich nichts. Offen ist noch die genaue Aufteilung der Geräte im Sync.
Fazit
Der Umzug war das risikoärmste Stück der ganzen Reihe, weil der Stack fertig und portabel war. Trotzdem lohnt sich die Sorgfalt: ein frischer Stand statt bequemer Altdateien, nachgezählt statt geglaubt, und eine alte Instanz als Sicherheitsnetz, solange der Beweis der Praxis noch aussteht. Mit der neuen Maschine hat das Second Brain jetzt einen festen Ort, an dem weitere Dienste Platz finden.
Ausblick
Damit läuft VectorSearch auf eigener Hardware, aber noch am zentralen Zugang vorbei: Der Redakteur spricht den Dienst direkt an, ohne vorgeschaltete Zugangskontrolle. Wie ein vorgeschalteter Zugang mit echten Zugriffsrechten aussieht, zeigt der nächste Teil. Wie sich der Abgleich zwischen SSD und NAS in der Praxis schlägt, bleibt einer späteren Fortsetzung vorbehalten.