En hälsning från Zima
Tack, MorgothTheBauglir, för att du visar hur långt en kompakt hemserverplattform kan nå när expansion ses som ett designverktyg snarare än en fast begränsning. Från att upptäcka ZimaOS på en egenbyggd NAS till att göra en ZimaBoard 2 till kontrollpunkt för ett lagringssystem på över 350 TB återspeglar ditt arbete den praktiska experimentlust som gör self-hosting-communityn värdefull.
Vi uppskattar särskilt att du delade mer än den slutliga kapacitetssiffran. Du dokumenterade bygget, förklarade hårdvaruvalen och avvägningarna, svarade på frågor från andra homelab-användare och var öppen när systemet fortsatte att växa och till slut blottlade en ny prestandagräns. Den öppenheten ger andra byggare något mer värdefullt än en uppvisning: ett verkligt projekt som de kan studera, ifrågasätta och lära sig av.
— Zima
Möt MorgothTheBauglir
MorgothTheBauglir är Reddit-identiteten för byggaren som presenterades som Igor i ZimaSpaces tidigare fallstudie om 350 TB. Där beskrevs han som nätverksingenjör från Brasilien med ett långvarigt intresse för datorer, serverarkitektur och datahantering. Hans homelab-arbete följer samma mönster: håll det fysiska omfånget hanterbart, återanvänd praktisk hårdvara där det är rimligt och lämna tillräckligt med utrymme för fortsatta experiment.
Hans Zima-resa gick från att upptäcka ZimaOS på en egenbyggd NAS till att göra en ZimaBoard 2 till kontrollpunkt för ett lagringsbygge som växte till över 350 TB. Hans offentliga aktivitet på Reddit fortsätter i samma praktiska anda genom diskussioner om lagring, HBA-kort, virtualisering, nätverk, self-hosting och ZimaOS. Du kan följa MorgothTheBauglir på Reddit för att se hur projekten och samtalen fortsätter utanför den här sidan.
Från ZimaOS till en dedikerad ZimaBoard 2
Vägen till ZimaBoard 2 började med mjukvara. Enligt ZimaSpaces ursprungliga fallstudie kom Igor först i kontakt med ZimaOS via NAS Compares och installerade det på en egenbyggd NAS. Det som utmärkte sig var inte en enskild funktion, utan kombinationen av ett genomarbetat gränssnitt, låg resursförbrukning och ett self-hosting-arbetsflöde som kändes lättillgängligt utan att dölja den underliggande hårdvaran.
Efter att ha gått med i IceWhale-communityn vann han en ZimaBoard 2 832 i ett evenemang och gick snart över till den mer avancerade ZimaBoard 2 1664. Det gav nästa lagringsexperiment något som hans tidigare generiska mini-PC inte kunde erbjuda i samma kompakta format: en direkt PCIe-expansionsväg som kunde fungera som utgångspunkt för ett mycket större system.
Från en enda PCIe-expansionsväg till över 350 TB
Projektet som fick bygget att sticka ut började som ett NAS-system på 80 TB och fortsatte att växa. I januari 2026 hade MorgothTheBauglir byggt om det kring ZimaBoard 2 i ett 10-tums minirack och utökat den blandade lagringspoolen till över 350 TB.
Den centrala hårdvarukedjan kombinerade ZimaBoard 2 med en IBM M1210 HBA och en Adaptec AEC-82885T SAS-expander. Runt detta använde han en blandning av hårddiskar och SSD-enheter samt dedikerad strömfördelning, aluminiumprofiler, omfattande kablage, kylning och 3D-printade fästen. Resultatet liknade mindre ett färdigt NAS-system från hyllan och mer ett kompakt lagringschassi som utformats kring de exakta komponenterna, kapaciteten och det tillgängliga utrymmet.
ZimaSpace dokumenterade arkitekturen, programvarustacken och expansionsbesluten i fallstudien om ZimaBoard 2-lagring på över 350 TB. Den ursprungliga byggloggen på Reddit ger ytterligare detaljer från verkstaden: problem med luftflödet, diskhållare, 3D-printade delar, kabeldragning, strömfördelning och de små speciallösningar som krävdes för att göra det tätpackade racket praktiskt.
Expansion som konstruktionsverktyg
För det här bygget var den viktigaste ZimaBoard 2-funktionen inte bara att det kunde ansluta mer lagring. Det viktiga var att PCIe-platsen kunde ta emot ett riktigt HBA-kort direkt. Det gjorde att systemet kunde gå från ett kompakt kort till en SAS-expansionstopologi utan att själva värden behövde bli en stor konventionell server.
MorgothTheBauglir beskrev skillnaden med enkla ord: direkt HBA-stöd förändrar hur ett kompakt NAS-system med hög densitet kan utformas. Kortet förblev litet medan lagringsinfrastrukturen runt det blev betydligt större.
Kylning, strömförsörjning och utrymme var en del av lagringsproblemet
Kapaciteten var bara en av begränsningarna. Varmt väder, företagsdiskar, begränsat utrymme i hemmet och ett tätt 10-tumsrack innebar att luftflöde och strömfördelning behövde utformas tillsammans med datasökvägen. Fläktar, diskfästen, placering av nätaggregat och kabeldragning behövde alla fungera med samma fysiska layout.
Det är en av anledningarna till att bygget är värdefullt även bortom den uppmärksammade kapaciteten. Det visar att mycket stor lagring i hemmet sällan bara handlar om att ansluta fler diskar; mekanisk layout, temperaturhantering, strömförsörjning, kabeldragning och servicevänlighet blir en del av arkitekturen.
Att välja programvara utifrån begränsningen
Lagringsprogramvaran följde samma logik där begränsningarna stod i centrum. I stället för att bygga hela poolen kring en minneskrävande ZFS-topologi använde han Proxmox VE som virtualiseringslager, en resurssnål virtuell Windows IoT-maskin för lagringshanteringen och StableBit DrivePool för flexibel poolning och mappduplicering över enheter med blandade kapaciteter.
Hans sammanfattning i ZimaSpaces fallstudie var medvetet okomplicerad: "Alla behöver inte RAID." Poängen var inte att en viss lagringsdesign är universellt bättre. Poängen var att programvarustacken bör anpassas efter den faktiska hårdvaran, återställningsmodellen och arbetsbelastningen, i stället för att väljas för att den är det mest avancerade alternativet som finns.
Att dela bygget, inte bara resultatet
Den offentliga byggloggen är en viktig del av berättelsen. MorgothTheBauglir publicerade inte bara ett foto av ett färdigt rack; han listade de viktigaste komponenterna, länkade till 3D-utskriftsmodellerna, beskrev problemen vid monteringen och välkomnade frågor om delar och utmaningar. I den efterföljande diskussionen besvarade han frågor om strömförbrukning, nätverkshastighet, lagringsanvändning, aluminiumprofiler, diskfästen och framtida uppgraderingar.
Samma praktiska ton märks i hans bredare diskussioner om självhostning. På sin Reddit-profil har han rekommenderat HBA-lösningar i IT-läge för SATA-utbyggnad och, i en senare diskussion om migrering, beskrivit ZimaOS som sitt val när användarvänlighet prioriteras, samtidigt som han har föreslagit Proxmox-virtualisering när ögonblicksbilder, återställning och enklare migrering är viktiga.
Att pressa bygget tills gränsen blev synlig
Berättelsen slutade inte vid 350 TB. När systemet växte förbi 450 TB rapporterade MorgothTheBauglir långsammare nätverksöverföringar tillsammans med ihållande CPU-belastning och många avbrott. ZimaBoard 2-konfigurationen hade fungerat vid 350-TB-etappen, men den större arbetsbelastningen gjorde nästa flaskhals synlig.
I stället för att se det som ett misslyckande ändrade han arkitekturen. Den primära beräkningskraften för lagringen flyttades till en värddator med högre prestanda, mer minne, snabbare PCIe-anslutning och 10GbE, medan arbetet med racken och utbyggnaden fortsatte att utvecklas. Hans uppdatering om 450 TB på Reddit är en användbar uppföljning eftersom den dokumenterar punkten då en framgångsrik kompakt konstruktion till slut blev tillräckligt stor för att motivera en annan klass av värddator.
Den utvecklingen är en mer användbar lärdom än ett påstående om obegränsad kapacitet. ZimaBoard 2 möjliggjorde ett ovanligt tätt experiment med lagring i hemmet; experimentet gav sedan konkret information om var plattformen passade och var arbetsbelastningen hade vuxit förbi dess kapacitet.
Det som förblev konstant
Trots förändringarna i hårdvaran är samma ingenjörsmässiga arbetssätt fortfarande tydliga: använd den utbyggnadsväg som löser det aktuella problemet, undvik komplexitet som inte ger tillräcklig nytta, låt den mekaniska konstruktionen vara en del av systemarkitekturen och dela tillräckligt med detaljer för att andra ska kunna lära sig av resultatet.
Det är också därför relationen mellan denna användarberättelse och den tekniska fallstudien är viktig. Artikeln om 350 TB förklarar arkitekturen. Den här sidan dokumenterar personen bakom bygget, besluten som ledde dit och vad som hände när projektet fortsatte att växa.
Berättelsen skrivs fortfarande
Berättelsen om MorgothTheBauglir och Zima skrivs fortfarande. Projektet har redan gått från en mindre gör-det-själv-NAS till ett ZimaBoard 2-system på över 350 TB och därefter in i en ny fas på över 450 TB. Racken, lagringspoolen och programvaruvalen fortsätter att förändras när nya begränsningar uppstår.
Om du vill ha den tekniska genomgången av ZimaBoard 2-etappen kan du läsa den fullständiga fallstudien om ZimaBoard 2 på 350 TB. Om du vill se vad han bygger, testar och rekommenderar härnäst kan du följa MorgothTheBauglir på Reddit.
