Hoe voorkomt u dat snapshotreplicatie de bestemmingspool vult?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Prevent Snapshot Replication From Filling the Destination Pool

Snapshotreplicatie vult een bestemmingspool wanneer bewaarde snapshots en gewijzigde blokken zich sneller opstapelen dan het opschoningsbeleid van de bestemming ze kan vrijgeven.

De preventieve oplossing is om bronretentie, bestemmingsretentie, replicatiefrequentie en waarschuwingen voor vrije ruimte als één beleid te ontwerpen. Een replica kan legitiem meer geschiedenis bewaren dan de bron, maar die keuze moet begrensd zijn. Houd bij welke snapshots nodig zijn als basis voor incrementele overdrachten, hoeveel unieke gegevens oude snapshots vasthouden, of bookmarks sommige lokale snapshots op de bron kunnen vervangen en hoeveel speelruimte resteert voordat de volgende grote wijzigingsset arriveert.

Stel expliciet een retentiebeleid voor de bestemming in

Bepaal hoeveel herstelpunten per uur, per dag, per week en per maand de bestemming moet bewaren en documenteer waarom die geschiedenis afwijkt van die van de bron. Ga er niet van uit dat replicatiesoftware automatisch elke oude snapshot op de bestemming verwijdert wanneer de bron deze verwijdert.

Een overzicht van ZFS-replicatie legt uit dat replicatie een snapshotbeleid nodig heeft, omdat snapshots zowel herstelpunten als grenzen voor incrementele overdrachten zijn.

Pas de kortste retentie toe op datasets met veel wijzigingen, tenzij een langere geschiedenis concrete herstelwaarde heeft. Bewaar archieven met weinig wijzigingen volgens een ander schema, zodat één globaal beleid geen ruimte verspilt waar frequente herstelpunten weinig waarde toevoegen.

Schat hoeveel wijzigingen oude snapshots vasthouden

Meet USED van snapshots, de hoeveelheid geschreven gegevens tussen snapshots en de vrije ruimte in de bestemmingspool vóór en na grote verwijderingen, verplaatsingen, mediavervangingen of herschrijvingen van virtuele machines. Een snapshot kan oude blokken in leven houden nadat livegegevens zijn verdwenen.

Een TrueNAS-notitie over replicatie waarschuwt dat snapshotwijzigingen oude blokken behouden, zelfs wanneer de huidige live-dataset kleiner wordt.

Gebruik die wijzigingssnelheid om de retentie te bepalen. Een bestemming met 30 dagen aan snel veranderende VM-images kan veel meer capaciteit nodig hebben dan een andere dataset met dezelfde livegrootte maar voornamelijk foto’s van familie waaraan alleen gegevens worden toegevoegd.

Reserveer ruimte in de pool voor de volgende replicatie

Stel een operationele ondergrens voor vrije ruimte in die rekening houdt met de grootste realistische binnenkomende incrementele overdracht, lokale snapshotgroei en normale bestandssysteemoverhead. Stuur een waarschuwing voordat de ondergrens wordt bereikt, niet pas wanneer de pool al bijna vol is.

Oracle’s bespreking van snapshotretentie merkt op dat retentie de snapshotgroei beheerst, in plaats van snapshots als gratis te beschouwen omdat ze aanvankelijk goedkoop zijn om aan te maken.

Pauzeer niet-kritieke retentie of verkort deze voordat de bestemming een noodsituatie bereikt. Een replicatiedoel heeft ruimte nodig om nieuwe blokken te ontvangen en vast te leggen. Alleen genoeg ruimte overlaten voor de live-dataset van vandaag is daarom geen veilig capaciteitsplan.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Gebruik bookmarks wanneer ze incrementele geschiedenis behouden

Wanneer je ZFS-versie en replicatietools bookmarks ondersteunen, beoordeel dan of een bookmark de verwijzing voor een incrementele overdracht kan behouden nadat een oude snapshot op de bron niet langer nodig is als volledig lokaal herstelpunt.

Een ontwerp voor offsiteback-ups laat zien hoe bookmarks incrementele bases behouden, terwijl snapshotretentie onafhankelijk kan blijven.

Vervang niet elke snapshot door een bookmark. Voor herstelgeschiedenis op de bestemming zijn nog steeds echte snapshots nodig en replicatietools verschillen in de manier waarop ze gemeenschappelijke bases beheren. Gebruik bookmarks alleen wanneer ze het beheer aan de bronzijde vereenvoudigen zonder de hersteldoelstelling van de bestemming te verzwakken.

Bescherm alleen de snapshots die replicatie nog nodig heeft

Identificeer de meest recente gemeenschappelijke snapshot die bron en bestemming delen voordat je gaat opschonen. Wanneer tools holds of gelijkwaardige beveiligingen gebruiken, controleer dan of opschoontaken deze respecteren en of verouderde holds uiteindelijk worden vrijgegeven.

Het FreeBSD ZFS-handboek legt uit dat holds gedeelde snapshots beschermen totdat de hold expliciet wordt vrijgegeven.

Bewaar niet elke historische snapshot alleen omdat één gemeenschappelijke basis nodig is. Bescherm de kleine set die replicatie daadwerkelijk nodig heeft en laat het retentiebeleid van de bestemming vervolgens de oudere, onafhankelijke herstelpunten beheren.

Controleer replicatiesnapshots afzonderlijk van back-upgeschiedenis

Sommige tools maken naast je geplande snapshots per uur of per dag ook eigen synchronisatiesnapshots. Geef beide soorten op de bestemming weer en zorg ervoor dat de door de tool gegenereerde set niet zonder opschoningsregel kan blijven groeien.

Een bespreking van Sanoid en Syncoid legt uit dat synchronisatiesnapshots als vangnet fungeren, in plaats van dat elke replicatiesnapshot bedoeld is als langdurige back-upgeschiedenis.

Controleer de bestemming maandelijks of na elke grote verplaatsing van een dataset. Het beleid is gezond wanneer de verwachte herstelpunten behouden blijven, de volgende incrementele overdracht een geldige gemeenschappelijke basis heeft en de vrije ruimte in de pool boven de vastgestelde ondergrens blijft. Het gerelateerde ZimaSpace-artikel over diagnose van snapshotruimte is de herstelroute wanneer de bestemming al onverwacht vol is.

Veelgestelde vragen

Moet de bestemming precies dezelfde snapshots bewaren als de bron?

Niet noodzakelijk. Een back-updoel kan een langere geschiedenis bewaren, maar het verschil moet bewust zijn gekozen, op capaciteit zijn getest en door een eigen retentiebeleid worden beheerd.

Kan het verwijderen van bestanden op de bron de ruimte op de bestemming onmiddellijk vrijmaken?

Nee. Gerepliceerde snapshots kunnen naar oudere blokken blijven verwijzen nadat het livebestand is verdwenen. Ruimte komt pas vrij wanneer geen enkele bewaarde snapshot of andere verwijzing die blokken nog nodig heeft.

Maakt het verwijderen van de oudste snapshot altijd de meeste ruimte vrij?

Nee. Snapshotruimte wordt gedeeld tussen herstelpunten. Schat of meet de unieke ruimte waarnaar wordt verwezen en bescherm elke gemeenschappelijke snapshot die nog nodig is voor incrementele replicatie.