Eine Nachricht von Zima
Vielen Dank, MorgothTheBauglir, dass du gezeigt hast, wie weit eine kompakte Home-Server-Plattform gehen kann, wenn Erweiterbarkeit als Designwerkzeug und nicht als feste Grenze verstanden wird. Von der Entdeckung von ZimaOS auf einem DIY-NAS bis dazu, ein ZimaBoard 2 zum Steuerungspunkt eines Speichersystems mit mehr als 350 TB zu machen, spiegelt deine Arbeit genau die praxisnahe Experimentierfreude wider, die Self-Hosting-Communities wertvoll macht.
Wir schätzen besonders, dass du mehr als nur die endgültige Kapazität genannt hast. Du hast den Aufbau dokumentiert, die Hardwareauswahl und die damit verbundenen Kompromisse erklärt, Fragen anderer Homelab-Nutzer beantwortet und offen darüber berichtet, wie das System weiterwuchs und schließlich eine neue Leistungsgrenze sichtbar machte. Diese Offenheit bietet anderen Entwicklern mehr als eine Vorzeigeinstallation: ein echtes Projekt, das sie untersuchen, hinterfragen und aus dem sie lernen können.
— Zima
Lerne MorgothTheBauglir kennen
MorgothTheBauglir ist die Reddit-Identität des Entwicklers, der in der früheren 350-TB-Fallstudie von ZimaSpace als Igor vorgestellt wurde. Dort wurde er als Netzwerkingenieur aus Brasilien mit langjährigem Interesse an Computern, Serverarchitektur und Datenverwaltung beschrieben. Seine Homelab-Arbeit folgt demselben Muster: den Platzbedarf überschaubar halten, praktische Hardware wiederverwenden, wo es sinnvoll ist, und genügend Raum für weitere Experimente lassen.
Seine Zima-Geschichte führte von der Entdeckung von ZimaOS auf einem DIY-NAS dazu, ein ZimaBoard 2 zum Steuerungspunkt für einen Speicheraufbau zu machen, der auf mehr als 350 TB anwuchs. Seine öffentlichen Reddit-Aktivitäten setzen diesen praxisnahen Ansatz durch Diskussionen über Speicher, HBAs, Virtualisierung, Netzwerke, Self-Hosting und ZimaOS fort. Du kannst MorgothTheBauglir auf Reddit folgen, um die Projekte und Gespräche auch über diese Seite hinaus weiterzuverfolgen.
Von ZimaOS zu einem dedizierten ZimaBoard 2
Der Weg zum ZimaBoard 2 begann mit Software. Laut der ursprünglichen Fallstudie von ZimaSpace stieß Igor erstmals über NAS Compares auf ZimaOS und installierte es auf einem DIY-NAS. Besonders hervorzuheben war nicht ein einzelnes Feature, sondern die Kombination aus einer ausgereiften Benutzeroberfläche, einem ressourcenschonenden Betrieb und einem Self-Hosting-Workflow, der zugänglich wirkte, ohne die zugrunde liegende Hardware zu verbergen.
Nach seinem Beitritt zur IceWhale-Community gewann er bei einer Veranstaltung ein ZimaBoard 2 832 und wechselte bald auf das leistungsstärkere ZimaBoard 2 1664. Damit bot das nächste Speicherexperiment etwas, das sein früherer generischer Mini-PC in derselben kompakten Form nicht bieten konnte: einen direkten PCIe-Erweiterungspfad, der als Ausgangspunkt für ein deutlich größeres System dienen konnte.
Einen PCIe-Erweiterungspfad in mehr als 350 TB verwandeln
Das Projekt, das diesen Aufbau besonders machte, begann als 80-TB-NAS und wuchs stetig weiter. Bis Januar 2026 hatte MorgothTheBauglir den Aufbau im 10-Zoll-Minirack rund um das ZimaBoard 2 neu konstruiert und den gemischten Speicherpool auf über 350 TB erweitert.
Die zentrale Hardwarekette kombinierte das ZimaBoard 2 mit einem IBM-M1210-HBA und einem Adaptec-AEC-82885T-SAS-Expander. Dazu kamen eine Mischung aus HDDs und SSDs sowie eine eigene Stromverteilung, Aluminiumprofile, umfangreiche Verkabelung, Kühlung und 3D-gedruckte Halterungen. Das Ergebnis ähnelte weniger einem NAS von der Stange als vielmehr einem kompakten Speicherchassis, das exakt auf die verfügbaren Komponenten, Kapazität und Platzverhältnisse zugeschnitten war.
ZimaSpace dokumentierte die Architektur, den Software-Stack und die Erweiterungsentscheidungen in der Fallstudie zum 350-TB+-Speicheraufbau mit ZimaBoard 2. Der ursprüngliche Aufbaubericht auf Reddit ergänzt Details aus der Werkstatt: Probleme mit dem Luftstrom, Laufwerksschächte, 3D-gedruckte Teile, Kabelführung, Stromverteilung und die kleinen Tricks, die nötig waren, um das kompakte Rack praxistauglich zu machen.
Erweiterung als Konstruktionswerkzeug
Für diesen Aufbau war die wichtigste Funktion des ZimaBoard 2 nicht einfach die Möglichkeit, mehr Speicher anzuschließen. Entscheidend war, dass der PCIe-Steckplatz direkt einen echten HBA aufnehmen konnte. Dadurch konnte das System von einem kompakten Board auf eine SAS-Erweiterungstopologie umsteigen, ohne den Host selbst in einen großen herkömmlichen Server verwandeln zu müssen.
MorgothTheBauglir beschrieb den Unterschied ganz einfach: Die direkte HBA-Unterstützung verändert die Gestaltungsmöglichkeiten eines kompakten NAS mit hoher Speicherdichte. Das Board blieb klein, während die darum aufgebaute Speicherstruktur deutlich größer wurde.
Kühlung, Stromversorgung und Platz waren Teil des Speicherproblems
Die Kapazität war nur eine der Einschränkungen. Warmes Wetter, Enterprise-Laufwerke, begrenzter Platz im Haushalt und ein dicht bestücktes 10-Zoll-Rack bedeuteten, dass Luftstrom und Stromverteilung zusammen mit dem Datenpfad geplant werden mussten. Lüfter, Laufwerkshalterungen, Netzteilplatzierung und Kabelwege mussten mit derselben physischen Anordnung funktionieren.
Das ist ein Grund, warum der Aufbau über die Schlagzeilenkapazität hinaus nützlich ist. Er zeigt, dass sehr großer Heimspeicher selten nur eine Frage des Anschlusses weiterer Laufwerke ist; mechanische Anordnung, Wärmeentwicklung, Stromversorgung, Verkabelung und Wartungsfreundlichkeit werden zu Bestandteilen der Architektur.
Die Software passend zur Einschränkung auswählen
Die Speichersoftware folgte derselben Logik, bei der die Einschränkungen im Vordergrund stehen. Statt den gesamten Pool um eine speicherhungrige ZFS-Topologie herum aufzubauen, verwendete er Proxmox VE als Virtualisierungsschicht, eine schlanke virtuelle Windows-IoT-Maschine für die Speicherverwaltungsaufgaben und StableBit DrivePool für flexibles Pooling und die Duplizierung von Ordnern über Laufwerke mit unterschiedlichen Kapazitäten hinweg.
Seine Zusammenfassung in der ZimaSpace-Fallstudie war bewusst unkompliziert: „Nicht jeder braucht RAID.“ Der Punkt war nicht, dass ein Speicherkonzept grundsätzlich besser ist als alle anderen. Es ging darum, dass der Software-Stack zur tatsächlichen Hardware, zum Wiederherstellungsmodell und zur Arbeitslast passen sollte, statt gewählt zu werden, weil er die aufwendigste verfügbare Option ist.
Den Aufbau teilen, nicht nur das Ergebnis
Das öffentliche Build-Protokoll ist ein wichtiger Teil der Geschichte. MorgothTheBauglir veröffentlichte nicht nur ein Foto des fertigen Racks, sondern listete die wichtigsten Komponenten auf, verlinkte die 3D-Druckmodelle, beschrieb die Probleme beim Zusammenbau und lud zu Fragen über Teile und Schwierigkeiten ein. In der anschließenden Diskussion beantwortete er Fragen zum Stromverbrauch, zur Netzwerkgeschwindigkeit, zur Speichernutzung, zu Aluminiumprofilen, Laufwerkshalterungen und künftigen Upgrades.
Derselbe praxisnahe Ton zeigt sich auch in seinen umfassenderen Diskussionen zum Self-Hosting. In seinem Reddit-Profil hat er HBA-Ansätze im IT-Modus für die SATA-Erweiterung empfohlen und in einer späteren Migrationsdiskussion ZimaOS als seine Wahl für einfache Bedienung beschrieben, zugleich aber Proxmox-Virtualisierung empfohlen, wenn Snapshots, Rollback und eine einfachere Migration Priorität haben.
Den Aufbau vorantreiben, bis die Grenze sichtbar wurde
Die Geschichte endete nicht bei 350 TB. Als das System über 450 TB hinauswuchs, berichtete MorgothTheBauglir von langsameren Netzwerkübertragungen sowie anhaltender CPU-Auslastung und Interrupt-Last. Die Konfiguration mit dem ZimaBoard 2 hatte für die 350-TB-Phase funktioniert, doch die größere Arbeitslast machte den nächsten Engpass sichtbar.
Statt dies als Misserfolg zu betrachten, änderte er die Architektur. Die Rechenleistung für den primären Speicher wechselte zu einem leistungsfähigeren Host mit mehr Arbeitsspeicher, schnellerer PCIe-Anbindung und 10GbE, während sich die Arbeit am Rack und an der Erweiterung weiterentwickelte. Sein 450-TB-Update auf Reddit ist eine hilfreiche Fortsetzung, weil es den Punkt dokumentiert, an dem ein erfolgreiches kompaktes Design schließlich groß genug wurde, um eine andere Hostklasse zu rechtfertigen.
Diese Entwicklung ist eine nützlichere Erkenntnis als eine Behauptung unbegrenzter Kapazität. Das ZimaBoard 2 ermöglichte ein ungewöhnlich dichtes Heimspeicher-Experiment; daraus ergaben sich konkrete Informationen darüber, wo die Plattform geeignet war und wo die Arbeitslast über ihre Möglichkeiten hinausgewachsen war.
Was gleich blieb
Bei allen Änderungen an der Hardware bleiben dieselben technischen Grundsätze erkennbar: den Erweiterungspfad nutzen, der das aktuelle Problem löst, unnötige Komplexität vermeiden, die mechanische Konstruktion als Teil der Systemarchitektur betrachten und genügend Details teilen, damit andere aus dem Ergebnis lernen können.
Genau deshalb ist die Beziehung zwischen dieser Anwendergeschichte und der technischen Fallstudie wichtig. Der Artikel zu 350 TB erklärt die Architektur. Diese Seite stellt den Erbauer dahinter, die Entscheidungen, die dorthin geführt haben, und die Ereignisse vor, als das Projekt weiter wuchs, vor.
Die Geschichte wird noch geschrieben
Die Geschichte von MorgothTheBauglir und Zima wird noch geschrieben. Das Projekt hat sich bereits von einem kleineren DIY-NAS zu einem ZimaBoard-2-System mit mehr als 350 TB und anschließend in eine neue Phase jenseits von 450 TB weiterentwickelt. Rack, Speicherpool und Softwareauswahl verändern sich weiter, sobald neue Anforderungen entstehen.
Wenn du die technische Aufschlüsselung der ZimaBoard-2-Phase lesen möchtest, lies die vollständige Fallstudie zu ZimaBoards 2 mit 350 TB. Um zu sehen, was er als Nächstes baut, testet und empfiehlt, folge MorgothTheBauglir auf Reddit.
