Så bygger RG 4 Tech ett privat moln med ZimaBoard 2

RG 4 Tech gör ZimaBoard 2 till mer än en kompakt filserver. Hans bygge kombinerar tyst x86-hårdvara, två direktanslutna diskar, en ZimaOS RAID 1-lagringspool och Home Assistant i ett webbläsarhanterat system. Resultatet är en praktisk grund för ett privat moln med filer och smarthemstjänster – men det kräver fortfarande en oberoende säkerhetskopia och en driftsättningsplan som tar hänsyn till skillnaderna mellan Home Assistant Container och Home Assistant OS.

Tack till RG 4 Tech för att han dokumenterade hela konfigurationen. Hans ursprungliga video går igenom hårdvaran, den interna kylningen, den inledande ZimaOS-konfigurationen, RAID 1-konfigurationen med två diskar, installationen av applikationer och introduktionen till Home Assistant.

Källnotis: Den här artikeln omorganiserar konfigurationen och observationerna som visas i RG 4 Techs video. Den utgår inte från att alla enheter som syns i videon levererades av ZimaSpace, eftersom något sådant samarbetsanspråk inte har fastställts oberoende här. Gränssnittsdetaljer, programversioner, tillgängliga paket, temperaturer och kompatibilitet kan ändras efter publiceringen.

Resultatet: ZimaBoard 2 ger RG 4 Tech en lågprofilerad plattform för lokal lagring och smarthemstyrning. RAID 1 håller lagringspoolen tillgänglig om en av diskarna går sönder, medan Home Assistant tillför ett lokalt automatiseringslager. Ingen av funktionerna eliminerar behovet av att säkerhetskopiera viktiga data och konfigurationer utanför servern.

Varför RG 4 Tech börjar med en lokal hemmaserver

Videons ”farväl till molnet”-vinkel handlar inte bara om att slippa en månadsavgift. En hemmaserver förändrar vem som kontrollerar lagringshårdvaran, vilka applikationer som behandlar data, hur tjänster exponeras mot nätverket och när kapaciteten utökas. Dessa val blir särskilt relevanta när personliga filer och smarthemaktivitet annars skulle vara uppdelade mellan flera leverantörer.

Lokalt ägande innebär också ett större ansvar. Ägaren måste övervaka diskarnas hälsa, installera uppdateringar, hantera användaråtkomst, underhålla säkerhetskopior och återställa tjänster efter ett fel. Ett privat moln är därför inte en molntjänst där leverantören har tagits bort, utan en liten del av infrastrukturen som kräver en driftplan.

RG 4 Tech använder ZimaBoard 2 som en flexibel bas snarare än som en försluten apparat. Kortet kan börja som lagringsserver och sedan köra ytterligare applikationer via ZimaOS, så att systemet kan växa utifrån ett verkligt hushålls arbetsflöde.

Vad gör ZimaBoard 2 lämpat för den här konfigurationen

ZimaBoard 2 Mini Home Server kombinerar en Intel N150-processor, inbyggt minne och systemlagring, två 2,5GbE-portar, två SATA-anslutningar och ett öppet PCIe-expansionsgränssnitt. Den kombinationen är viktig eftersom en hemmaserver behöver mer än processorkraft: den behöver praktiska anslutningsvägar till lagring, nätverk och framtida maskinvara.

Två SATA-portar gör det möjligt att ansluta ett par hårddiskar eller SSD-enheter direkt utan att vara beroende av en USB-brygga för lagring. Dubbla nätverksgränssnitt kan användas för en lagringslänk, ett segmenterat nätverk, ett routerprojekt eller en annan topologi där en enda port skulle bli begränsande. PCIe lämnar utrymme för en vald expansion, till exempel NVMe-lagring eller en annan uppgiftsspecifik adapter.

Plattformen är fortfarande kompakt. En PCIe-anslutning kan inte rymma alla expansioner samtidigt, två SATA-portar gör inte enheten till en NAS med många diskplatser, och en Intel N150 bör inte betraktas som en processor för virtualisering med många kärnor. Konstruktionen fungerar bäst när serverns huvudsakliga roller väljs innan tillbehör läggs till.

När chassit öppnas avslöjas kylstrategin

Klockan 08:16 öppnar RG 4 Tech höljet till ZimaBoard 2 och visar kortets interna layout samt den plats som används för aktiv kylning. Den här vyn är användbar eftersom det färdiga yttre inte ensamt förklarar hur värmen leds bort från processorn och närliggande komponenter.

Aluminiumkonstruktionen bidrar till värmeavledning, medan en fläkt kan tillföra luftflöde när kortet placeras på en varmare plats eller förväntas hantera tyngre arbete under längre tid. Lagringsaktivitet, programindexering, rumstemperatur, kabelplacering och närliggande ytor påverkar alla de termiska förhållandena runt en verklig installation.

