ZFS-pooler och RAID-Z: så bygger du en hemma-NAS som aldrig tappar ett enda block

De flesta NAS-system lovar att dina data är säkra så länge en disk går sönder. Verkligheten är krångligare: diskar dör sällan en och en, bitar kan flippa obemärkt, och strömavbrott mitt i en skrivning kan korrumpera hela RAID-grupper. ZFS — filsystem och volymhanterare i ett — byggdes för exakt de problemen.

Här går vi igenom pooler och vdevs, skillnaderna mellan RAID-Z1, Z2 och Z3, när speglar är bättre, hur checksummor och självreparation fungerar — och hur du lägger ut en pool för en hemma-NAS utan att falla i de vanligaste fällorna.

Så fungerar en ZFS-pool: pooler, vdevs och datasets

En ZFS-pool (zpool) är en samling diskar som hanteras som en gemensam resurs. Men poolen i sig ger ingen redundans — den bor i vdevs (virtual devices): en enskild disk, en spegel eller en RAID-Z-grupp. Poolen stripar data över alla vdevs, som RAID 0, så om en vdev dör så dör hela poolen. ZFS viktigaste princip: varje vdev måste själv klara diskbortfall.

Ovanpå poolen ligger datasets och zvols — filsystem och blockvolymer som dynamiskt delar poolens lediga utrymme utan fasta partitionsgränser. Här ställs komprimering, deduplicering och snapshots in, per dataset.

RAID-Z1, RAID-Z2 och RAID-Z3

RAID-Z är ZFS svar på RAID 5 och 6, utan deras svagheter. RAID-Z1 tål en trasig disk, RAID-Z2 med dubbel paritet tål två samtidiga bortfall och RAID-Z3 med trippel paritet tål tre. Till skillnad från traditionell RAID använder RAID-Z dynamisk stripe-bredd: varje block får exakt den paritet det behöver. Dessutom verifieras varje block mot sin checksumma vid läsning — varje block bär sitt eget integritetsbevis.

RAID-Z mot speglar: prestanda och återuppbyggnad

Speglar (mirrors) skriver samma data till två eller tre diskar, utan paritetsberäkning. Det ger full läsprestanda och snabbast möjliga återuppbyggnad (resilver): bara använda block kopieras. RAID-Z måste däremot läsa alla överlevande diskar och räkna om paritet — långsammare, och diskarna belastas hårt just när de är som mest sårbara.

Baksidan är utrymmet: tvåvägsspeglar ger 50 procent användbart utrymme, mot cirka 67 procent för RAID-Z2 med sex diskar. För mediastreaming spelar det liten roll, men för slumpmässig I/O — VM:er, databaser — kan speglar ge flera gånger högre IOPS.

	RAID-Z1	RAID-Z2	RAID-Z3	Spegel (2-vägs)
Tål diskbortfall	1	2	3	1 per vdev
Användbart utrymme (6 diskar)	cirka 83 %	cirka 67 %	cirka 50 %	50 %
Slumpmässig läs-IOPS	Medel	Medel	Medel	Hög
Återuppbyggnadstid	Lång	Längre	Längst	Kort
Paritetskostnad vid skrivning	Låg	Medel	Högre	Ingen
Bäst för	Medialagring	Hemma-NAS	Stora arkiv	VM, databaser

Skrivhålet som ZFS eliminerar

Det klassiska RAID-skrivhålet (write hole) uppstår när strömmen bryts mitt i en stripe-skrivning: vissa diskar har fått nya data, andra inte, och pariteten stämmer inte längre — utan att styrenheten märker det. ZFS drabbas aldrig av detta, eftersom det aldrig skriver över data på plats: varje skrivning är copy-on-write, där nya block skrivs till ledigt utrymme och pekarna byts atomiskt. För synkrona skrivningar används ZIL (ZFS Intent Log) som krockkudde mot strömavbrott.

Checksummor och självreparation

