Konfigurera separata ZFS-dataset för appdata, säkerhetskopior och nedladdningar genom att ge varje arbetsbelastning sin egen monteringspunkt, sina egna egenskaper, sin egen ögonblicksbildspolicy och sin egen rensningsgräns.
På en hemmaserver börjar dessa mappar ofta i en enda stor delad mapp eftersom det är enkelt. Senare behöver de olika lagringstider, behörigheter, komprimering, recordsize, kvoter och återställningsbeteenden. Därför är den säkra lösningen att dela upp dem innan en arbetsbelastning med hög aktivitet bestämmer policyn för allt annat.
Bestäm vad varje dataset ska skydda
Börja med varje arbetsbelastnings uppgift. Appdata behöver vanligtvis konsekventa ögonblicksbilder och noggranna återställningar, säkerhetskopior behöver kapacitetskontroll och lagringstid, och nedladdningar behöver kunna rensas enkelt utan att bli en del av det långsiktiga skyddet.
ZFS-dataset är administrativa gränser lika mycket som de är mappar. Egenskaper som komprimering, kvoter och reservationer, monteringspunkter och ögonblicksbilder kan hanteras per dataset. Det är därför det är användbart att separera arbetsbelastningar även när de ligger i samma pool.
Skriv ner de tre avsedda rollerna innan du skapar något: appdata som du skulle återställa, säkerhetskopierade data som du skulle behålla samt data som kan tas bort eller laddas ned igen. Om två mappar behöver samma återställnings- och rensningspolicy behöver de kanske inte vara separata dataset ännu.
Skapa tydliga monteringspunkter innan du flyttar data
Välj monteringspunkter som gör uppdelningen tydlig för både appar och människor. En enkel struktur kan använda en överordnad mapp som /srv/storage och sedan underordnade monteringspunkter för appdata, säkerhetskopior och nedladdningar.
OpenZFS-dokumentationen för zfs-set beskriver hur datasettegenskaper anges med zfs set, medan den övergripande dokumentationen om egenskaper täcker monteringspunkters beteende och arv av egenskaper. Det innebär att du kan skapa en överordnad nivå med gemensamma standardvärden och bara åsidosätta dem för de underordnade dataset som behöver ett annat beteende.
Skapa tomma dataset först, bekräfta att de monteras på rätt plats och flytta sedan data. Avbryt om en applikation fortfarande skriver till den gamla sökvägen. Migrera applikationen under ett planerat underhållsfönster så att du kan rulla tillbaka ändringen på ett ordnat sätt.
Ge appdata den mest noggranna ögonblicksbildspolicyn
Appdata ändras vanligtvis i små men viktiga delar: databaser, konfigurationsfiler, användaruppladdningar, containervolymar och applikationstillstånd. Att förlora en fil kan vara mindre synligt än att förlora en hel säkerhetskopieringsmapp, men att återställa fel tidpunkt kan göra en app obrukbar.
OpenZFS dokumentation om egenskaper visar att egenskaper på datasetnivå kan ärvas eller åsidosättas. Det gör att appdata kan ha tätare ögonblicksbilder eller en annan komprimering utan att samma val tvingas på nedladdningar.
För appdata bör du föredra täta ögonblicksbilder, försiktig rensning och ett återställningstest för en representativ applikation. Om en app använder en aktiv databas bör du samordna ögonblicksbilderna med appens egen säkerhetskopierings- eller pausningsmetod i stället för att anta att filsystemets ögonblicksbild är konsekvent ur applikationens perspektiv.
Ge säkerhetskopior kapacitetsgränser och lagringsgränser
Säkerhetskopior förtjänar ett eget dataset eftersom de kan växa i det tysta genom lagringstid, dedupliceringsmetadata, syntetiska fullständiga säkerhetskopior, replikering eller gamla klientjobb. Ett säkerhetskopieringsdataset utan gräns kan förbruka det utrymme som appar eller aktiva delade mappar behöver.
Oracles guide om ZFS-egenskaper förklarar kvoter och reservationer som kontroller på datasetnivå. Därför är de användbara för att hindra säkerhetskopior från att tränga undan orelaterade arbetsbelastningar.
Ange en kvot eller åtminstone en varningsgräns för säkerhetskopieringsdatasetet och anpassa sedan lagringstiden för ögonblicksbilder till säkerhetskopieringsverktygets egen lagringstid. Behåll inte filsystemets ögonblicksbilder för evigt runt säkerhetskopior som säkerhetskopieringsprogrammet anser redan vara rensade.
Gör nedladdningar enkla att återskapa och ta bort
Nedladdningar är vanligtvis det minst viktiga datasetet eftersom de flesta filer är tillfälliga, kan laddas ned igen eller ligger i kö innan de sorteras. De behöver ändå en egen gräns eftersom de snabbt kan fylla en pool och ärva ögonblicksbilder som de inte behöver.
Ett separat nedladdningsdataset låter dig minska eller inaktivera lång lagringstid, anpassa komprimeringen efter filtypen och rensa katalogen utan att påverka appdata eller säkerhetskopior.
Använd en liten kvot eller schemalagd rensning om nedladdningar regelbundet fyller utrymmet. Om en fil blir viktig bör du flytta den till det dataset vars policy passar den nya rollen, i stället för att behålla långsiktiga data i det tillfälliga området.
Verifiera behörigheter, ögonblicksbilder och återställningar efter uppdelningen
Konfigurationen är inte klar när dataseten finns. Den är klar när appar startar korrekt, säkerhetskopior hamnar i rätt dataset, nedladdningar kan rensas säkert och ögonblicksbilderna visar de förväntade gränserna.
Genomför ett återställningstest för varje kategori: återställ en liten appkonfiguration, visa en återställningspunkt för en säkerhetskopia och ta bort eller rensa en testfil för nedladdningar. Det bekräftar att datasetgränsen motsvarar den operativa gränsen.
Om en ögonblicksbild oväntat inkluderar nedladdningar eller saknar appdata ska du stoppa och korrigera monteringspunkten eller datasetets tilldelning innan du lägger till mer automatisering. Det rena slutresultatet är odramatiskt: varje arbetsbelastning har en policy som du kan förklara med en enda mening.
Vanliga frågor
Bör appdata och säkerhetskopior någonsin dela ett dataset?
Endast när de verkligen delar samma krav på lagringstid, kvot, ögonblicksbilder och återställning. På de flesta hemmaservrar förtjänar appdata och säkerhetskopior olika policyer.
Kan jag dela upp dataset efter att data redan finns?
Ja, men behandla det som en migrering. Skapa de nya dataseten, stoppa apparna eller jobben som skriver data, flytta datan, uppdatera sökvägarna, testa och behåll den gamla kopian tills de nya monteringspunkterna har verifierats.
Som ett relaterat planeringssteg kan du läsa om hur datasetgränser samverkar med replikeringskapacitet. ZimaSpaces guide om ögonblicksbildsreplikering som fyller destinationspoolen visar varför lagringstid och datasetets omfattning bör utformas tillsammans.
Support och tips
Mer att läsa

Guide till lagring av live-tv-inspelningar för kapacitet, lagringstid och rensning
Mät verkliga inspelningar, reservera marginal, kombinera gränser för ålder och kapacitet och bevisa att det äldsta berättigade programmet tas bort innan lagringen blir full.

Arbetsflöde för återställning av metadata för hemmamedia efter en databasåterställning
Skydda det återställda tillståndet, verifiera medieidentitet och sökvägar och reparera sedan saknade omslagsbilder eller matchningar i ett pilotbibliotek innan omfattande metadataändringar görs.

Kompatibilitetschecklista för Jellyfin-klienter för ljud, video och undertexter
Testa representativa filer med en variabel i taget och notera Direct Play, remuxning, ljudkonvertering, videotranskodning eller fel för varje klient.

