Så förhindrar du att ögonblicksbildsreplikering fyller målpoolen

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Prevent Snapshot Replication From Filling the Destination Pool

Snapshotreplikering fyller en destinationspool när kvarhållna snapshots och ändrade block ackumuleras snabbare än destinations rensningspolicy kan frigöra dem.

Den förebyggande lösningen är att utforma källans kvarhållning, destinationens kvarhållning, replikeringens intervall och larm för ledigt utrymme som en enda policy. En replika kan med rätta behålla mer historik än källan, men det valet måste ha tydliga gränser. Följ vilka snapshots som behövs som baser för inkrementella överföringar, hur mycket unika data äldre snapshots låser, om bookmarks kan ersätta vissa lokala snapshots på källan och hur mycket marginal som återstår innan nästa stora ändringsmängd anländer.

Ange en kvarhållningspolicy för destinationen

Bestäm hur många återställningspunkter per timme, dag, vecka och månad destinationen ska behålla och dokumentera varför den historiken skiljer sig från källans. Anta inte att replikeringsprogram automatiskt rensar alla gamla snapshots på destinationen när källan tar bort dem.

En översikt över ZFS-replikering förklarar att replikering kräver en snapshot-policy eftersom snapshots både är återställningspunkter och gränser för inkrementella överföringar.

Använd den kortaste kvarhållningstiden för datauppsättningar med hög förändringstakt, såvida inte längre historik har ett konkret återställningsvärde. Behåll arkiv med låg förändringstakt enligt ett annat schema så att en global policy inte slösar utrymme där täta återställningspunkter ger liten nytta.

Uppskatta hur mycket förändringar äldre snapshots låser

Mät snapshotens USED, mängden skriven data mellan snapshots och destinationspoolens lediga utrymme före och efter stora borttagningar, flyttar, mediebyten eller omskrivningar av virtuella maskiner. Ett snapshot kan hålla gamla block vid liv även efter att den aktiva datan har försvunnit.

En TrueNAS-anteckning om replikering varnar för att snapshot-förändringar behåller gamla block även när den aktuella aktiva datauppsättningen blir mindre.

Använd den förändringstakten för att dimensionera kvarhållningen. En destination med 30 dagar av snabbt föränderliga VM-avbildningar kan behöva betydligt mer kapacitet än en annan datauppsättning med samma aktiva storlek men huvudsakligen tilläggsbaserade familjefoton.

Reservera marginal i poolen för nästa replikering

Ange en operativ gräns för ledigt utrymme som tar hänsyn till den största realistiska inkommande inkrementella överföringen, lokal snapshot-tillväxt och normalt filsystemspill. Skicka larm innan gränsen nås, inte när poolen redan är nästan full.

Oracles diskussion om snapshot-kvarhållning noterar att kvarhållning styr snapshot-tillväxten i stället för att behandla snapshots som kostnadsfria bara för att de först skapas billigt.

Pausa eller förkorta icke-kritisk kvarhållning innan destinationen når ett akut läge. Ett replikationsmål behöver utrymme för att ta emot och skriva nya block, så att bara lämna tillräckligt med utrymme för dagens aktiva datauppsättning är ingen säker kapacitetsplan.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Använd bookmarks där de bevarar inkrementell historik

När din ZFS-version och dina replikeringsverktyg stöder bookmarks bör du utvärdera om ett bookmark kan bevara referensen för en inkrementell sändning efter att ett äldre snapshot inte längre behövs som en fullständig lokal återställningspunkt.

En design för säkerhetskopiering till en extern plats visar hur bookmarks bevarar baser för inkrementella överföringar samtidigt som snapshot-kvarhållningen kan vara fristående.

Ersätt inte alla snapshots med bookmarks. Återställningshistorik på destinationen kräver fortfarande faktiska snapshots, och replikeringsverktyg skiljer sig åt i hur de hanterar gemensamma baser. Använd bookmarks endast där de förenklar hanteringen på källan utan att försvaga destinationens återställningsmål.

Skydda endast de snapshots som replikeringen fortfarande behöver

Identifiera det senaste gemensamma snapshotet som delas av källan och destinationen innan du rensar. När verktygen använder holds eller motsvarande skydd ska du kontrollera att rensningsjobben respekterar dem och att föråldrade holds till slut frigörs.

FreeBSD:s ZFS-handbok förklarar att holds skyddar gemensamma snapshots tills holden uttryckligen frigörs.

Behåll inte alla historiska snapshots bara för att en gemensam bas krävs. Skydda den lilla uppsättning som replikeringen faktiskt behöver och låt sedan destinationens kvarhållningspolicy styra över äldre, fristående återställningspunkter.

Granska replikeringssnapshots separat från säkerhetskopieringshistoriken

Vissa verktyg skapar egna synkroniseringssnapshots utöver dina schemalagda snapshots per timme eller dag. Lista båda kategorierna på destinationen och se till att den verktygsskapade uppsättningen inte kan växa utan en rensningsregel.

En diskussion om Sanoid och Syncoid förklarar att synkroniseringssnapshots fungerar som skyddsräcken snarare än att varje replikeringssnapshot är avsett som långsiktig säkerhetskopieringshistorik.

Granska destinationen varje månad eller efter en stor flytt av en datauppsättning. Policyn är sund när förväntade återställningspunkter finns kvar, nästa inkrementella överföring har en giltig gemensam bas och poolens lediga utrymme ligger över den angivna gränsen. Den relaterade ZimaSpace-artikeln om diagnostik av snapshot-utrymme är nästa steg när destinationen redan oväntat är full.

Vanliga frågor

Bör destinationen behålla exakt samma snapshots som källan?

Inte nödvändigtvis. Ett säkerhetskopieringsmål kan behålla längre historik, men skillnaden bör vara avsiktlig, kapacitetstestad och styras av en egen kvarhållningspolicy.

Kan borttagning av filer på källan omedelbart frigöra utrymme på destinationen?

Nej. Replikerade snapshots kan fortsätta referera till äldre block efter att den aktiva filen har försvunnit. Utrymme frigörs först när inget kvarhållet snapshot eller någon annan referens längre behöver dessa block.

Frigörs alltid mest utrymme genom att ta bort det äldsta snapshotet?

Nej. Snapshotutrymme delas mellan återställningspunkter. Uppskatta eller mät det unika refererade utrymmet och skydda alla gemensamma snapshots som fortfarande krävs för inkrementell replikering.