Una nota da Zima
Grazie, MorgothTheBauglir, per aver mostrato quanto può spingersi una piattaforma home server compatta quando l'espansione viene considerata uno strumento di progettazione anziché un limite fisso. Dalla scoperta di ZimaOS su un NAS fai-da-te alla trasformazione di uno ZimaBoard 2 nel punto di controllo di un sistema di archiviazione oltre i 350 TB, il tuo lavoro riflette il tipo di sperimentazione pratica che rende preziose le community del self-hosting.
Apprezziamo particolarmente il fatto che tu abbia condiviso più del semplice dato sulla capacità finale. Hai documentato il progetto, spiegato le scelte hardware e i relativi compromessi, risposto alle domande di altri utenti homelab e mantenuto un approccio trasparente mentre il sistema continuava a crescere, fino a raggiungere un nuovo limite prestazionale. Questa apertura offre agli altri costruttori qualcosa di più utile di una semplice vetrina: un progetto reale da studiare, mettere in discussione e da cui imparare.
— Zima
Conosci MorgothTheBauglir
MorgothTheBauglir è l'identità su Reddit del costruttore presentato come Igor nel precedente case study di ZimaSpace sui 350 TB. Quel profilo lo descriveva come un ingegnere di rete brasiliano, da sempre interessato ai computer, all'architettura dei server e alla gestione dei dati. Il suo homelab segue lo stesso approccio: mantenere dimensioni gestibili, riutilizzare hardware pratico quando ha senso e lasciare abbastanza spazio per continuare a sperimentare.
La sua storia con Zima è passata dalla scoperta di ZimaOS su un NAS fai-da-te alla trasformazione di uno ZimaBoard 2 nel punto di controllo di un sistema di archiviazione cresciuto oltre i 350 TB. La sua attività pubblica su Reddit continua a riflettere questo approccio pratico, attraverso discussioni su archiviazione, HBA, virtualizzazione, rete, self-hosting e ZimaOS. Puoi seguire MorgothTheBauglir su Reddit per vedere come proseguono i progetti e le conversazioni oltre questa pagina.
Da ZimaOS a uno ZimaBoard 2 dedicato
Il percorso verso ZimaBoard 2 è iniziato dal software. Secondo il case study originale di ZimaSpace, Igor ha scoperto ZimaOS tramite NAS Compares e lo ha installato su un NAS fai-da-te. Ciò che lo ha colpito non è stata una singola funzione, ma la combinazione di un'interfaccia curata, un funzionamento leggero e un flusso di self-hosting accessibile, senza nascondere l'hardware sottostante.
Dopo essere entrato nella community di IceWhale, ha vinto uno ZimaBoard 2 832 durante un evento e poco dopo è passato al modello ZimaBoard 2 1664 di fascia più alta. Questo ha dato al successivo esperimento di archiviazione qualcosa che il precedente mini-PC generico non offriva nella stessa forma compatta: un percorso di espansione PCIe diretto, che poteva essere usato come punto di partenza per un sistema molto più grande.
Trasformare un unico percorso di espansione PCIe in oltre 350 TB
Il progetto che ha reso notevole questa configurazione è iniziato come un NAS da 80 TB e ha continuato a crescere. A gennaio 2026, MorgothTheBauglir lo aveva ricostruito intorno a ZimaBoard 2 all’interno di un mini rack da 10 pollici, portando il pool di storage misto oltre i 350 TB.
La catena hardware principale abbinava ZimaBoard 2 a un HBA IBM M1210 e a un expander SAS Adaptec AEC-82885T. Intorno a questi componenti, ha utilizzato un mix di HDD e SSD, oltre a una distribuzione dell’alimentazione dedicata, profili in alluminio, un cablaggio esteso, sistemi di raffreddamento e supporti stampati in 3D. Il risultato assomigliava meno a un NAS pronto all’uso e più a uno chassis di storage compatto progettato intorno ai componenti, alla capacità e allo spazio esattamente disponibili.
ZimaSpace ha documentato l’architettura, lo stack software e le decisioni relative all’espansione nel case study sullo storage ZimaBoard 2 da oltre 350 TB. Il log del progetto su Reddit aggiunge i dettagli a livello di laboratorio: problemi di flusso d’aria, caddy per le unità, componenti stampati in 3D, instradamento dei cavi, distribuzione dell’alimentazione e i piccoli accorgimenti necessari per rendere pratico il rack ad alta densità.
L’espansione come strumento di progettazione
Per questo progetto, la caratteristica importante di ZimaBoard 2 non era semplicemente la possibilità di collegare più storage. Il punto era che lo slot PCIe poteva accettare direttamente un vero HBA. Ciò ha permesso al sistema di passare da una scheda compatta a una topologia di espansione SAS senza trasformare l’host stesso in un grande server tradizionale.
MorgothTheBauglir ha descritto la differenza in termini semplici: il supporto HBA diretto cambia il modo in cui è possibile progettare un NAS compatto e ad alta densità. La scheda è rimasta piccola, mentre l’infrastruttura di storage intorno a essa è diventata molto più grande.
Raffreddamento, alimentazione e spazio facevano parte del problema dello spazio di archiviazione
La capacità era solo uno dei vincoli. Il clima caldo, le unità enterprise, lo spazio domestico limitato e un rack compatto da 10 pollici imponevano di progettare il flusso d'aria e la distribuzione dell'alimentazione insieme al percorso dei dati. Ventole, supporti per le unità, posizione dell'alimentatore e instradamento dei cavi dovevano integrarsi tutti nella stessa configurazione fisica.
Questo è uno dei motivi per cui la build è utile anche oltre il dato della capacità dichiarata. Dimostra che uno spazio di archiviazione domestico molto grande raramente consiste solo nel collegare più dischi: la disposizione meccanica, la gestione termica, l'alimentazione, il cablaggio e la facilità di manutenzione diventano parte dell'architettura.
Scegliere il software in base al vincolo
Il software di archiviazione seguiva la stessa logica basata innanzitutto sui vincoli. Invece di costruire l'intero pool attorno a una topologia ZFS dispendiosa in termini di memoria, ha utilizzato Proxmox VE come livello di virtualizzazione, una macchina virtuale Windows IoT leggera per il carico di lavoro di gestione dello spazio di archiviazione e StableBit DrivePool per il pooling flessibile e la duplicazione delle cartelle su unità miste.
Il suo riepilogo nel case study di ZimaSpace era volutamente semplice: "Non tutti hanno bisogno del RAID." Il punto non era che un determinato design di archiviazione fosse universalmente migliore. Era che lo stack software dovesse corrispondere all'hardware effettivo, al modello di ripristino e al carico di lavoro, invece di essere scelto perché rappresentava l'opzione più elaborata disponibile.
Condividere la build, non solo il risultato
Il registro pubblico della build è una parte importante della storia. MorgothTheBauglir non ha pubblicato soltanto una foto del rack finito: ha elencato i componenti principali, inserito i link ai modelli per la stampa 3D, descritto i problemi di assemblaggio e invitato a fare domande sui componenti e sulle difficoltà. Nella discussione che ne è seguita, ha risposto a domande sul consumo energetico, sulla velocità di rete, sull'uso dello spazio di archiviazione, sui profilati in alluminio, sui supporti per le unità e sui futuri aggiornamenti.
Lo stesso tono pratico emerge nelle sue discussioni più ampie sull’hosting autonomo. Sul suo profilo Reddit, ha consigliato approcci con HBA in modalità IT per l’espansione SATA e, in una discussione successiva sulla migrazione, ha descritto ZimaOS come la sua scelta per la facilità d’uso, suggerendo al contempo la virtualizzazione Proxmox quando snapshot, rollback e migrazione più semplice sono prioritari.
Spingere il progetto finché il limite non è diventato visibile
La storia non si è fermata a 350 TB. Quando il sistema è cresciuto oltre i 450 TB, MorgothTheBauglir ha segnalato trasferimenti di rete più lenti, insieme a una pressione costante sulla CPU e a un numero elevato di interrupt. La configurazione ZimaBoard 2 aveva funzionato nella fase da 350 TB, ma il carico di lavoro maggiore ha reso visibile il collo di bottiglia successivo.
Invece di considerarlo un fallimento, ha cambiato l’architettura. L’elaborazione dello storage principale è stata spostata su un host dalle prestazioni superiori, con più memoria, connettività PCIe più veloce e 10GbE, mentre il rack e il lavoro di espansione continuavano a evolversi. Il suo aggiornamento sui 450 TB su Reddit è un seguito utile perché documenta il momento in cui un design compatto di successo è diventato finalmente abbastanza grande da giustificare una classe di host diversa.
Questa progressione offre una lezione più utile di una promessa di capacità illimitata. ZimaBoard 2 ha reso possibile un esperimento di archiviazione domestica insolitamente denso; l’esperimento ha poi fornito informazioni concrete su dove la piattaforma fosse adatta e su quando il carico di lavoro l’avesse superata.
Cosa è rimasto invariato
Nonostante i cambiamenti nell’hardware, restano visibili le stesse abitudini ingegneristiche: usare il percorso di espansione che risolve il problema attuale, evitare complessità che non offrano un reale vantaggio, considerare il design meccanico parte dell’architettura del sistema e condividere dettagli sufficienti affinché qualcun altro possa imparare dal risultato.
Anche per questo il rapporto tra questa storia dell’utente e il case study tecnico è importante. L’articolo sui 350 TB spiega l’architettura. Questa pagina racconta il costruttore che l’ha realizzata, le decisioni che ci hanno portato e cosa è successo quando il progetto ha continuato a crescere.
La storia è ancora in corso
La storia di MorgothTheBauglir e Zima è ancora in corso. Il progetto è già passato da un NAS fai-da-te più piccolo a un sistema ZimaBoard 2 da oltre 350 TB, per poi entrare in una nuova fase oltre i 450 TB. Il rack, il pool di archiviazione e le scelte software continuano a cambiare con l’emergere di nuovi vincoli.
Se desideri l’analisi tecnica della configurazione ZimaBoard 2, leggi il case study completo sullo ZimaBoard 2 da 350 TB. Per vedere cosa costruisce, testa e consiglia in seguito, segui MorgothTheBauglir su Reddit.