Aktiv kylning bör ses som ett beslut utifrån arbetsbelastning, inte som dekoration. En lätt belastad filserver kan fungera annorlunda än samma kort när det samtidigt hanterar lagringsöverföringar, programuppdateringar, medieindexering och smarta hem-tjänster. Efter monteringen bör ägaren kontrollera temperaturerna under den avsedda kombinerade belastningen i stället för att enbart förlita sig på vilovärden.

Planera den fysiska lagringen innan lagringspoolen skapas

RG 4 Tech ansluter två enheter innan lagringen konfigureras i ZimaOS. Ordningen kan verka självklar, men den förhindrar en viktig typ av misstag: att skapa utdelningar eller installera program innan man har bestämt vilken disk som ska innehålla aktiva data, vilken disk som ska ingå i redundansen och var säkerhetskopiorna ska lagras.

En server med två diskar erbjuder flera möjliga layouter. Diskarna kan förbli oberoende, kombineras för bättre prestanda eller större kapacitet, eller spegla varandra för redundans. Det rätta valet beror på om prioriteten är användbart utrymme, kontinuerlig tillgänglighet efter ett diskfel eller åtskillnad mellan olika dataklasser.

Det är också viktigt att matcha enheterna. En spegling visar normalt en kapacitet som baseras på den mindre medlemmen, så en kombination av enheter med väsentligt olika storlek kan leda till outnyttjat utrymme. Båda enheterna bör testas, deras hälsa övervakas och deras serienummer dokumenteras innan viktiga data flyttas till den nya poolen.

Skapa en RAID 1-pool med två enheter i ZimaOS

Vid 16:50 använder RG 4 Tech ZimaOS lagringsgränssnitt för att välja de två diskarna och konfigurera RAID 1. Layouten skriver speglade kopior över medlemsenheterna och byter bort hälften av den sammanlagda råkapaciteten mot möjligheten att hålla poolen tillgänglig när en enhet går sönder.

ZimaOS listar RAID 1 som sitt redundansfokuserade alternativ i guiden om RAID-alternativ i ZimaOS. Det grafiska arbetsflödet sänker tröskeln för den som bygger sin första NAS, eftersom användaren kan identifiera enheterna och välja lagringsläge utan att behöva bygga arrayen helt från kommandoraden.

Gränssnittet eliminerar inte behovet av att verifiera valet. När en ny array skapas kan befintliga data på de valda diskarna raderas. Enheternas identitet, kapacitet och eventuella kopior som behövs bör bekräftas innan den slutliga åtgärden godkänns.

Varför RAID 1 är användbart men ändå inte är en säkerhetskopia

RAID 1 hanterar ett specifikt fel: förlusten av en medlemsenhet. Om en disk slutar fungera kan den andra kopian hålla poolen tillgänglig medan den felaktiga enheten byts ut och arrayen byggs om. Den tillgängligheten är värdefull för en server som förväntas förbli online.

Spegligen upprepar logiska ändringar på båda enheterna. En oavsiktlig radering, en överskriven fil, en ransomware-attack, ett skadat programtillstånd eller ett felaktigt administratörskommando kan därför påverka båda kopiorna. Stöld, elektriska skador eller fysisk förlust av hela servern kan ta bort hela arrayen på en gång.

Den säkrare utformningen kombinerar RAID 1 med versionshanterade säkerhetskopior som lagras på annan plats. ZimaSpace-guiden om RAID-layouter och planering av NAS-säkerhetskopiering förklarar varför redundans, säkerhetkopieringshistorik och en kopia på en annan enhet hanterar olika risker.

ZimaOS förvandlar lagringshårdvara till en appplattform

När poolen är tillgänglig behöver servern inte förbli en enkel nätverksresurs. ZimaOS lägger till webbläsarbaserad filhantering och en applikationsmiljö, så att lagring och självhostade tjänster kan hanteras från samma gränssnitt.

Det är här hårdvaran blir mer användbar än ett hårddiskkabinett med två fack. Applikationer kan använda den lokala lagringspoolen för beständiga filer, medan driftmiljön hanterar deras livscykel. Ett hushåll kan börja med fillagring och sedan lägga till en tjänst i taget, i stället för att driftsätta en komplett hem-labbstack första dagen.

Applikationsdata bör inte tillåtas bli osynlig infrastruktur. Innan en tjänst installeras bör du identifiera dess konfigurationskatalog, databas, uppladdade filer, nätverksportar och metod för säkerhetskopiering. En körande container är enkel att återskapa; tillståndet inuti den kanske inte är det.

Installation av Home Assistant ger lokal kontroll över smarthemmet

Klockan 19:07 har Home Assistant startat och RG 4 Tech når sin första introduktionsskärm. Detta bekräftar att ZimaBoard 2 kan köra applikationen tillsammans med lagringsmiljön och ger projektet en ytterligare tydlig roll: lokal samordning av kompatibla smarthem-enheter och automatiseringar.