Varje block i ZFS har en checksumma — som standard Fletcher-4, med SHA-256 som alternativ — lagrad separat från datat, i blockets förälder. Tyst korruption (bit rot) upptäcks vid varje läsning, och på en redundant vdev lagar ZFS skadan automatiskt från paritet eller spegel. Kör zpool scrub månadsvis för att verifiera alla checksummor i förebyggande syfte. Utan redundans kan ZFS bara rapportera felet — då är copies=2 värd att känna till för viktiga dataset.

Snapshots och send/receive

En snapshot är en skrivskyddad, ögonblicklig bild av ett dataset som inte kostar extra förrän data ändras — copy-on-write gör att oförändrade block delas med det levande filsystemet. Hundratals snapshots kan behållas billigt och ett dataset rullas tillbaka på sekunder. Med zfs send och zfs receive replikeras snapshots till en annan pool — inkrementellt, komprimerat och krypterat vid behov. Det är grunden för seriös backup: schemalägg dagliga snapshots och skicka dem till en andra maskin.

ARC, L2ARC och SLOG: cache och special-vdevs

ARC (Adaptive Replacement Cache) är ZFS läs-cache i RAM och den viktigaste prestandafaktorn: minst 8 GB för en enkel NAS, mer vid deduplicering. L2ARC är en SSD-utökning av ARC som bara hjälper om arbets-setet är större än RAM men får plats på SSD:n — och den äter själv RAM för indexering. På en hemma-NAS är mer RAM därför oftare bättre än en L2ARC.

SLOG (separate log device) flyttar ZIL till snabba SSD:er med strömavbrottsskydd och hjälper enbart synkrona skrivningar — NFS, databaser, VM:er över nätverk. Den bör vara speglad men behöver inte vara stor: några tiotals gigabyte räcker. För vanlig SMB-delning märks ingen skillnad. Special-vdevs lagrar metadata och små block på SSD medan stora filer stannar på hårddiskar — men dör en ospeglad special-vdev så dör hela poolen.

Layout för hemma-NAS: speglar eller RAID-Z2?

För fyra till sex diskar står valet mellan tvåvägsspeglar och RAID-Z2. Speglar vinner på IOPS, återuppbyggnadstid och expansion — lägg bara till ett spegelpar till. RAID-Z2 vinner på utrymme per krona och tål vilka två diskar som helst, medan en spegelpool dör om båda diskarna i samma par går sönder samtidigt. Undvik fler än åtta till tio diskar per RAID-Z2-grupp — välj hellre två smalare vdevs. Och lägg aldrig till en icke-redundant vdev i en redundant pool.

Expansionsfällor: RAID-Z-expansion i OpenZFS 2.3

Tidigare kunde en RAID-Z-vdev bara växa genom en hel ny vdev — i praktiken en fördubbling av antalet diskar. OpenZFS 2.3 ändrade det med RAID-Z-expansion: med zpool attach pool raidz2-0 ny-disk breddas en grupp en disk i taget, online och utan avbrott. Men nivån ändras aldrig (en Z1 förblir en Z1), diskar kan inte tas bort, och gamla block behåller sin ursprungliga data/paritets-kvot — bara nyskrivna block använder den bredare stripen. Den fulla vinsten kommer gradvis, i takt med att data skrivs om. Expansionen skriver om allt allokerat utrymme, så kör den inte på en 90-procentigt full pool under pågående användning.

Slutsats: praktiska köpråd

Köp diskar av samma storlek — vdev:en begränsas av den minsta disken — och räkna med RAID-Z2 som standardval för fyra till åtta diskar. Välj speglar vid virtuella maskiner eller behov av snabb återuppbyggnad. Lägg budgeten på RAM före L2ARC, satsa på speglad SLOG endast vid tunga synkrona skrivningar, och spegla alltid special-vdevs. Planera layouten från början: vdevs är lätta att lägga till men omöjliga att ta bort, och RAID-Z-nivån kan aldrig ändras.

Kör månatlig scrub, schemalägg snapshots med replikering till en andra pool, och låt aldrig poolen bli mer än 80–90 procent full — både prestanda och copy-on-write mår dåligt av trängsel. Då får du en NAS som inte bara lagrar dina data, utan aktivt vaktar dem.