Eine Anmerkung von Zima
Vielen Dank, Ted, dass du den ZimaCube 2 als ein System dokumentierst, das schrittweise wächst, statt als fertiges Gerät. Dein Pioneer-Build hält die erfolgreichen Upgrades, die Speicher-Benchmarks, die Immich-Migration und die Komponenten fest, die sich widersetzten — darunter ein Thunderbolt-Pfad, der schließlich zu einer OCuLink-Lösung wurde. Indem du Messungen, Workarounds, Fehler und sich ändernde Hardware-Entscheidungen während der Entwicklung des Builds veröffentlichst, gibst du der Community etwas, das nützlicher ist als ein endgültiges Datenblatt: eine Aufzeichnung darüber, wie sich ein echtes ZimaOS-Homelab entwickelt.
— Zima
Ted-knight kennenlernen
Ted-knight dokumentiert einen der systematischsten ZimaCube-2-Builds im Pioneer-Programm. Sein ZimaCube 2 Build ist nicht auf eine endgültige Konfiguration ausgerichtet. Stattdessen ist das Projekt in Phasen unterteilt, wobei jede Ebene getestet wird, bevor die nächste hinzugefügt wird.
Das Ziel hinter dem Build ist klar: Heute ein NAS schaffen, dem wichtige Daten anvertraut werden können, und gleichzeitig genügend Spielraum für Self-Hosting, Medien, lokale KI und andere Workloads in der Zukunft lassen. Das hat Ted durch Speicherarchitektur, ZFS, btrfs, RAM- und NVMe-Upgrades, OCuLink-Erweiterungen, Benchmarking, die Integration von ZimaOS, die Immich-Migration und eine immer detailliertere Roadmap für die mögliche Weiterentwicklung des Systems geführt.
Er begann mit dem ZimaCube 2 Standard: einem System mit Intel Core i3-1215U, 8 GB DDR5 und einem 256-GB-NVMe-Systemlaufwerk. Die ursprüngliche Konfiguration blieb nicht lange unverändert.
Die Speichergrundlage schaffen, bevor weitere Dienste hinzugefügt werden
Teds oberste Priorität war nicht, den Server mit Anwendungen zu füllen. Zuerst musste entschieden werden, wo die verschiedenen Datentypen gespeichert werden sollten.
Das resultierende System nutzt mehrere Speicherebenen mit bewusst unterschiedlichen Aufgaben. ZimaOS bleibt auf der eigenen 256-GB-Kingston-NVMe. Eine Crucial P510 mit 2 TB NVMe wurde zu Arctic-Storage, einer btrfs-Ebene für AppData, Docker-Images, Datenbanken und andere aktive Workloads. Vier 2-TB-NVMe-Laufwerke bilden glacier, einen ZFS-RAIDZ1-Pool mit rund 5,5 TB nutzbarem Speicherplatz. Später wurden vier 4-TB-Seagate-IronWolf-Laufwerke zu einem 12-TB-btrfs-RAID5-Pool für umfangreiche Medienbibliotheken und weniger häufig benötigte Daten.
Bei der Architektur geht es weniger darum, dass sich jedes Laufwerk gleich verhält, sondern vielmehr darum, den Speicher auf die jeweilige Arbeitslast abzustimmen. Datenbanken mit vielen zufälligen I/O-Vorgängen gehören auf die schnelle P510. Größere sequenzielle Arbeitslasten und Daten, die von ZFS-Prüfsummen und Redundanz profitieren, können auf Glacier liegen. Große Mediendatenmengen können auf die IronWolf-Tier mit höherer Kapazität verschoben werden.
Als Thunderbolt 4 nicht funktionierte, änderte sich die Architektur
Einer der nützlichsten Aspekte von teds Projekt ist, dass die fehlgeschlagenen Experimente in der Dokumentation erhalten bleiben.
Der ursprüngliche Plan war, ein Vier-NVMe-Gehäuse Aoostar TB4S-OC über Thunderbolt 4 mit dem ZimaCube 2 zu verbinden. Ted testete verschiedene 40-Gbit/s-Kabel, beide Thunderbolt-Anschlüsse, eine externe Stromversorgung und das Verhalten des zugrunde liegenden Kernels, doch das Gehäuse konnte weiterhin keine stabile PCIe-Verbindung herstellen.
Die Untersuchung führte schließlich zur Wechselwirkung zwischen der Thunderbolt-Konfiguration von ZimaOS und dem ASMedia-ASM2462PDX-Controller im Gehäuse. Statt den ursprünglichen Plan weiterhin zu erzwingen, änderte ted die Architektur.
Ein PCIe-x4-zu-OCuLink-Adapter wurde in Steckplatz 1 eingesetzt. Das Aoostar-Gehäuse wechselte von Thunderbolt zu einer direkten OCuLink-Verbindung. Beim ersten Start wurden alle vier NVMe-Laufwerke erkannt, ohne die Tunnel- und Autorisierungsprobleme, die die Thunderbolt-Konfiguration verhindert hatten.
Die Änderung wirkte sich auch auf spätere Pläne aus. Steckplatz 1 ist nun durch den Speicher belegt, während die beiden Thunderbolt-Anschlüsse für künftige Experimente wie direkte Netzwerkverbindungen oder einen anderen eGPU-Weg verfügbar bleiben. Eine fehlgeschlagene Verbindung wurde nicht einfach zu einer Randnotiz bei der Fehlersuche; sie änderte die Roadmap der gesamten Maschine.
Speicher benchmarken, statt anzunehmen, welche Tier schneller war
Sobald der Speicher vorhanden war, maß Ted seine Leistung.
In Phase 1.5 verwendet er fio , um den Glacier-ZFS-RAIDZ1-Pool mit Arctic-Storage zu vergleichen, statt „NVMe“ als eine einzige Leistungskategorie zu behandeln. Der Kalt-Benchmark zeigte, dass Glacier 1.726 MB/s bei sequenziellen Schreibvorgängen und 2.591 MB/s bei sequenziellen Lesevorgängen erreichte, während die Arctic-Ebene mit einem einzelnen Laufwerk bei zufälligen I/O-Zugriffen deutlich stärker war und an ihrem ursprünglichen Standort 205.588 zufällige 4K-Lese-IOPS erreichte.
Das interessantere Ergebnis zeigte sich, als der ZFS-ARC ins Spiel kam. Wiederholte Lesezugriffe von Glacier konnten aus dem RAM bedient werden, statt erneut auf die NVMe-Laufwerke zuzugreifen. Mit der früheren 16-GB-Speicherkonfiguration erreichten zufällige Warm-Lesezugriffe ungefähr 83.929 IOPS statt des kalten Ergebnisses von 14.781 IOPS.
Diese Erkenntnis beeinflusste später eine weitere Hardwareentscheidung. Ted rüstete das Gerät mit zwei 16-GB-DDR5-Modulen auf 32 GB auf und wechselte damit von Einkanal- zu Zweikanal-Speicher. Nach der Aufrüstung stiegen die zufälligen Warm-ARC-Lesezugriffe erneut auf 126.816 IOPS – eine gemessene Verbesserung von 51 Prozent gegenüber dem früheren Ergebnis.
Die Benchmarks stellten auch die ursprüngliche Platzierung der Crucial P510 infrage. Im 7. Schacht des Standardmodells wurde der sequenzielle Durchsatz durch die Bridge begrenzt. Ted versetzte das Laufwerk in den integrierten M.2-Steckplatz und maß eine Steigerung der sequenziellen Lesegeschwindigkeit von 874 MB/s auf 1.677 MB/s, während die zufällige 4K-Leseleistung von 205.588 auf 403.078 IOPS stieg.
Die Erkenntnis war nicht einfach, dass ein Steckplatz schneller war. Die Messungen veränderten, wo Workloads platziert werden sollten und welche Aufrüstungen sich tatsächlich lohnten.
ZFS neben ZimaOS einsetzen
Der Aufbau zeigt außerdem eine interessante Grenze zwischen dem, was ZimaOS nativ verwaltet, und dem, was ein erfahrener Benutzer darunter ergänzen kann.
Ted verwendet für Arctic-Storage und den IronWolf-Pool bewusst btrfs, da sich diese Volumes nahtlos in ZimaOS integrieren. Der Glacier-Pool ist anders. Er wurde über die Kommandozeile als ZFS-RAIDZ1 erstellt und bietet Ted ZFS-Datasets, Prüfsummen, ARC-Caching, Snapshots und ein Speichermodell, das besser zu einigen seiner geplanten Workloads passte.
Diese Flexibilität hat jedoch einen kleinen Nachteil: Über die Kommandozeile erstellte ZFS-Pools erscheinen in der Oberfläche nicht als native ZimaOS-Speichervolumes.
Teds Workaround ist einfach und praxisnah. Er stellt die einzelnen ZFS-Datasets über Symlinks unter /DATA, sodass Pfade wie Glacier-Dokumente, Medien, Backups und VM-Speicher in der ZimaOS-Datei-App angezeigt werden können, während der zugrunde liegende Pool weiterhin über ZFS verwaltet wird.
Er stellte ein weiteres Problem bei der Speicherauslastung fest. ZimaOS kann einen großen Teil des RAM als „belegt“ melden, wenn der ZFS-ARC ansonsten ungenutzten Speicher füllt. Bei btop und ARC-Statistiken erzählen eine aussagekräftigere Geschichte: Der Cache belegt Speicher, weil dieser verfügbar ist, und ZFS kann ihn freigeben, sobald Anwendungen mehr Speicher benötigen.
Genau diese Art von Feedback ist bei einem Pioneer-Aufbau wichtig. Ted zeigt nicht nur, was mit ZimaOS funktioniert; er dokumentiert auch, wo eine fortgeschrittene Speicherkonfiguration an die Grenzen der aktuellen Benutzeroberfläche stößt und was er tut, wenn dieser Punkt erreicht ist.
Eine bestehende Immich-Bibliothek verschieben, ohne ihre Historie zu verlieren
Die Speicherarchitektur wird deutlich wichtiger, sobald nicht ersetzbare Daten darauf gespeichert werden.
Für Ted war dieser Test Immich. Er hatte bereits eine Immich-Instanz auf einem älteren DIY-ZimaOS-Server laufen und wollte sie auf den ZimaCube 2 umziehen, ohne von vorn beginnen zu müssen.
Die Migration umfasste 14.505 Fotos und 925 Videos – insgesamt 134 GiB. Die wichtigen Daten beschränkten sich jedoch nicht auf die Bilddateien. Alben, Personen, Gesichtserkennung, Erinnerungen, geteilte Links und andere Metadaten lagen in PostgreSQL.
Über die ZimaOS-Dateien-App im LAN kopierte Ted beide /DATA/Gallery/immich und das vollständige /DATA/AppData/immich Verzeichnis, einschließlich pgdata. Die Quell-Immich-Instanz wurde vor dem Kopieren beendet, damit die PostgreSQL-Daten konsistent blieben.
Nach der Migration blieben Konto, Alben, Gesichtsinformationen, Erinnerungen und Bibliothek vollständig erhalten, ohne gemeldeten Datenverlust. Anschließend überprüfte Ted die PostgreSQL-Datenbank direkt, anstatt davon auszugehen, dass eine erfolgreiche Anmeldung bedeutete, dass alles erhalten geblieben war.
Wenn Sie eine ähnliche Umstellung planen, führt unser Immich-Migrationsleitfaden für ZimaCube 2 durch dieselbe wichtige Unterscheidung: Nur die Medienbibliothek zu verschieben reicht nicht aus – die Datenbank muss mit umziehen.
Von einer Migration mit 134 GiB zu 725 GiB selbst gehosteter Fotos und Videos
Die Immich-Phase endete nicht mit dem erfolgreichen Abschluss der Migration des alten Servers.
Was als Übertragung einer bestehenden ZimaOS-Bibliothek begann, entwickelte sich zu einer viel umfassenderen Abkehr davon, iCloud als primären Speicherort für Teds Fotos und Videos zu verwenden. Sein iPhone begann, die ursprüngliche iCloud-Bibliothek in Immich zu übertragen, das auf dem ZimaCube 2 läuft.
Am Ende dieser Phase enthielt der Server 63.665 Dateien mit insgesamt 725 GiB: 55.604 Fotos und 8.061 Videos. Die iCloud-Übertragung selbst umfasste etwa 655 GB, wobei 4K-Videos den größten Teil dieses Speicherplatzes beanspruchten.
Das Ziel bestand nicht darin, so zu tun, als ließe sich jeder Apple-Cloud-Dienst ersetzen. Ted stellte weiterhin Gerätesicherungen, Nachrichten und andere iOS-spezifische Daten fest, für die ein kleinerer iCloud-Tarif sinnvoll ist. Die Änderung war gezielter: Die große Foto- und Videosammlung sollte auf einen Speicher verschoben werden, den er selbst kontrolliert, während Cloud-Dienste erhalten bleiben, die weiterhin einen nützlichen Zweck erfüllen.
Diese Entscheidung brachte auch eine neue Verantwortung mit sich. Eine selbst gehostete Fotobibliothek ist nur dann sicherer als eine Cloud-Kopie, wenn sie ordnungsgemäß gesichert wird. Teds Migrationsnotizen gehen daher auf eine zweite Kopie auf TrueNAS ein und schaffen die Grundlage für die umfassendere 3-2-1-Backup-Phase, die noch auf der Roadmap steht.
Aufbauend auf dem, was ZimaOS einfach macht – und Messung des Rests
Ted entschied sich bewusst für ZimaOS. Nach jahrelanger Nutzung von Synology und als langjähriger CasaOS-Nutzer wollte er das übersichtlichere, auf Docker ausgerichtete Anwendungsmodell beibehalten und zugleich weiterhin Zugriff auf das zugrunde liegende System haben, wenn der Aufbau etwas Anspruchsvolleres erforderte.
Mehrere Teile des Projekts profitieren von diesem Gleichgewicht. Das integrierte AppData-Migrationstool verschob die Docker-Anwendungsdaten vom Systemlaufwerk auf Arctic-Storage, ohne jede App neu aufbauen zu müssen. Die Files-App stellte den LAN-Workflow bereit, der für die Immich-Migration verwendet wurde. Zu den nativen Tools gehören fio, zpool, zfs, nvme, und iostat ermöglichte es, die Speicherarchitektur unterhalb der grafischen Oberfläche zu messen und zu verwalten.
Andere Teile zeigen, wo die Erfahrung noch weniger integriert ist. Über die CLI erstellter ZFS-Speicher benötigt den Symlink-Workaround. ARC macht die standardmäßige RAM-Angabe leicht missverständlich. Das Verhalten von Thunderbolt erzwang eine Neugestaltung der Hardware.
Diese Beobachtungen machen das Projekt wertvoller als eine Präsentation, bei der jedes Experiment auf Anhieb funktioniert. Ted dokumentiert die Grenze zwischen einer einfachen ZimaOS-Erfahrung und der anspruchsvolleren Homelab-Arbeit, die beginnt, sobald man beschließt, diese Grenze zu überschreiten.
Was bereits aufgebaut ist – und was noch auf der Roadmap steht
Der Titel von Teds Repository beschreibt das Ziel als ein einfaches, KI-gestütztes NAS, doch das Projekt wird bewusst in Phasen aufgebaut.
Das Fundament ist bereits vorhanden. Der Tiered Storage läuft. Der Glacier-ZFS-RAIDZ1-Pool ist betriebsbereit. Arctic-Storage wurde auf den integrierten M.2-Steckplatz verschoben. Der Arbeitsspeicher wurde auf 32 GB im Dual-Channel-Betrieb erweitert. Der IronWolf-RAID5-Pool ist vorhanden. Die Speicherbenchmarks wurden abgeschlossen. Die Immich-Migration und die umfassendere Konsolidierung der iCloud-Fotos sind abgeschlossen.
Die Medienschicht wächst noch. Der IronWolf-Pool wurde für umfangreiche Medienbestände erstellt, während Jellyfin und der umfassendere *arr-Stack weiterhin Teil der laufenden Arbeiten in Phase 2 sind.
Die KI-Ebenen liegen noch vor uns. Teds Fahrplan sieht derzeit CPU-only-Ollama-Tests in Phase 4a vor, gefolgt von einer RTX-4090-eGPU-Option in Phase 4b und semantischer Suche über den lokalen Speicher in Phase 5.
Diese Unterscheidung ist wichtig. Der ZimaCube 2 wird bereits durch Speicherplatzierung, Speicherkapazität, PCIe-Entscheidungen und Workload-Planung auf lokale KI vorbereitet, aber das Projekt ist noch nicht an dem Punkt angelangt, an dem GPU-Inferenz als abgeschlossenes Ergebnis dargestellt werden sollte.
Für Leser, die diese zukünftige Richtung bereits jetzt erkunden möchten, zeigt unser Leitfaden zu lokaler KI auf dem ZimaCube 2, wie Ollama, Arbeitsspeicher, PCIe-Erweiterungen und spätere GPU-Upgrades in einen ähnlichen Homelab-Fahrplan passen können.
Ein Aufbau, der sich mit den Belegen verändert
Das beständigste Muster in teds Projekt ist weder ZFS noch Immich noch eine bestimmte Hardwarekomponente. Es ist die Bereitschaft, eine Entscheidung zu ändern, nachdem gemessen wurde, was tatsächlich passiert ist.
Das Thunderbolt-Gehäuse funktionierte nicht, daher wurde der Speicherpfad auf OCuLink umgestellt.
Die P510 konnte ihren potenziellen Nutzen im 7. Schacht nicht ausschöpfen und wurde daher in den integrierten M.2-Steckplatz versetzt.
ZFS ARC schnitt besser ab als erwartet, sodass Arbeitsspeicher zu einem Leistungsupgrade und nicht nur zu zusätzlicher Kapazität wurde.
Eine 134-GiB-Immich-Migration verlief ohne Datenbankverlust, sodass sich das Experiment auf die Auslagerung von mehreren hundert weiteren Gigabyte aus iCloud ausweitete.
Jede Phase hinterlässt Messwerte, Befehle, Fehler und aktualisierte Annahmen für die nächste Phase. Dadurch ist das Repository auch für Personen nützlich, die nicht exakt dieselbe Speicherkonfiguration aufbauen.
Die Geschichte wird noch geschrieben
Die Geschichte von ted-knight und Zima wird noch geschrieben. Der ZimaCube 2 begann als 8-GB-Standardmodell und ist bereits zu einem mehrstufigen Speichersystem mit btrfs, ZFS RAIDZ1, OCuLink-NVMe-Erweiterung, 32 GB Dual-Channel-Speicher, einem IronWolf-RAID5-Archiv und einer selbst gehosteten Immich-Bibliothek mit Hunderten Gigabyte persönlicher Medien geworden.
Die nächsten Phasen sind bewusst noch offen: Jellyfin und der Media-Stack, robustere Backup-Abläufe, lokale KI ausschließlich auf der CPU, eine spätere GPU-Option, semantische Suche und alles, was ted im weiteren Verlauf aufgrund der Messwerte neu bewerten muss.
Wenn du den Aufbau verfolgen möchtest, während diese Phasen vom Fahrplan zu tatsächlichen Ergebnissen werden, folge teds laufendem ZimaCube-2-Aufbau auf GitHub.
