En hälsning från Zima
Tack, King_Arda, för att du delade med dig av hur en första NAS kan se ut när integritet, experimenterande och praktiskt lärande är lika viktigt som bekvämlighet. Din ZimaBlade blev hem åt Immich, Jellyfin, Duplicati, krypterade säkerhetskopior och fjärråtkomst via den WireGuard-konfiguration du redan litade på i ditt nätverk.
Vi uppskattar särskilt att du dokumenterade problemen lika öppet som det som fungerade – från Docker-konfiguration och förvirring kring lagringssökvägar till säkerhetskopieringsbeteende och planering av strömförsörjningen för en andra enhet. Dessa detaljer ger andra homelab-byggare en mer användbar bild av hur det faktiskt är att gradvis utveckla en liten DIY-NAS över tid.
— Zima
Möt King_Arda
King_Arda är en Reddit-användare som bygger homelab och som i det ursprungliga inlägget beskrev sig själv som cybersäkerhetsstudent med nätverkskunskaper från Cisco CCNA. Han letade inte bara efter en låda som kunde lagra filer. Han ville ha en NAS som också kunde bli en praktisk plats för att experimentera med självhostade tjänster, nätverk, säkerhetskopior och lagring.
Innan han köpte ZimaBlade jämförde han mer konventionella NAS-alternativ med att återanvända en gammal dator. Till slut valde han det mindre x86-systemet eftersom kombinationen av pris, flexibilitet, utseende och utrymme för experimenterande stämde överens med vad han ville få ut av sin första homelab-NAS.
Du kan följa King_Arda på Reddit för att se skaparen bakom denna användarberättelse.
Upplysning: I det ursprungliga Reddit-inlägget berättade King_Arda att han kontaktade Zimas support efter att ha upptäckt att hans befintliga nätaggregat inte var tillräckligt kraftfullt för den lagringskonfiguration han ville använda. Han uppgav att supporten erbjöd fri frakt i utbyte mot att han publicerade Reddit-inlägget, samtidigt som han betonade att han var fri att dela sin egen åsikt. Denna användarberättelse bevarar den upplysningen och hans kritik av installationsupplevelsen.
Från NAS-efterforskning till ZimaBlade
King_Arda övervägde två välbekanta utgångspunkter innan han valde ZimaBlade: att köpa en Synology-NAS eller att återanvända en gammal dator. Hans efterforskning fick honom till slut att välja en mindre DIY-plattform som kunde fungera både som lagring och som en allmän hemmaserver.
Han beskrev valet främst utifrån värde och flexibilitet. Han uppskattade också den bredare idén med programvara med öppen källkod och att ha större kontroll över vilka tjänster som körs på maskinen. Det var viktigt eftersom NAS-enheten aldrig var tänkt att förbli en apparat för endast ett ändamål.
Den aktuella ZimaBlade-dokumentationen beskriver plattformen som en x86-enkortserver med två SATA 3.0-anslutningar, Gigabit Ethernet och PCIe-expansion. King_Ardas inlägg anger inte om hans kort är modellen 3760 eller 7700, så denna berättelse tillskriver honom ingen av dem.
Varför ZimaOS förblev centralt i bygget
King_Arda behöll ZimaOS på systemet i stället för att omedelbart ersätta det med Windows, Proxmox eller ett annat serveroperativsystem. Han uppskattade den webbläsarbaserade filhanteringen och App Store, eftersom de gjorde det enkelt att hitta och distribuera Docker-applikationer utan att varje experiment behövde bli ett kommandoradsprojekt.
Tre applikationer blev centrala i konfigurationen: Immich för foton, Jellyfin för medier och Duplicati för säkerhetskopieringsarbetsflöden. Han experimenterade också med andra appar längs vägen, och det var då maskinen började fungera mindre som en enkel NAS och mer som en riktig homelab-nod.
Integritet utan att avstå från säkerhetskopiering på annan plats
Foton var en av King_Ardas tydligaste anledningar till självhosting. Han sade att han kände sig obekväm med att lämna hela sitt bildbibliotek hos Google, särskilt på grund av oro kring hur molnlagrade foton kan användas i samband med AI.
Hans lösning var inte att helt överge molnlagring. Immich gav honom en fototjänst på maskinvara han själv kontrollerade, medan Duplicati skickade en krypterad säkerhetskopia av bilderna till Google Drive. Han beskrev också hur han förde tillbaka filer från Drive till ZimaBlade, så att ingen av platserna blev den enda kopian.
Det gjorde projektet till en hybrid snarare än ett allt-eller-inget-beslut om integritet: lokala tjänster för daglig kontroll, med krypterad lagring på annan plats kvar som ytterligare ett säkerhetskopieringslager.
WireGuard i stället för ytterligare ett lager för fjärråtkomst
För fjärråtkomst övervägde King_Arda Tailscale men valde WireGuard eftersom hans router redan hade stöd för det. På så sätt kunde han använda en nätverksväg han förstod i stället för att lägga till ytterligare en fjärråtkomsttjänst enbart för NAS-enheten.
Aktuella versioner av ZimaOS dokumenterar även fjärråtkomst via ZimaClient, men King_Ardas konfiguration visar ett annat självhostingsmönster: användare som redan hanterar sitt eget nätverk kan välja det åtkomstlager som passar resten av deras infrastruktur.
Den aktuella guiden för fjärråtkomst i ZimaOS beskriver ZimaClient-vägen; det ursprungliga Reddit-inlägget dokumenterar King_Ardas separata val av WireGuard.
Där den enkla vägen slutade vara enkel
App Store var praktisk, men King_Arda beskrev inte varje installation som helt automatiserad. Han sade att han ibland behövde ändra delar av en Docker-fil innan en applikation fungerade som han ville.
Han rapporterade också ett mer oroande problem med lagringssökvägar: vissa data verkade skrivas till ZimaBlades interna lagring trots att han trodde att han hade valt hårddisken. Säkerhetskopieringsjobb som han förväntade sig skulle köras automatiskt fungerade inte heller alltid som förväntat.
Problemen fick honom inte att överge systemet, men de ändrade vilken typ av användare han skulle rekommendera det till. Hans erfarenhet var betydligt mer positiv för någon som var villig att granska konfigurationen och felsöka än för någon som förväntade sig en apparat som aldrig visar den underliggande modellen för containrar eller lagring.
Aktuell vägledning för ZimaOS gör sökvägarna för appdata tydligare
Den aktuella dokumentationen för ZimaOS ger nu apparnas lagring en egen vägledning. Guiden Sökvägar för applagring rekommenderar att appdata placeras på ett huvudsakligt lagringsutrymme i stället för att stora beständiga datamängder lämnas på systemenheten. Den lyfter särskilt fram fotobibliotek som Immich som arbetsbelastningar som snabbt kan fylla en liten systemdisk.
Det bevisar inte att exakt det problem King_Arda såg har lösts på hans maskin. Det ger däremot tydligare aktuell vägledning för samma typ av problem som han stötte på när han lärde sig hur ZimaOS och Dockers beständighet hänger ihop.
En NAS han skulle rekommendera till experimenterare, inte till alla
King_Ardas övergripande rekommendation var medvetet villkorad. Han gillade enheten och tyckte att den gjorde det han ville, men han skulle inte ge samma upplevelse till en fullständig nybörjare som förväntade sig att varje tjänst skulle fungera utan konfiguration eller undersökning.
För någon som var villig att redigera inställningar, förstå var data lagras och felsöka en container vid behov var hans slutsats betydligt mer positiv. I den meningen fungerade ZimaBlade inte bara som lagring utan också som en lärplattform.
En enhet först, en andra enhet härnäst
Vid tidpunkten för det ursprungliga inlägget kördes NAS-enheten med en hårddisk. King_Arda planerade att lägga till en andra enhet och använda RAID, men han publicerade inte den avsedda RAID-nivån.
Med två diskar innehåller den aktuella ZimaOS-dokumentationen RAID 1 som det speglade alternativet, medan RAID 5 kräver minst tre enheter. Det är användbar bakgrund för läsare, men det ska inte omvandlas till ett påstående om att King_Arda personligen valde RAID 1. Hans offentliga uppdatering sträcker sig endast till planen att lägga till ytterligare en disk.
De bredare alternativen dokumenteras i den aktuella RAID-referensen för ZimaOS.
Planering av strömförsörjningen blev en del av lagringsplanen
Övergången till en andra disk blottlade en annan praktisk begränsning: nätaggregatet i King_Ardas konfiguration var inte tillräckligt kraftfullt för det han ville köra. Det var problemet som fick honom att kontakta supporten och ledde till arrangemanget med fri frakt som avslöjades i Reddit-inlägget.
Aktuell vägledning för NAS-konfiguration med ZimaBlade rekommenderar också att extern strömförsörjning övervägs vid långvarig användning av hårddiskar. Det ursprungliga inlägget anger inte diskmodell, startström, specifikation för adaptern eller ZimaBlade-modell, så denna berättelse försöker inte diagnostisera den exakta elektriska begränsningen i hans konfiguration.
En liten NAS som blev ett praktiskt homelab
När King_Arda skrev om projektet gjorde ZimaBlade betydligt mer än att lagra filer. Den hade blivit en privat fototjänst, en Jellyfin-server, en säkerhetskopieringsnod och en plats där han kunde tillämpa de nätverks- och cybersäkerhetskunskaper han redan studerade.
Det värdefulla i berättelsen är att lärandet kom både från framgångarna och från friktionen. Han behövde avgöra var containerdata skulle lagras, vilket lager för fjärråtkomst som var rimligt, hur en krypterad kopia på annan plats skulle upprätthållas och vad som förändrades när utökad lagring ökade kraven på strömförsörjningen.
Berättelsen skrivs fortfarande
Berättelsen om King_Arda och Zima skrivs fortfarande. Reddit-inlägget från den 31 januari 2026 beskriver ett system som redan var användbart men fortfarande byggdes ut: en hårddisk hanterade verkliga arbetsbelastningar, en andra disk och RAID var planerade, Immich och Jellyfin hade blivit vardagstjänster, Duplicati hanterade säkerhetskopieringen och WireGuard gav fjärråtkomst.
Det finns ingen offentlig uppföljning i det material som verifierats för denna sida som bekräftar uppgraderingen med en andra disk, den slutliga RAID-konfigurationen eller om problemen med appdata och säkerhetskopiering senare löstes. Dessa punkter bör förbli öppna tills King_Arda själv dokumenterar nästa steg.
Om du vill följa källan bakom denna berättelse kan du läsa det ursprungliga Reddit-inlägget om ZimaBlade-NAS eller besöka King_Ardas Reddit-profil.
