Uma nota da Zima
Obrigado, MorgothTheBauglir, por mostrar até onde pode chegar uma plataforma compacta de servidor doméstico quando a expansão é tratada como uma ferramenta de design, e não como um limite fixo. Desde a descoberta do ZimaOS num NAS DIY até à transformação de um ZimaBoard 2 no ponto de controlo de um sistema de armazenamento com mais de 350 TB, o seu trabalho reflete o tipo de experimentação prática que torna as comunidades de self-hosting tão valiosas.
Apreciamos especialmente o facto de ter partilhado mais do que o simples número da capacidade final. Documentou a configuração, explicou as escolhas e os compromissos relativos ao hardware, respondeu às perguntas de outros utilizadores de homelab e manteve-se transparente à medida que o sistema continuava a crescer e acabava por revelar um novo limite de desempenho. Essa abertura oferece aos outros criadores algo mais útil do que uma montra: um projeto real que podem estudar, questionar e usar para aprender.
— Zima
Conheça MorgothTheBauglir
MorgothTheBauglir é a identidade no Reddit do criador apresentado como Igor no estudo de caso anterior da ZimaSpace sobre 350 TB. Esse perfil descrevia-o como um engenheiro de redes do Brasil, com um interesse de longa data por computadores, arquitetura de servidores e gestão de dados. O seu trabalho no homelab segue o mesmo padrão: manter uma pegada reduzida, reutilizar hardware prático quando faz sentido e deixar espaço suficiente para continuar a experimentar.
A história de Zima passou da descoberta do ZimaOS num NAS DIY à transformação de um ZimaBoard 2 no ponto de controlo de uma configuração de armazenamento que cresceu para além dos 350 TB. A sua atividade pública no Reddit mantém essa abordagem prática através de discussões sobre armazenamento, HBAs, virtualização, redes, self-hosting e ZimaOS. Pode seguir MorgothTheBauglir no Reddit para acompanhar a continuação dos projetos e das conversas para além desta página.
Do ZimaOS a um ZimaBoard 2 dedicado
O caminho até ao ZimaBoard 2 começou pelo software. De acordo com o estudo de caso original da ZimaSpace, Igor conheceu o ZimaOS através do NAS Compares e instalou-o num NAS DIY. O que se destacou não foi uma única funcionalidade, mas a combinação de uma interface refinada, funcionamento leve e um fluxo de trabalho de self-hosting acessível, sem esconder o hardware subjacente.
Depois de aderir à comunidade IceWhale, ganhou um ZimaBoard 2 832 num evento e, pouco depois, passou para o ZimaBoard 2 1664, de gama superior. Isso proporcionou à experiência de armazenamento seguinte algo que o seu mini-PC genérico anterior não oferecia no mesmo formato compacto: um caminho de expansão PCIe direto, que podia ser tratado como ponto de partida para um sistema muito maior.
Transformar um único caminho de expansão PCIe em mais de 350 TB
O projeto que fez esta construção destacar-se começou como um NAS de 80 TB e continuou a crescer. Em janeiro de 2026, MorgothTheBauglir reconstruiu-o em torno do ZimaBoard 2 dentro de um mini-rack de 10 polegadas e levou o conjunto de armazenamento misto para além dos 350 TB.
A cadeia de hardware principal combinava o ZimaBoard 2 com um HBA IBM M1210 e um expansor SAS Adaptec AEC-82885T. À sua volta, utilizou uma combinação de HDD e SSD, além de distribuição de energia dedicada, perfis de alumínio, cablagem extensa, arrefecimento e suportes impressos em 3D. O resultado parecia menos um NAS pronto a usar e mais um chassis de armazenamento compacto concebido em torno das peças, da capacidade e do espaço exatos disponíveis.
A ZimaSpace documentou a arquitetura, a pilha de software e as decisões de expansão no estudo de caso de armazenamento do ZimaBoard 2 de mais de 350 TB. O registo de construção no Reddit acrescenta os detalhes ao nível da oficina: problemas de circulação de ar, gavetas para unidades, peças impressas em 3D, encaminhamento de cabos, distribuição de energia e os pequenos truques necessários para tornar prático o rack denso.
A expansão foi a ferramenta de design
Nesta construção, a funcionalidade importante do ZimaBoard 2 não era simplesmente poder ligar mais armazenamento. Era o facto de a ranhura PCIe poder aceitar diretamente um HBA verdadeiro. Isso permitiu ao sistema passar de uma placa compacta para uma topologia de expansão SAS sem transformar o próprio anfitrião num servidor convencional de grandes dimensões.
MorgothTheBauglir descreveu a diferença de forma simples: o suporte HBA direto altera a forma como pode ser concebido um NAS compacto e de alta densidade. A placa manteve-se pequena, enquanto a infraestrutura de armazenamento à sua volta se tornou muito maior.
A refrigeração, a alimentação e o espaço faziam parte do problema do armazenamento
A capacidade era apenas uma das limitações. O clima quente, as unidades empresariais, o espaço doméstico limitado e um rack denso de 10 polegadas significavam que o fluxo de ar e a distribuição de energia tinham de ser concebidos em conjunto com o percurso dos dados. As ventoinhas, os suportes das unidades, a colocação da fonte de alimentação e as rotas dos cabos tinham todos de funcionar com a mesma disposição física.
Essa é uma das razões pelas quais a construção é útil para além da capacidade anunciada. Mostra que um armazenamento doméstico muito grande raramente é apenas uma questão de ligar mais discos; a disposição mecânica, a gestão térmica, a alimentação, o cabeamento e a facilidade de manutenção passam a fazer parte da arquitetura.
Escolher o software em função da limitação
O software de armazenamento seguiu a mesma lógica baseada nas limitações. Em vez de construir todo o conjunto em torno de uma topologia ZFS exigente em memória, utilizou o Proxmox VE como camada de virtualização, uma máquina virtual Windows IoT leve para a carga de trabalho de gestão do armazenamento e o StableBit DrivePool para agrupamento flexível e duplicação de pastas entre unidades mistas.
O resumo que apresentou no estudo de caso da ZimaSpace foi deliberadamente simples: "Nem toda a gente precisa de RAID." A ideia não era que um determinado design de armazenamento fosse universalmente melhor. Era que a pilha de software deveria corresponder ao hardware real, ao modelo de recuperação e à carga de trabalho, em vez de ser escolhida por ser a opção mais elaborada disponível.
Partilhar a construção, não apenas o resultado
O registo público da construção é uma parte importante da história. MorgothTheBauglir não publicou apenas uma fotografia do rack concluído; enumerou os principais componentes, partilhou ligações para os modelos de impressão 3D, descreveu os problemas de montagem e convidou a colocar questões sobre as peças e as dificuldades. Na discussão que se seguiu, respondeu a perguntas sobre o consumo de energia, a velocidade da rede, a utilização do armazenamento, os perfis de alumínio, os suportes das unidades e futuras atualizações.
Esse mesmo tom prático também aparece nas suas discussões mais amplas sobre autoalojamento. No seu perfil do Reddit, recomendou abordagens com HBA em modo IT para expansão SATA e, numa discussão posterior sobre migração, descreveu o ZimaOS como a sua escolha pela facilidade de utilização, sugerindo também a virtualização com Proxmox quando os snapshots, o rollback e uma migração mais fácil são prioridades.
Levar a Construção Até o Limite se Tornar Visível
A história não terminou nos 350 TB. À medida que o sistema ultrapassou os 450 TB, MorgothTheBauglir comunicou transferências de rede mais lentas, juntamente com pressão contínua sobre o CPU e interrupções. A configuração do ZimaBoard 2 tinha funcionado na fase dos 350 TB, mas a carga de trabalho maior tornou visível o estrangulamento seguinte.
Em vez de encarar isso como um fracasso, ele alterou a arquitetura. O processamento do armazenamento principal passou para um anfitrião de maior desempenho, com mais memória, conectividade PCIe mais rápida e 10GbE, enquanto o rack e o trabalho de expansão continuaram a evoluir. A sua atualização de 450 TB no Reddit é um seguimento útil, pois documenta o momento em que um design compacto bem-sucedido finalmente se tornou suficientemente grande para justificar uma classe diferente de anfitrião.
Essa progressão é uma lição mais útil do que uma alegação de capacidade ilimitada. O ZimaBoard 2 permitiu uma experiência de armazenamento doméstico com uma densidade invulgar; a experiência produziu então informação concreta sobre onde a plataforma se adequava e onde a carga de trabalho já a tinha ultrapassado.
O Que Permaneceu Constante
Ao longo das mudanças no hardware, os mesmos hábitos de engenharia continuam visíveis: utilizar a via de expansão que resolve o problema atual, evitar complexidade que não compensa, integrar o design mecânico na arquitetura do sistema e partilhar detalhes suficientes para que outra pessoa possa aprender com o resultado.
É também por isso que a relação entre esta História de Utilizador e o estudo de caso técnico é importante. O artigo sobre os 350 TB explica a arquitetura. Esta página regista o criador por detrás dela, as decisões que conduziram até aí e o que aconteceu quando o projeto continuou a crescer.
A História Continua a Ser Escrita
A história de MorgothTheBauglir e da Zima continua a ser escrita. O projeto já passou de um NAS DIY mais pequeno para um sistema ZimaBoard 2 com mais de 350 TB e, depois, para uma nova fase com mais de 450 TB. O rack, o conjunto de armazenamento e as escolhas de software continuam a mudar à medida que surgem novas limitações.
Se quiser saber os pormenores técnicos da fase do ZimaBoard 2, leia o estudo de caso completo do ZimaBoard 2 de 350 TB. Para ver o que ele constrói, testa e recomenda a seguir, siga MorgothTheBauglir no Reddit.