Home Assistant kan hålla många beslut inom hemnätverket i stället för att skicka varje automatisering via en leverantörs molntjänst. Den faktiska graden av lokal kontroll beror fortfarande på varje enhet och integration. Vissa produkter erbjuder ett lokalt API, medan andra fortfarande kräver ett externt konto eller en molnanslutning.

Den första skärmen är början på driftsättningen, inte slutet. Ägaren behöver fortfarande skapa ett administratörskonto, ange hemmets plats, granska upptäckta enheter, säkra fjärråtkomst, testa automatiseringar och skapa ett säkerhetskopieringsschema innan systemet blir tillförlitligt.

Home Assistant Container och Home Assistant OS är olika alternativ

Att installera Home Assistant via en befintlig applikationsplattform innebär vanligtvis att Home Assistant Container körs. Den officiella översikten över installation av Home Assistant förklarar att containeralternativet använder en värd och en containermiljö som användaren själv hanterar. Det inkluderar inte heller det app-system som finns i Home Assistant OS.

Containerdistribution passar en mångsidig ZimaOS-server eftersom Home Assistant kan köras tillsammans med lagring och andra applikationer. Home Assistant OS är det mer appliance-liknande valet när hela maskinen är dedikerad till Home Assistant och användaren vill ha dess integrerade hanteringsupplevelse.

RG 4 Techs tillvägagångssätt är attraktivt eftersom det konsoliderar roller. Den bekvämligheten bör vägas mot felomfattningen: omstart eller reparation av den gemensamma servern kan tillfälligt påverka både filåtkomst och smarthemstyrning.

Lagring och smarthemstjänster behöver separata återställningsplaner

En speglad lagringspool och en körande Home Assistant-instans skyddar olika saker. RAID 1 hjälper poolen att överleva ett fel på en medlemsdisk. En säkerhetskopia av Home Assistant bevarar konfiguration, automatiseringar och applikationstillstånd som stöds. Ingen av dem skapar automatiskt en säker kopia utanför servern.

Home Assistant erbjuder nu skapande och återställning av säkerhetskopior för olika installationstyper, enligt dokumentationen för säkerhetskopieringsintegrationen. Dessa säkerhetskopior bör kopieras till en destination som inte är beroende av samma tvådiskarsarray och samma fysiska maskin.

Ett praktiskt återställningstest ställer två separata frågor: kan hushållet återställa sina filer efter att ha förlorat NAS-enheten, och kan det återställa Home Assistant efter att ha förlorat applikationsvärden? Om båda svaren beror på att samma server fortfarande fungerar har systemet fortfarande en gemensam fel-domän.

Vad den här konsoliderade servern gör bra

Vem bör bygga samma typ av ZimaBoard 2-server?

Den här konfigurationen passar den som vill ha sitt första privata moln, en familje-NAS med två diskar, en lokal smart hem-styrenhet eller en kompakt applikationsvärd utan att behöva avsätta en separat dator för varje roll. Den är särskilt attraktiv när tyst drift och möjligheter att bygga ut den öppna hårdvaran är viktigare än en polerad, försluten apparatdesign.

En dedikerad Home Assistant-enhet kan vara det bättre valet när automatiseringar måste vara tillgängliga under NAS-underhåll. En större NAS med flera diskplatser passar användare som behöver flera kapacitetsnivåer, flera oberoende lagringspooler eller bättre tolerans mot diskfel. En server med fler kärnor är lämpligare för många tunga virtuella maskiner eller kontinuerliga beräkningsbelastningar.

Beslutet bör börja med felområden, inte bara med antalet appar som hårdvaran kan köra. Konsolidering sparar utrymme, energi och administration, men innebär också att en omstart eller ett hårdvaruproblem kan avbryta flera hushållstjänster samtidigt.

RG 4 Tech bygger ett privat moln kring tydliga hushållsfunktioner

RG 4 Techs projekt lyckas eftersom varje större steg har ett tydligt syfte. Att öppna chassit visar hur värmehantering och underhåll är utformade. Genom att ansluta två enheter skapas en lagringsgrund. RAID 1 förbättrar tillgängligheten efter ett diskfel. ZimaOS gör lagringen enklare att hantera, och Home Assistant utökar maskinen till lokal automatisering.

Bygget är som starkast när fördelarna beskrivs korrekt. RAID 1 ger redundans, inte säkerhetskopiering. En Home Assistant-container är inte identisk med Home Assistant OS. En enda tyst server kan samla många användbara funktioner, men den samlar också riskerna om säkerhetskopior och återställningsplaner inte finns utanför servern.

Titta på RG 4 Techs kompletta video för en inspektion av den interna hårdvaran, lagringskonfiguration i ZimaOS, RAID 1-arbetsflöde och installation av Home Assistant. För ett annat sätt att konfigurera ett lokalt smart hem kan du se hur du kör Home Assistant på ZimaBoard, eller gå med i ZimaSpaces Discord-community för att jämföra hemmserverbyggen med andra användare.