MorgothTheBauglir’s 350TB ZimaBoard 2 User Story

A Note from Zima

Thank you, MorgothTheBauglir, for showing how far a compact home-server platform can go when expansion is treated as a design tool rather than a fixed limit. From discovering ZimaOS on a DIY NAS to turning a ZimaBoard 2 into the control point for a storage system beyond 350TB, your work reflects the kind of hands-on experimentation that makes self-hosting communities valuable.

We especially appreciate that you shared more than the final capacity number. You documented the build, explained the hardware choices and trade-offs, answered questions from other homelab users, and stayed candid as the system kept growing and eventually exposed a new performance boundary. That openness gives other builders something more useful than a showcase: a real project they can study, question, and learn from.

— Zima

Meet MorgothTheBauglir

MorgothTheBauglir is the Reddit identity of the builder introduced as Igor in ZimaSpace's earlier 350TB case study. That profile described him as a network engineer from Brazil with a long-standing interest in computers, server architecture, and data management. His homelab work follows the same pattern: keep the footprint manageable, reuse practical hardware where it makes sense, and leave enough room to keep experimenting.

His Zima story moved from discovering ZimaOS on a DIY NAS to turning a ZimaBoard 2 into the control point for a storage build that grew beyond 350TB. His public Reddit activity continues that hands-on approach through discussions about storage, HBAs, virtualization, networking, self-hosting, and ZimaOS. You can follow MorgothTheBauglir on Reddit to see the projects and conversations continue beyond this page.

MorgothTheBauglir's compact 350TB-plus ZimaBoard 2 storage build shared on Reddit — MorgothTheBauglir shared the 350TB+ build publicly on Reddit, giving the community a direct look at the compact rack system behind the capacity figure.

From ZimaOS to a Dedicated ZimaBoard 2

The path to ZimaBoard 2 started with software. According to ZimaSpace's original case study, Igor first encountered ZimaOS through NAS Compares and installed it on a DIY NAS. What stood out was not a single feature, but the combination of a polished interface, lightweight operation, and a self-hosting workflow that felt approachable without hiding the underlying hardware.

After joining the IceWhale community, he won a ZimaBoard 2 832 in an event and soon moved to the higher-end ZimaBoard 2 1664. That gave the next storage experiment something his earlier generic mini-PC did not offer in the same compact form: a direct PCIe expansion path that could be treated as the starting point for a much larger system.

Turning One PCIe Expansion Path into 350TB+

The project that made the build stand out began as an 80TB NAS and kept growing. By January 2026, MorgothTheBauglir had rebuilt it around ZimaBoard 2 inside a 10-inch mini rack and pushed the mixed storage pool past 350TB.

The core hardware chain paired ZimaBoard 2 with an IBM M1210 HBA and an Adaptec AEC-82885T SAS expander. Around that, he used a mix of HDDs and SSDs, plus dedicated power distribution, aluminum extrusion, extensive cabling, cooling, and 3D-printed mounts. The result was less like an off-the-shelf NAS and more like a compact storage chassis designed around the exact parts, capacity, and space available.

ZimaSpace documented the architecture, software stack, and expansion decisions in the 350TB+ ZimaBoard 2 storage case study. The original Reddit build log adds the workshop-level detail: airflow problems, drive caddies, 3D-printed parts, cable routing, power distribution, and the small hacks required to make the dense rack practical.

System diagram from the ZimaSpace 350TB ZimaBoard 2 case study — The system overview from ZimaSpace's original case study places ZimaBoard 2 at the center of a much larger storage-management design rather than treating the board as the storage enclosure itself.

Expansion Was the Design Tool

For this build, the important ZimaBoard 2 feature was not simply that it could attach more storage. It was that the PCIe slot could accept a real HBA directly. That let the system move from a compact board to a SAS expansion topology without turning the host itself into a large conventional server.

MorgothTheBauglir described the difference in simple terms: direct HBA support changes the way a compact, high-density NAS can be designed. The board remained small while the storage fabric around it became much larger.

Hardware detail from MorgothTheBauglir's compact ZimaBoard 2 storage build — A hardware view from the build documents how the project moves beyond the footprint of the host itself by extending storage through dedicated expansion hardware.

Dense rack and storage hardware from the 350TB ZimaBoard 2 project — The compact rack format makes mechanical layout part of the engineering problem: drives, cabling, cooling, power, and expansion all have to coexist inside a limited home-lab footprint.

