Come pianificare i processi Restic di backup, Forget e Prune senza conflitti di blocco

Pianifica frequentemente i backup, esegui forget tramite un unico controller del repository e avvia prune meno spesso all’interno di una finestra di manutenzione esclusiva. Non permettere che ogni host gestisca tutti e tre i processi.

Un repository condiviso per home server richiede due tipi di pianificazione: punti di ripristino per host e manutenzione dell’intero repository. Costruisci la pianificazione sulla base delle durate misurate e degli obiettivi di ripristino, non su esempi fissi trovati online. Centralizza la retention e prune, raggruppa correttamente gli snapshot, ordina esplicitamente le unità e assegna a ogni processo saltato un nuovo tentativo e un avviso. La pianificazione è completa solo dopo che due cicli e un ripristino di prova hanno dimostrato che retention e locking si comportano come previsto.

Inventaria ogni processo, responsabile e durata normale massima

Crea una tabella per ogni operazione che accede al repository: backup, forget, prune, check, unlock, elenco degli snapshot e test di ripristino. Registra l’host che avvia l’operazione, il comando o wrapper, la credenziale, la durata normale e la durata massima recente, il timeout, la regola per i nuovi tentativi e la destinazione degli avvisi. Includi anche i processi nascosti nelle applicazioni di backup o nelle interfacce NAS.

Un repository condiviso richiede una manutenzione a livello di repository, non una copia per ogni client. Una configurazione Restic pratica per più host assegna forget, prune e check una sola volta per repository, raggruppando la retention per gli host e i percorsi pertinenti.

Consolida i processi di manutenzione duplicati sotto un unico controller. Mantieni la gestione dei backup per host quando facilita l’accesso alle origini, ma fai in modo che ogni host comunichi al controller lo stato di avvio e completamento. Se un processo non ha una durata misurata o un responsabile, osservalo prima di costruirgli attorno una finestra di manutenzione.

Imposta prima la frequenza dei backup, poi definisci l’ambito di forget

Scegli la frequenza dei backup di ogni host in base alla quantità di modifiche che puoi permetterti di perdere e al tempo normalmente necessario per completare un backup. Distribuisci nel tempo le scansioni delle origini più grandi se competono per la rete o lo spazio di archiviazione, ma non spostare i processi solo per rendere ordinato un grafico. Usa il backup normale più lungo per definire l’inizio più vicino possibile della manutenzione.

Esegui forget dal controller del repository e visualizza in anteprima la selezione usando il raggruppamento previsto per host, percorso e tag. Un raggruppamento imprevisto per calendario può fare sì che la retention rimuova più punti di ripristino di quanto lasci intendere una semplice lettura del numero da conservare.

Mantieni logicamente separati forget e prune fisico durante la progettazione della pianificazione. La policy di retention visualizzata in anteprima può essere eseguita dopo un backup completato correttamente o in una fase separata del controller, mentre prune deve avere una finestra esclusiva più lunga. Non associare prune al backup di ogni host solo perché un singolo comando consente di combinarli.

Inserisci prune e check in finestre valide per l’intero repository

Esegui prune meno frequentemente del backup e, di norma, anche meno frequentemente di forget, perché la pulizia fisica del repository può richiedere molto più tempo e bloccare le altre attività. Pianificalo dopo il completamento di tutti i backup previsti e della selezione della retention. Assegna a check una fase o una finestra propria, in base alle dimensioni del repository e alla velocità del backend.

Una configurazione Restic con systemd può mantenere backup e pruning in servizi separati, così lo scheduler osserva i relativi stati di uscita invece di avviare un unico comando opaco.

Se prune supera regolarmente la finestra, non permettere che i backup si accumulino silenziosamente. Riduci la frequenza di prune, amplia la finestra, analizza il throughput del backend oppure dividi i repository quando le loro esigenze operative non sono più compatibili. L’ingresso richiede che non ci siano backup attivi; l’uscita richiede uno stato di manutenzione pulito e il rilascio del lock del repository.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Codifica dipendenze, nuovi tentativi e avvisi

Codifica l’ordine previsto invece di affidarti agli intervalli dell’orologio: le unità di backup comunicano il completamento, forget viene eseguito solo dopo i backup richiesti, prune viene eseguito solo dopo l’ingresso del repository nella finestra esclusiva e check segue la policy di manutenzione scelta. Usa un gate esterno condiviso che tutte le unità interessate rispettino.

I target di systemd possono esprimere che le dipendenze tra backup e manutenzione devono essere completate in ordine, invece di limitarsi ad avviarsi in momenti diversi.

Imposta nuovi tentativi con limiti precisi per la contesa sul lock e i problemi di rete, quindi invia un avviso quando la scadenza viene superata. Un backup in ritardo deve rimandare prune; un prune prolungato oltre la finestra deve rimandare il backup successivo e avvisare l’operatore. L’unlock forzato e le opzioni no-lock non sono policy per i nuovi tentativi.

Verifica due cicli completi e un ripristino

Osserva due cicli completi invece di dichiarare il successo dopo il semplice caricamento dei file timer. Verifica che ogni origine produca lo snapshot previsto, che forget conservi i gruppi desiderati, che prune venga eseguito solo nella propria finestra, che i lock vengano rimossi dopo le uscite corrette e che gli avvisi registrino ogni ritardo.

Ripristina i file da uno snapshot sopravvissuto alla sequenza di retention e prune, non solo dall’ultimo backup. Questo dimostra che la pianificazione completa conserva un punto di ripristino utilizzabile, invece di limitarsi a produrre stati verdi dei processi.

La pianificazione supera la verifica quando due cicli vengono completati nell’ordine previsto, nessun processo scompare silenziosamente, gli snapshot conservati corrispondono all’anteprima e il ripristino di prova è corretto. Annulla l’automazione della manutenzione mantenendo i backup normali se la retention rimuove il gruppo sbagliato, prune non riesce a completarsi in modo affidabile o i conflitti sui lock si ripresentano. Modifica la frequenza sulla base dei risultati misurati, non disabilitando la protezione del repository.