Come evitare che la replica degli snapshot riempia il pool di destinazione

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Prevent Snapshot Replication From Filling the Destination Pool

La replica degli snapshot riempie il pool di destinazione quando gli snapshot conservati e i blocchi modificati si accumulano più rapidamente di quanto la policy di pulizia della destinazione riesca a rilasciarli.

La soluzione preventiva consiste nel progettare conservazione sulla sorgente, conservazione sulla destinazione, frequenza della replica e avvisi sullo spazio libero come un’unica policy. Una replica può legittimamente conservare più cronologia della sorgente, ma questa scelta deve essere delimitata. Tieni traccia degli snapshot necessari come basi incrementali, della quantità di dati univoci che i vecchi snapshot mantengono vincolati, dell’eventualità che i bookmark possano sostituire alcuni snapshot locali della sorgente e dello spazio residuo prima dell’arrivo del prossimo grande insieme di modifiche.

Imposta esplicitamente una policy di conservazione sulla destinazione

Decidi quanti punti di ripristino orari, giornalieri, settimanali e mensili debba conservare la destinazione e documenta perché tale cronologia differisce da quella della sorgente. Non presumere che il software di replica elimini automaticamente ogni vecchio snapshot sulla destinazione quando la sorgente lo elimina.

Una panoramica sulla replica ZFS spiega che la replica richiede una policy per gli snapshot, perché gli snapshot sono sia punti di ripristino sia limiti per i trasferimenti incrementali.

Applica la conservazione più breve ai dataset soggetti a frequenti modifiche, a meno che una cronologia più lunga non abbia un concreto valore per il ripristino. Mantieni gli archivi soggetti a poche modifiche secondo una pianificazione diversa, così una policy globale non spreca spazio dove punti di ripristino frequenti aggiungono poco valore.

Stima la quantità di modifiche vincolate dai vecchi snapshot

Misura lo spazio USED degli snapshot, i dati scritti tra uno snapshot e l’altro e lo spazio libero del pool di destinazione prima e dopo grandi eliminazioni, spostamenti, sostituzioni di file multimediali o riscritture di macchine virtuali. Uno snapshot può mantenere in vita vecchi blocchi anche dopo che i dati attivi sono scomparsi.

Una nota sulla replica TrueNAS avverte che il ricambio degli snapshot conserva i vecchi blocchi anche quando il dataset attivo corrente diventa più piccolo.

Usa questo tasso di cambiamento per dimensionare la conservazione. Una destinazione con 30 giorni di immagini di macchine virtuali soggette a frequenti modifiche può richiedere molta più capacità rispetto a un altro dataset delle stesse dimensioni attive ma costituito soprattutto da foto di famiglia a cui vengono aggiunti nuovi dati.

Riserva spazio libero nel pool per la prossima replica

Imposta una soglia operativa di spazio libero che tenga conto dell’incrementale in arrivo più grande realistico, della crescita degli snapshot locali e del normale overhead del file system. Invia avvisi prima di raggiungere la soglia, non quando il pool è già quasi pieno.

La discussione di Oracle sulla conservazione degli snapshot osserva che la conservazione controlla la crescita degli snapshot, invece di trattarli come privi di costi perché la loro creazione iniziale è economica.

Sospendi o riduci la conservazione non critica prima che la destinazione raggiunga una situazione di emergenza. Una destinazione di replica ha bisogno di spazio per ricevere e registrare i nuovi blocchi, quindi lasciare spazio sufficiente solo per il dataset attivo di oggi non è un piano di capacità sicuro.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Usa i bookmark quando preservano la cronologia incrementale

Quando la tua versione di ZFS e gli strumenti di replica supportano i bookmark, valuta se un bookmark possa preservare il riferimento per l’invio incrementale dopo che un vecchio snapshot della sorgente non è più necessario come punto di ripristino locale completo.

Un progetto di backup remoto mostra come i bookmark preservino le basi incrementali, consentendo di mantenere indipendente la conservazione degli snapshot.

Non sostituire ogni snapshot con un bookmark. La cronologia di ripristino sulla destinazione richiede comunque snapshot effettivi e gli strumenti di replica differiscono nella gestione delle basi comuni. Usa i bookmark solo quando semplificano il lato della sorgente senza indebolire l’obiettivo di ripristino della destinazione.

Proteggi solo gli snapshot ancora necessari alla replica

Individua lo snapshot comune più recente condiviso da sorgente e destinazione prima di eseguire la potatura. Quando gli strumenti utilizzano blocchi o protezioni equivalenti, verifica che i processi di pulizia li rispettino e che i blocchi obsoleti vengano infine rimossi.

Il manuale di FreeBSD su ZFS spiega che i blocchi proteggono gli snapshot condivisi finché il blocco non viene rimosso esplicitamente.

Non conservare ogni snapshot storico semplicemente perché è necessaria una base comune. Proteggi il piccolo insieme realmente richiesto dalla replica, quindi lascia che la policy di conservazione della destinazione gestisca i punti di ripristino indipendenti più vecchi.

Controlla gli snapshot di replica separatamente dalla cronologia dei backup

Alcuni strumenti creano propri snapshot di sincronizzazione oltre agli snapshot orari o giornalieri pianificati. Elenca entrambe le categorie sulla destinazione e assicurati che l’insieme generato dallo strumento non possa crescere senza una regola di pulizia.

Una discussione su Sanoid e Syncoid spiega che gli snapshot di sincronizzazione fungono da protezioni, invece di essere destinati tutti a diventare una cronologia di backup a lungo termine.

Esamina la destinazione ogni mese o dopo qualsiasi grande spostamento di dataset. La policy è sana quando i punti di ripristino previsti rimangono disponibili, il prossimo incrementale dispone di una base comune valida e lo spazio libero del pool resta sopra la soglia definita. L’articolo correlato di ZimaSpace sulla diagnosi dello spazio occupato dagli snapshot è il percorso di ripristino quando la destinazione è già inaspettatamente piena.

Domande frequenti

La destinazione dovrebbe conservare esattamente gli stessi snapshot della sorgente?

Non necessariamente. Una destinazione di backup può conservare una cronologia più lunga, ma la differenza deve essere intenzionale, verificata in base alla capacità e regolata da una propria policy di conservazione.

L’eliminazione dei file sulla sorgente libera immediatamente spazio sulla destinazione?

No. Gli snapshot replicati possono continuare a referenziare i blocchi più vecchi anche dopo la scomparsa del file attivo. Lo spazio viene rilasciato solo quando nessuno snapshot conservato o altro riferimento necessita più di quei blocchi.

L’eliminazione dello snapshot più vecchio libera sempre la maggior quantità di spazio?

No. Lo spazio degli snapshot è condiviso tra i punti di ripristino. Stima o misura lo spazio referenziato univoco e proteggi qualsiasi snapshot comune ancora necessario per la replica incrementale.