Una nota de Zima
Gracias, MorgothTheBauglir, por mostrar hasta dónde puede llegar una plataforma compacta de servidor doméstico cuando la expansión se trata como una herramienta de diseño y no como un límite fijo. Desde descubrir ZimaOS en un NAS DIY hasta convertir una ZimaBoard 2 en el punto de control de un sistema de almacenamiento de más de 350 TB, tu trabajo refleja el tipo de experimentación práctica que hace valiosas a las comunidades de autohospedaje.
Apreciamos especialmente que compartieras más que la cifra final de capacidad. Documentaste la construcción, explicaste las elecciones de hardware y sus compromisos, respondiste a las preguntas de otros usuarios de homelab y mantuviste la franqueza a medida que el sistema seguía creciendo y finalmente alcanzaba un nuevo límite de rendimiento. Esa apertura ofrece a otros creadores algo más útil que una exhibición: un proyecto real que pueden estudiar, cuestionar y aprovechar para aprender.
— Zima
Conoce a MorgothTheBauglir
MorgothTheBauglir es la identidad en Reddit del creador presentado como Igor en el anterior caso de estudio de 350 TB de ZimaSpace. Ese perfil lo describía como un ingeniero de redes de Brasil con un interés de larga trayectoria en los ordenadores, la arquitectura de servidores y la gestión de datos. Su trabajo en el homelab sigue el mismo patrón: mantener una huella física manejable, reutilizar hardware práctico cuando tiene sentido y dejar suficiente margen para seguir experimentando.
La historia de Zima de Morgoth pasó de descubrir ZimaOS en un NAS DIY a convertir una ZimaBoard 2 en el punto de control de una construcción de almacenamiento que creció hasta superar los 350 TB. Su actividad pública en Reddit continúa con ese enfoque práctico mediante conversaciones sobre almacenamiento, HBA, virtualización, redes, autohospedaje y ZimaOS. Puedes seguir a MorgothTheBauglir en Reddit para ver cómo continúan los proyectos y las conversaciones más allá de esta página.
De ZimaOS a una ZimaBoard 2 dedicada
El camino hacia ZimaBoard 2 comenzó con el software. Según el caso de estudio original de ZimaSpace, Igor conoció ZimaOS a través de NAS Compares y lo instaló en un NAS DIY. Lo que destacó no fue una sola función, sino la combinación de una interfaz pulida, un funcionamiento ligero y un flujo de trabajo de autohospedaje accesible, sin ocultar el hardware subyacente.
Después de unirse a la comunidad de IceWhale, ganó una ZimaBoard 2 832 en un evento y poco después pasó a la ZimaBoard 2 1664, de gama superior. Eso aportó al siguiente experimento de almacenamiento algo que su mini-PC genérico anterior no ofrecía en un formato igual de compacto: una vía de expansión PCIe directa que podía tomarse como punto de partida para un sistema mucho más grande.
Convertir una ruta de expansión PCIe en más de 350 TB
El proyecto que hizo destacar esta construcción comenzó como un NAS de 80 TB y siguió creciendo. En enero de 2026, MorgothTheBauglir lo había reconstruido alrededor de ZimaBoard 2 dentro de un mini rack de 10 pulgadas y había ampliado el conjunto de almacenamiento mixto hasta superar los 350 TB.
La cadena principal de hardware combinaba ZimaBoard 2 con un HBA IBM M1210 y un expansor SAS Adaptec AEC-82885T. Además, utilizó una combinación de HDD y SSD, junto con distribución de alimentación específica, perfiles de aluminio, un cableado extenso, refrigeración y soportes impresos en 3D. El resultado se parecía menos a un NAS comercial estándar y más a un chasis de almacenamiento compacto diseñado en torno a las piezas, la capacidad y el espacio disponibles.
ZimaSpace documentó la arquitectura, la pila de software y las decisiones de expansión en el estudio de caso del almacenamiento ZimaBoard 2 de más de 350 TB. El registro de construcción en Reddit original añade los detalles propios del taller: problemas de flujo de aire, bandejas para unidades, piezas impresas en 3D, distribución de cables, distribución de la alimentación y los pequeños trucos necesarios para hacer práctico el rack de alta densidad.
La expansión fue la herramienta de diseño
En esta construcción, la característica importante de ZimaBoard 2 no era simplemente que pudiera conectar más almacenamiento. Era que la ranura PCIe podía aceptar directamente un HBA real. Eso permitió que el sistema pasara de una placa compacta a una topología de expansión SAS sin convertir el propio equipo anfitrión en un servidor convencional de gran tamaño.
MorgothTheBauglir describió la diferencia en términos sencillos: la compatibilidad directa con HBA cambia la forma de diseñar un NAS compacto y de alta densidad. La placa siguió siendo pequeña, mientras que la infraestructura de almacenamiento que la rodeaba creció mucho más.
La refrigeración, la alimentación y el espacio también formaban parte del problema de almacenamiento
La capacidad era solo una de las limitaciones. El clima cálido, las unidades empresariales, el espacio doméstico limitado y un rack denso de 10 pulgadas obligaban a diseñar el flujo de aire y la distribución eléctrica junto con la ruta de datos. Los ventiladores, los soportes para unidades, la ubicación de la fuente de alimentación y las rutas de los cables debían funcionar con la misma disposición física.
Esa es una de las razones por las que la construcción resulta útil más allá de la cifra de capacidad. Demuestra que un almacenamiento doméstico muy grande rara vez consiste simplemente en conectar más discos; la disposición mecánica, la gestión térmica, la alimentación, el cableado y la facilidad de mantenimiento pasan a formar parte de la arquitectura.
Elegir el software en función de la limitación
El software de almacenamiento siguió la misma lógica de priorizar las limitaciones. En lugar de construir todo el conjunto en torno a una topología ZFS con un alto consumo de memoria, utilizó Proxmox VE como capa de virtualización, una máquina virtual ligera con Windows IoT para la carga de trabajo de gestión del almacenamiento y StableBit DrivePool para crear conjuntos flexibles y duplicar carpetas entre unidades mixtas.
Su resumen en el estudio de caso de ZimaSpace fue deliberadamente sencillo: «No todo el mundo necesita RAID». La idea no era que un diseño de almacenamiento fuera universalmente mejor. Era que la pila de software debía adaptarse al hardware real, al modelo de recuperación y a la carga de trabajo, en lugar de elegirse por ser la opción más elaborada disponible.
Compartir la construcción, no solo el resultado
El registro público de la construcción es una parte importante de la historia. MorgothTheBauglir no solo publicó una foto del rack terminado; también enumeró los componentes principales, enlazó los modelos para impresión 3D, describió los problemas de montaje e invitó a hacer preguntas sobre las piezas y las dificultades. En el debate posterior, respondió preguntas sobre el consumo eléctrico, la velocidad de red, el uso del almacenamiento, los perfiles de aluminio, los soportes para unidades y futuras actualizaciones.
Ese mismo tono práctico aparece en sus conversaciones más amplias sobre el autoalojamiento. En su perfil de Reddit, ha recomendado enfoques con HBA en modo IT para la expansión SATA y, en una conversación posterior sobre migración, describió ZimaOS como su opción por facilidad de uso, aunque también sugirió la virtualización con Proxmox cuando las instantáneas, la reversión y una migración más sencilla son prioritarias.
Llevar el proyecto al límite hasta que el límite se hizo visible
La historia no terminó en los 350 TB. Cuando el sistema superó los 450 TB, MorgothTheBauglir informó de transferencias de red más lentas, junto con una presión sostenida sobre la CPU y las interrupciones. La configuración de ZimaBoard 2 había funcionado para la etapa de 350 TB, pero la mayor carga de trabajo hizo visible el siguiente cuello de botella.
En lugar de considerarlo un fracaso, cambió la arquitectura. El procesamiento del almacenamiento principal pasó a un equipo anfitrión de mayor rendimiento, con más memoria, conectividad PCIe más rápida y 10GbE, mientras el rack y el trabajo de expansión seguían evolucionando. Su actualización de 450 TB en Reddit es un seguimiento útil porque documenta el momento en que un diseño compacto que había tenido éxito finalmente alcanzó un tamaño suficiente para justificar otra clase de equipo anfitrión.
Esa evolución ofrece una lección más útil que una afirmación sobre capacidad ilimitada. ZimaBoard 2 permitió realizar un experimento de almacenamiento doméstico con una densidad inusual; después, el experimento aportó información real sobre dónde encajaba la plataforma y en qué momento la carga de trabajo la había superado.
Lo que se mantuvo constante
A pesar de los cambios de hardware, los mismos hábitos de ingeniería siguen siendo visibles: usar la vía de expansión que resuelve el problema actual, evitar una complejidad que no compense, hacer que el diseño mecánico forme parte de la arquitectura del sistema y compartir suficientes detalles para que otra persona pueda aprender del resultado.
Por eso también es importante la relación entre esta historia de usuario y el caso práctico técnico. El artículo sobre los 350 TB explica la arquitectura. Esta página documenta al creador que está detrás, las decisiones que lo llevaron hasta allí y lo que ocurrió cuando el proyecto siguió creciendo.
La historia aún se está escribiendo
La historia de MorgothTheBauglir y Zima aún se está escribiendo. El proyecto ya pasó de ser un NAS DIY más pequeño a un sistema ZimaBoard 2 de más de 350 TB, y después entró en una nueva fase que supera los 450 TB. El rack, el conjunto de almacenamiento y las decisiones de software siguen cambiando a medida que aparecen nuevas limitaciones.
Si quieres el desglose técnico de la etapa de ZimaBoard 2, lee el caso práctico completo de 350 TB de ZimaBoard 2. Para ver qué construye, prueba y recomienda después, sigue a MorgothTheBauglir en Reddit.