Cooling, Power, and Space Were Part of the Storage Problem

Capacity was only one constraint. Warm weather, enterprise drives, limited household space, and a dense 10-inch rack meant airflow and power distribution had to be designed alongside the data path. Fans, drive mounts, PSU placement, and cable routes all had to work with the same physical layout.

That is one reason the build is useful beyond the headline capacity. It shows that very large home storage is rarely just a question of attaching more disks; mechanical layout, thermals, power, cabling, and serviceability become part of the architecture.

Storage hardware and cabling in MorgothTheBauglir's 350TB ZimaBoard 2 build — As capacity increases, the project becomes as much about cabling, physical organization, and service access as it is about raw disk count.

Compact high-density storage arrangement from the ZimaBoard 2 350TB project — The build's defining trade-off is visible in its packaging: very high storage capacity is organized around a compact host and a home-friendly rack rather than a full-size enterprise chassis.

Choosing the Software Around the Constraint

The storage software followed the same constraint-first logic. Rather than building the entire pool around a memory-hungry ZFS topology, he used Proxmox VE as the virtualization layer, a lightweight Windows IoT virtual machine for the storage-management workload, and StableBit DrivePool for flexible pooling and folder duplication across mixed drives.

His summary in the ZimaSpace case study was deliberately uncomplicated: "Not everyone needs RAID." The point was not that one storage design is universally better. It was that the software stack should match the actual hardware, recovery model, and workload instead of being chosen because it is the most elaborate option available.

Software view from MorgothTheBauglir's 350TB storage-management setup — The software side of the project was designed around the same constraint as the hardware: manage a very large mixed-drive pool without adding unnecessary complexity to the compact host.

Storage pool management screenshot from the 350TB ZimaBoard 2 case study — ZimaSpace's original case study documents the operational side of the build as well as the hardware, including the software used to organize and manage the mixed-capacity storage pool.

Sharing the Build, Not Just the Result

The public build log is an important part of the story. MorgothTheBauglir did not only post a finished rack photo; he listed the major components, linked the 3D-print models, described the assembly problems, and invited questions about parts and struggles. In the discussion that followed, he answered questions about power draw, network speed, storage use, aluminum extrusion, drive mounts, and future upgrades.

That same practical tone appears in his wider self-hosting discussions. On his Reddit profile, he has recommended HBA-in-IT-mode approaches for SATA expansion and, in a later migration discussion, described ZimaOS as his ease-of-use choice while also suggesting Proxmox virtualization when snapshots, rollback, and easier migration are priorities.

Pushing the Build Until the Limit Became Visible

The story did not stop at 350TB. As the system grew past 450TB, MorgothTheBauglir reported slower network transfers together with sustained CPU pressure and interrupts. The ZimaBoard 2 configuration had worked for the 350TB stage, but the larger workload made the next bottleneck visible.

Instead of treating that as a failure, he changed the architecture. The primary storage compute moved to a higher-performance host with more memory, faster PCIe connectivity, and 10GbE, while the rack and expansion work continued to evolve. His 450TB update on Reddit is a useful follow-up because it documents the point where a successful compact design finally became large enough to justify a different class of host.

That progression is a more useful lesson than an unlimited-capacity claim. ZimaBoard 2 enabled an unusually dense home-storage experiment; the experiment then produced real information about where the platform fit and where the workload had moved beyond it.

What Stayed Constant

Across the changes in hardware, the same engineering habits remain visible: use the expansion path that solves the current problem, avoid complexity that does not earn its keep, make the mechanical design part of the system architecture, and share enough detail that someone else can learn from the result.

That is also why the relationship between this User Story and the technical case study matters. The 350TB article explains the architecture. This page records the builder behind it, the decisions that led there, and what happened when the project kept growing.

The Story Is Still Being Written

MorgothTheBauglir and Zima's story is still being written. The project has already moved from a smaller DIY NAS to a 350TB+ ZimaBoard 2 system and then into a new phase beyond 450TB. The rack, storage pool, and software choices continue to change as new constraints appear.

If you want the technical breakdown of the ZimaBoard 2 stage, read the full 350TB ZimaBoard 2 case study. To see what he builds, tests, and recommends next, follow MorgothTheBauglir on Reddit.