Saluto i lettori del nostro blog! In parte ci conosciamo già: i miei post in inglese sono apparsi qui nella traduzione della mia cara collega . Questa volta ho deciso di rivolgermi direttamente al pubblico di lingua russa.
Per il mio debutto volevo trovare un argomento interessante per un pubblico quanto più ampio possibile e che richiedesse una trattazione dettagliata. Daniel Defoe affermava che a tutti stanno aspettando la morte e le tasse. Da parte mia, posso dire che tutti gli ingegneri di supporto si trovano di fronte a domande sulle politiche di conservazione dei punti di ripristino (o, se volete, sul retention). Come funziona il retention, ho iniziato a spiegarlo 4 anni fa, essendo un ingegnere junior di primo livello, e continuo a spiegalo adesso, essendo ormai team leader del team di lingua spagnola e italiana. Sono certo che anche i miei colleghi di secondo e persino terzo livello di supporto rispondano regolarmente alle stesse domande.
In questo contesto, ho voluto scrivere un post finale, il più dettagliato possibile, a cui gli utenti di lingua russa possano tornare ripetutamente come a un manuale. Il momento è opportuno: la recente uscita della decima versione anniversaria ha aggiunto nuove funzionalità al già consolidato set di strumenti, che non sono cambiati per anni. Il mio post è principalmente orientato a questa versione — sebbene gran parte di quanto scritto sia valido anche per le versioni precedenti, alcuni aspetti funzionali semplicemente non saranno trovati. Infine, guardando un po' al futuro, posso dire che ci sono attese alcune modifiche nella prossima versione, ma ne parleremo quando sarà il momento. Quindi, iniziamo.
Compito di backup (Backup job)
Iniziamo esaminando quella parte che non ha subito cambiamenti nella versione 10. La politica di retention è definita da diversi parametri. Apriamo la finestra per creare un nuovo compito e andiamo alla scheda Storage. Qui vedremo un parametro che definisce il numero desiderato di punti di ripristino:
Tuttavia, questo è solo una parte dell'equazione. Il numero effettivo di punti è determinato anche dalla modalità di backup impostata per il task. Per scegliere questo parametro, è necessario fare clic sul pulsante Advanced nella stessa scheda. Questo aprirà una nuova finestra con molte opzioni. Numeriamole e consideriamole uno per uno:
Se è attivata solo l'opzione 1, il task funzionerà in modalità «incremente infinito» (forever forward incremental). Qui non ci sono difficoltà: il task conserverà un numero stabilito di punti di ripristino dal backup completo (file con estensione VBK) all'ultimo incremento (file con estensione VIB). Quando il numero di punti supera il valore impostato, l'incremento più vecchio verrà unito con il backup completo. In altre parole, se il task è impostato per conservare 3 punti, subito dopo una nuova sessione ci saranno 4 punti sul repository, dopodiché il backup completo sarà unito con il più vecchio incremento e il numero totale di punti tornerà a 3.
Il retention è estremamente semplice per la modalità "reverse incremental" (opzione 2). In questo caso, il punto più recente sarà un backup completo, che sarà seguito da una catena di cosiddetti rollback (file con estensione VRB); quindi, per applicare il retention, basta semplicemente eliminare il rollback più vecchio. La situazione sarà la stessa: subito dopo la sessione, il numero dei punti supererà di 1 quello impostato, per poi tornare al valore desiderato.
Si noti che con la modalità reverse incremental è anche possibile attivare un backup completo periodico (opzione 4), ma questo non cambierà il concetto. Sì, ci saranno punti di ripristino completi nella catena, ma continueremo semplicemente a eliminare i punti più vecchi uno alla volta.
Finalmente, siamo arrivati a una parte interessante. Se attivi il backup incrementale e, in aggiunta, abiliti le opzioni 3 o 4 (o anche entrambe contemporaneamente), il compito inizierà a creare backup completi periodici con il metodo "attivo" o sintetico. Il metodo per creare il backup completo non è importante: conterrà gli stessi dati e la catena incrementale sarà divisa in "sotto-catene". Questo metodo è chiamato forward incremental e suscita molte domande tra i nostri clienti.
La retention qui si applica eliminando la parte più vecchia della catena (dal backup completo all'incremento). In questo caso, non elimineremo solo il backup vuoto o solo una parte degli incrementi. L'intera "sotto-catena" viene rimossa completamente in una sola volta. Cambia anche il significato dell'impostazione del numero di punti: mentre in altri metodi si tratta del numero massimo consentito, dopo il quale è necessario applicare la retention, qui questa impostazione determina il numero minimo. In altre parole, dopo l'eliminazione della "sotto-catena" più vecchia, il numero di punti nella parte restante non deve scendere al di sotto di questo minimo.
Cercherò di rappresentare graficamente questo concetto. Supponiamo che il retention sia impostato su 3 punti, l'attività si esegue ogni giorno con un backup completo il lunedì. In questo caso, il retention sarà applicato quando il numero totale di punti raggiunge 10:
Perché 10, se è stato impostato a 3? Lunedì è stato creato un backup completo. Da martedì a domenica, l'attività ha creato incrementi. Infine, il lunedì successivo viene nuovamente creato un backup completo e solo quando sono stati creati 2 incrementi, l'intera parte vecchia della catena può finalmente essere eliminata, poiché il numero rimanente di punti non scenderà sotto i 3 impostati.
Se l'idea è chiara, ti propongo di provare a calcolare il retention da solo. Prendiamo queste condizioni: l'attività viene eseguita per la prima volta giovedì (ovviamente verrà effettuato un backup completo). L'attività è impostata per creare un backup completo il mercoledì e la domenica e per mantenere 8 punti di ripristino. Quando verrà applicato il retention per la prima volta?
Per rispondere a questa domanda, ti consiglio di prendere un foglio di carta, tracciarlo per giorni della settimana e scrivere quale punto viene creato ogni giorno. La risposta diventerà evidente.
Risposta
Spiegazione: per rispondere, basta chiedersi "quando sarà applicato il retention"? La risposta è: quando possiamo rimuovere i primi 3 punti (VBK, VIB, VIB) e la restante sequenza non scende sotto gli 8 punti previsti. Diventa chiaro che possiamo farlo quando abbiamo un totale di 11 punti, ovvero nella domenica della seconda settimana.
Alcuni lettori potrebbero obiettare: "perché tutto questo, se c'è ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Infine, non abbiamo considerato l'opzione "Trasforma le catene di backup precedenti in rollback" (contrassegnata dal numero 5). Questa opzione a volte confonde i clienti che la attivano automaticamente, volendo semplicemente includere un backup sintetico. Tuttavia, questa opzione attiva un modo di backup completamente diverso. Senza entrare nei dettagli, posso già dire che, in questa fase di sviluppo del prodotto, "Trasforma le catene di backup precedenti in rollback" è un'opzione obsoleta, e non riesco a pensare a nessuno scenario in cui dovrebbe essere utilizzata. Il suo valore è così dubbio che per un certo periodo Anton Gostev stesso ha lanciato un appello attraverso il forum, chiedendo di inviargli esempi di utilizzo utile (se li avete, scrivete nei commenti, mi interessa molto). Se non se ne troveranno (penso di sì), l'opzione sarà rimossa nelle prossime versioni.
Il task creerà incrementi (VIB) fino al giorno in cui è previsto il backup completo sintetico. In quel giorno viene effettivamente creato un VBK, ma tutti i punti precedenti a questo VBK vengono trasformati in rollbacks (VRB). Dopo ciò, il task continuerà a creare incrementi al backup completo fino al prossimo backup sintetico. Alla fine, nella catena si creerà un mix di file VBK, VBR e VIB. La retention viene applicata molto semplicemente: eliminando l'ultimo VBR.
Problemi
Oltre a comprendere come funziona, la maggior parte dei problemi che si presentano durante l'utilizzo della modalità incrementale è generalmente legata al backup completo. Un backup completo regolare è necessario per questa modalità, altrimenti il repository accumulerà punti finché non sarà pieno.
Ad esempio, un backup completo potrebbe essere creato con scarsa frequenza. Diciamo che il compito è impostato per conservare 10 punti, ma un backup completo viene eseguito una volta al mese. È chiaro che il numero effettivo di punti sarà significativamente superiore a quello programmato. Oppure il compito è stato impostato per funzionare in modo incrementale illimitato e conservare 50 punti. Poi qualcuno ha accidentalmente creato un backup completo. D'ora in poi, il compito dovrà attendere che il punto completo accumuli 49 incrementi, dopodiché applicherà la retention e tornerà in modalità completamente illimitata.
In altri casi, il backup completo è impostato per essere creato regolarmente, ma per qualche motivo non avviene. Qui descriverò il motivo più comune. Alcuni clienti preferiscono utilizzare l'opzione di programmazione "run after" e impostare le attività per lavorare in cascata. Prendiamo, ad esempio, 3 attività che vengono eseguite ogni giorno e creano un backup completo la domenica. La prima attività inizia alle 22:30, le altre vengono avviate in sequenza. Il backup incrementale richiede 10 minuti, quindi entro le 23:00 tutte le attività vengono completate. Tuttavia, il backup completo richiede un'ora, quindi la domenica accade quanto segue: la prima attività lavora dalle 22:30 alle 23:30. La successiva dalle 23:30 alle 00:30. E la terza attività si avvia già di lunedì. Il backup completo è programmato per la domenica, quindi in questo caso non ci sarà. L'attività dovrà aspettare il backup completo per applicare la retention. Perciò, fate attenzione quando utilizzate l'opzione "run after" oppure non utilizzatela affatto: impostate le attività per iniziare contemporaneamente e lasciate che il pianificatore delle risorse faccia il suo lavoro.
L'opzione complessa "Remove deleted items"
Navigando nelle impostazioni del compito Storage – Advanced – Maintenance, è possibile imbattersi nell'opzione “remove deleted items data after”, misurata in giorni.
Alcuni clienti si aspettano che questa sia la retention. In realtà, è un'opzione completamente separata, il cui malinteso può portare a conseguenze inaspettate. Tuttavia, prima di tutto, è necessario spiegare come B&R reagisce alle situazioni in cui durante la sessione solo alcune macchine vengono correttamente sottoposte a backup.
Immaginiamo questo scenario: un compito di backup incrementale infinito, impostato per mantenere 6 punti. Ci sono 2 macchine nel compito, una sempre sottoposta a backup con successo, l'altra che a volte ha mostrato errori. Alla settima istanza, si è presentata la seguente situazione:
È il momento di applicare la retention, ma una macchina ha 7 punti, mentre l'altra solo 4. Viene applicata la retention in questo caso? La risposta è sì, verrà applicata. Se anche solo un oggetto è stato sottoposto a backup, B&R considera che il punto è stato creato.
Una situazione simile può verificarsi se una macchina non è stata semplicemente inclusa nel compito durante una sessione specifica. Questo può accadere, ad esempio, quando le macchine vengono aggiunte al compito non in modo individuale, ma come parte di contenitori (cartelle, archivi) e una macchina migra temporaneamente in un altro contenitore. In tal caso, il compito sarà considerato completato, ma nelle statistiche troverete un messaggio che invita a prestare attenzione al fatto che una determinata macchina non viene più elaborata dal compito.
Cosa succede se non si presta attenzione a questo? Nel caso di modalità di backup infinitamente incrementale o retroattivo, il numero di punti di ripristino della ‘macchina problematica’ diminuirà ad ogni sessione, finché non raggiungerà 1, salvato nel VBK. In altre parole, anche se la macchina non viene sottoposta a backup per un lungo periodo, rimarrà comunque un punto di ripristino. La situazione cambia se sono attivati i backup completi periodici. Se si ignorano i segnali da B&R, alla fine l'ultimo punto potrebbe essere rimosso insieme alla parte più vecchia della catena.
Chiarito questi dettagli, è finalmente possibile considerare l'opzione "Rimuovi i dati degli elementi eliminati dopo". Questa opzione rimuoverà tutti i punti per una determinata macchina, se tale macchina non viene sottoposta a backup per X giorni. Va notato che questa impostazione non tiene conto degli errori (provato - non riuscito). Non deve nemmeno esserci un tentativo di backup della macchina. Sembrerebbe che l'opzione sia utile e dovrebbe sempre rimanere attivata. Se l'amministratore ha rimosso la macchina dal compito, è logico liberarsi di dati e collegamenti non necessari dopo un certo periodo. Tuttavia, questa impostazione richiede disciplina e attenzione.
Ecco un esempio pratico: nel job sono stati aggiunti diversi contenitori con una composizione piuttosto dinamica. A causa della mancanza di RAM, il server B&R ha riscontrato problemi rimasti inosservati. Il job è partito e ha tentato di effettuare il backup delle macchine, ad eccezione di una che al momento non era presente nel contenitore. Poiché molte macchine hanno restituito errori, per impostazione predefinita B&R deve fare 3 tentativi aggiuntivi di backup delle macchine problematiche. A causa dei continui problemi con la RAM, questi tentativi si sono protratti per diversi giorni. Non c'è stata una nuova possibilità di eseguire il backup della VM assente (l'assenza della VM non è un errore). Di conseguenza, durante uno dei tentativi di ripetizione, è stata soddisfatta la condizione “Rimuovi elementi eliminati” e tutti i punti di ripristino della macchina sono stati eliminati.
A riguardo posso dire quanto segue: se hai impostato avvisi sui risultati dei job, e ancor meglio se utilizzi l'integrazione con Veeam ONE, è probabile che ciò non accada. Se invece controlli il server B&R una volta alla settimana per verificare che tutto funzioni, è meglio rinunciare alle opzioni che potrebbero potenzialmente portare all'eliminazione dei backup.
Cosa è stato aggiunto nella v.10
Ciò di cui abbiamo parlato in precedenza è esistito in B&R per molte versioni. Comprendendo questi principi operativi, vediamo ora cosa è stato aggiunto nella decima edizione del nostro anniversario.
Ritenzione giornaliera
In precedenza abbiamo esaminato la politica di archiviazione 'classica', basata sul numero di punti. Un approccio alternativo è quello di impostare nel medesimo menu 'giorni' invece di 'punti di ripristino'.
L’idea è chiara dal nome: la ritenzione conserverà un numero definito di giorni, mentre il numero di punti per ogni giorno non ha importanza. Tuttavia, è importante ricordare quanto segue:
- Il giorno corrente non viene considerato nel calcolo della ritenzione
- I giorni in cui il lavoro non è stato eseguito affatto vengono comunque conteggiati. È importante tenerlo a mente per non perdere accidentalmente i punti di lavori che funzionano irregolarmente.
- Il punto di ripristino è calcolato dal giorno in cui ha avuto inizio la sua creazione (cioè, se il lavoro è iniziato di lunedì e si è concluso di martedì, allora questo punto è considerato di lunedì)
In altri aspetti, i principi dell'applicazione della retention per i task sono ancora determinati dal metodo di backup scelto. Proviamo un altro esercizio di calcolo, utilizzando sempre il metodo incrementale. Supponiamo che la retention sia impostata su 8 giorni, con il task che opera ogni 6 ore e un backup completo il mercoledì. Inoltre, il task non funziona di domenica. Il primo avvio del task sarà lunedì. Quando verrà applicata la retention?
Risposta
Come al solito, è meglio disegnare una tabella. Mi permetto di semplificare la questione e non disegnerò tutti i punti creati ogni giorno, poiché il numero di punti giornalieri qui non è rilevante. Ciò che conta è che il primo lunedì e i mercoledì il primo punto sarà un backup completo, mentre negli altri giorni il task creerà solo 4 punti incrementali.
Chiarificando, la retention sarà applicata rimuovendo il backup completo del lunedì e il suo incremento. Quando accadrà? Quando la parte rimanente della catena conterrà 8 giorni. Non consideriamo il giorno corrente, mentre consideriamo la domenica. Pertanto, la risposta è: giovedì della seconda settimana.
Archiviazione con metodo GFS per attività standard
Fino alla versione 10, il metodo di archiviazione Grandfather-Father-Son (GFS) era disponibile solo per le attività di creazione di backup (Backup copy) e per le attività di copia su nastro magnetico. Ora è disponibile anche per il backup standard.
Sebbene non riguardi direttamente l'argomento attuale, devo dire che la nuova funzionalità non segna un allontanamento dalla strategia 3-2-1. La presenza di punti di archivio nel repository principale non influisce sulla sua affidabilità. Si presume che il GFS venga utilizzato insieme a un repository espandibile (Scale-out), per il trasferimento di questi punti in S3 e simili soluzioni di archiviazione. Se non lo utilizzate, è meglio continuare a conservare i punti primari e di archivio in repository separati.
Ora guardiamo i principi per la creazione dei punti GFS. Nelle impostazioni dell'attività, nel passaggio Storage, è comparsa una speciale pulsante che apre il seguente menu:
La sostanza del GFS può essere riassunta in alcuni punti (si noti che il GFS funziona in modo diverso in altre tipologie di attività, ma ne parleremo tra poco):
- Il compito non crea un backup completo separato per il punto GFS. Invece, verrà utilizzato il backup completo più adatto disponibile. Pertanto, il compito deve funzionare in modalità incrementale, con backup completi periodici, oppure un backup completo deve essere creato manualmente dall'utente.
- Se è attivato solo un periodo (ad esempio, settimanale), all'inizio del periodo GFS il compito aspetterà semplicemente un backup completo e lo segnerà come il primo appropriato per GFS.
Esempio: il compito è impostato per mantenere un GFS settimanale, utilizzando un backup il mercoledì. Il compito viene eseguito ogni giorno, ma il backup completo è programmato per il venerdì. In questo caso, mercoledì inizia il periodo GFS e il compito inizierà ad aspettare un punto adeguato. Esso apparirà il venerdì e verrà contrassegnato con il flag GFS.
- Se sono attivati più periodi contemporaneamente (ad esempio, settimanale e mensile), B&R utilizzerà un metodo che consente di utilizzare lo stesso punto come GFS per più intervalli (per risparmiare spazio). I flag saranno assegnati a turno, iniziando dal più giovane.
Esempio: il GFS settimanale è impostato per mercoledì, mentre quello mensile per l'ultima settimana del mese. Il compito viene eseguito ogni giorno e crea backup completi il lunedì e il venerdì.
Per semplicità, iniziamo il conteggio dalla penultima settimana del mese. In questa settimana verrà creato un backup completo il lunedì, ma verrà ignorato perché l'intervallo GFS settimanale inizia il mercoledì. Invece, il backup completo del venerdì è completamente adatto per il punto GFS. Questo sistema ci è già familiare.
Ora vediamo cosa accadrà nell'ultima settimana del mese. L'intervallo GFS mensile inizierà il lunedì, ma il VBK del lunedì non sarà contrassegnato come GFS, perché il compito cerca di contrassegnare un VBK sia come punto GFS mensile che settimanale. La ricerca inizia infatti dal settimanale, poiché per definizione può anche diventare mensile.
Se si attivano solo gli intervalli settimanale e annuale, questi opereranno in modo indipendente l'uno dall'altro e possono contrassegnare 2 VBK separati come corrispondenti agli intervalli GFS.
Compiti di creazione di copie di backup (Backup copy)
Un altro tipo di incarico, che spesso richiede chiarimenti sul funzionamento. Iniziamo analizzando il metodo "classico" di lavoro, senza le innovazioni v.10.
Metodo di retention semplice.
Per impostazione predefinita, questi incarichi funzionano in modo infinito e incrementale. La creazione dei punti è determinata da due parametri: l'intervallo di copia e la quantità desiderata di punti di ripristino (qui non c'è retention per giorni). L'intervallo di copia viene impostato nella prima scheda Job durante la creazione dell'incarico:
La quantità di punti è definita poco dopo nella scheda Target.
L'incarico crea 1 nuovo punto per ogni intervallo (il numero di punti creati per la VM dagli incarichi originali non ha importanza). Alla fine dell'intervallo, il nuovo punto viene finalizzato e, se necessario, viene applicata la retention unendo VBK e il più antico incremento. Questo meccanismo ci è già familiare.
Metodo di retention utilizzando GFS.
BCJ può anche memorizzare punti archivistici. Questo si configura nella stessa scheda Target, leggermente più in basso rispetto alle impostazioni del numero di punti di ripristino:
Le GFS possono essere creati in due modi: sinteticamente, utilizzando i dati di un repository secondario, oppure simulando un backup completo e leggendo tutti i dati dal repository primario (attivato dall'opzione contrassegnata con il numero 3). Il retention in entrambi i casi sarà molto diverso, quindi esaminiamo i due casi separatamente.
GFS sintetico
In questo caso, il punto GFS non viene creato esattamente nel giorno stabilito. Invece, il punto GFS verrà generato quando il VIB del giorno fissato per la creazione del punto GFS sarà unito al backup completo. Questo può a volte generare fraintendimenti, poiché il tempo passa e il punto GFS non appare. Solo un potente sciamano del supporto tecnico può prevedere in quale giorno il punto apparirà. In realtà, non serve magia: basta osservare il numero di punti disponibili e l'intervallo di sincronizzazione (quanti punti vengono creati ogni giorno). Prova a calcolare tu stesso con questo esempio: l'assegnazione prevede di mantenere 7 punti, l'intervallo di sincronizzazione è di 12 ore (cioè 2 punti al giorno). Al momento, ci sono già 7 punti nella catena, oggi è lunedì e la creazione del punto GFS è programmata per oggi. In quale giorno verrà creato?
Risposta
È meglio descrivere come la catena cambierà dinamicamente, giorno per giorno:
Quindi, lunedì l'ultimo incremento nella catena viene contrassegnato come GFS, ma non ci sono altri cambiamenti visibili. Ogni giorno il compito crea 2 nuovi punti e il retention avanza inesorabilmente nella catena. Infine, giovedì arriva il momento di applicare la retention allo stesso incremento. Questa sessione richiederà più tempo del solito, poiché il compito "estrarrà" i blocchi necessari dalla catena e creerà un nuovo punto completo. Da questo momento, ci saranno già 8 punti nella catena: 7 nella catena principale + GFS.
Creazione di punti GFS con l'opzione “Leggi l'intero punto”
Come ho detto in precedenza, BCJ opera in modalità incrementale infinita. Ora esamineremo l'unica eccezione a questa regola. Quando è attivata l'opzione "Leggi l'intero punto", il punto GFS verrà creato esattamente nel giorno programmato. Il compito stesso funzionerà in modalità incrementale con backup completi periodici, come discusso in precedenza. Anche la retention sarà applicata rimuovendo la parte più vecchia della catena. Tuttavia, in questo caso verranno rimossi solo gli incrementi, mentre il backup completo sarà mantenuto come punto GFS. Pertanto, nel calcolo della retention non si considerano i punti contrassegnati con i flag GFS.
Supponiamo che il compito sia impostato per mantenere 7 punti e creare un punto GFS settimanale il lunedì. In questo caso, ogni lunedì il compito creerà effettivamente un backup completo e lo contrassegnerà come GFS. La retention sarà applicata quando, dopo la rimozione degli incrementi più vecchi, il numero degli incrementi rimanenti non scenderà sotto 7. Ecco come appare nello schema:
Quindi, alla fine della seconda settimana nella catena ci sono un totale di 14 punti. Durante la seconda settimana, la task ha creato 7 punti. Se fosse stata un'operazione semplice, la retention sarebbe stata già applicata. Ma si tratta di BCJ con retention GFS, quindi non consideriamo i punti GFS e, quindi, ne restano solo 6. Ciò significa che non possiamo ancora applicare la retention. Nella terza settimana creiamo un altro backup completo con il flag GFS. 15 punti, ma anche questo non lo consideriamo. E, infine, martedì della terza settimana creiamo un incremento. Ora, se rimuoviamo gli incrementi della catena della prima settimana, il numero totale di incrementi soddisferà la retention stabilita.
Come già detto sopra, in questo metodo è molto importante che i backup completi vengano creati regolarmente. Diciamo, se impostiamo la retention principale a 7 giorni ma solo 1 punto annuale, è facile immaginare che gli incrementi accumuleranno molto, molto più di 7. In tali casi, è meglio utilizzare il metodo sintetico per la creazione di GFS.
E di nuovo "Rimuovi gli elementi eliminati"
Questa opzione è presente anche per BCJ:
La logica di questa opzione è la stessa di un normale job di backup: se la macchina non viene elaborata per un determinato numero di giorni, i suoi dati vengono rimossi dalla catena. Tuttavia, per la BCJ, l'utilità di questa opzione è oggettivamente maggiore, ecco perché.
In modalità normale, la BCJ opera in modalità infinitamente incrementale, quindi se a un certo punto una macchina viene rimossa dal job, il retention eliminerà gradualmente tutti i punti di ripristino fino a che non ne rimarrà uno solo – nel VBK. Ora immaginiamo che il job sia ancora impostato per creare punti GFS sintetici. Quando sarà il momento, il job dovrà creare un GFS per tutte le macchine nella catena. Se per qualche macchina non ci sono nuovi punti – beh, bisognerà usare quello che c'è. E così ogni volta. Alla fine si può arrivare a questa situazione:
Nota la sezione Files: abbiamo un VBK principale e 2 punti GFS settimanali. E ora guarda la sezione Restore points – in realtà in questi file c'è la stessa immagine della macchina. Ovviamente, non ha alcun senso avere punti GFS di questo tipo, occupano solo spazio.
Questa situazione può verificarsi solo con l'uso di GFS sintetico. Per evitarlo, utilizza l'opzione "Remove deleted items". Assicurati solo di impostarla su un numero adeguato di giorni. Il supporto tecnico ha visto casi in cui l'opzione è stata impostata su un numero di giorni inferiore all'intervallo di sincronizzazione, causando malfunzionamenti in BCJ, che ha iniziato a eliminare i punti senza crearli.
Tieni presente che questa opzione non tocca i punti GFS già creati. Se desideri pulire gli archivi, devi farlo manualmente: fai clic destro sulla macchina e seleziona "Delete from disk" (nella finestra che appare, assicurati di spuntare l'opzione "Remove GFS full backup"):
Novità v.10 – copia immediata (immediate copy)
Dopo aver compreso le funzionalità "classiche", passiamo al nuovo. C'è una sola novità, ma è molto importante. Si tratta di una nuova modalità di funzionamento.
Non esiste un concetto come "intervallo di sincronizzazione"; il compito monitorerà continuamente se ci sono nuovi punti e copierà tutti, qualunque sia il loro numero. Tuttavia, il compito rimane incrementale, il che significa che anche se il compito principale crea VBK o VRB, questi punti saranno copiati come VIB. In ogni altro aspetto, non ci sono sorprese in questa modalità: sia il retention standard che il GFS funzionano secondo le regole descritte sopra (a dire il vero, qui è disponibile solo il GFS sintetico).
I dischi girano. Caratteristiche dei repository con rotazione dei dischi (rotated drives)
La minaccia persistente di ransomware ha reso de facto standard di sicurezza avere una copia dei dati su un supporto a cui il virus non può accedere. Una delle soluzioni è l'uso di repository con rotazione dei dischi, dove i dischi sono utilizzati a turni: mentre un disco è collegato e disponibile per la scrittura, gli altri sono conservati in un luogo sicuro.
Per insegnare a B&R a lavorare con tali repository, è necessario nelle impostazioni del repository, nel passaggio Repository, fare clic sul pulsante Avanzate e selezionare l'opzione corrispondente:
Dopo di ciò, VBR si aspetterà che la catena esistente scompaia periodicamente dal repository, il che significa la rotazione del disco. A seconda del tipo di repository e del tipo di task, B&R si comporterà in modo diverso. Può essere rappresentato con la seguente tabella:
Analizziamo ciascuna opzione.
Task normale e repository Windows
Pertanto, abbiamo un task che salva le catene sul primo disco. Con la rotazione, la catena creata scompare effettivamente, e il task deve in qualche modo affrontare questa perdita. La consolazione si trova nella creazione di un backup completo. In questo modo, ogni rotazione significa un backup completo. Ma cosa succede ai punti sul disco disconnesso? Vengono memorizzati e considerati nel calcolo della retention. Così, il numero di punti impostato nel task è quello che deve essere mantenuto su tutti i dischi. Facciamo un esempio:
Il task funziona in modalità infinitamente incrementale ed è configurato per conservare 3 punti di ripristino. Ma abbiamo anche un secondo disco, e una volta alla settimana eseguiamo la rotazione (i dischi possono essere anche di più, questo non cambia la sostanza).
Nella prima settimana, il compito creerà punti sul primo disco e unirà quelli in eccesso. In questo modo, il numero totale di punti sarà tre:
Poi colleghiamo il secondo disco. All'avvio, B&R noterà che il disco è cambiato. La catena sul primo disco scomparirà dall'interfaccia, ma le informazioni relative rimarranno nel database. Ora il compito manterrà 3 punti sul secondo disco. La situazione complessiva sarà la seguente:
Infine, ricolleghiamo il primo disco. Prima di creare un nuovo punto, il compito verificherà la situazione con la retention. E la retention, ricordo, è impostata per mantenere 3 punti. Nel frattempo abbiamo 3 punti sul disco 2 (che è scollegato e conservato in un luogo sicuro, inaccessibile a B&R) e 3 punti sul disco 1 (questo è collegato). Quindi, possiamo tranquillamente eliminare 3 punti dal disco 1, poiché superano la retention. Successivamente, il compito crea nuovamente un backup completo, e la nostra catena inizia a apparire così:
Se la retention è impostata per conservare giorni anziché un numero di punti, la logica non cambia. Inoltre, la retention GFS non è affatto supportata quando si utilizzano repository con rotazione dei dischi.
Compito normale e repository Linux archiviazione di rete
Questa opzione è possibile, ma in generale è meno raccomandata a causa delle limitazioni imposte. La rotazione del disco e la scomparsa della catena risponderanno allo stesso modo: creando un backup completo. La limitazione è legata al meccanismo di retention ridotto.
Qui, durante la rotazione, l'intera catena sul disco disattivato viene semplicemente rimossa dal database B&R. Nota: viene rimossa dal database, i file stessi rimangono sul disco. Possono essere importati e utilizzati per il ripristino, ma è facile intuire che, prima o poi, tali catene dimenticate riempiranno tutto il repository.
La soluzione è aggiungere DWORD ForceDeleteBackupFiles come indicato su questa pagina: . Dopo di che, il compito inizierà semplicemente a eliminare tutto il contenuto della cartella di lavoro o della cartella del repository (a seconda del valore) ad ogni rotazione.
Tuttavia, questo non è un retention elegante, ma una pulizia dell'intero contenuto. Sfortunatamente, il supporto tecnico ha riscontrato casi in cui come repository è stata scelta semplicemente la cartella radice del disco, dove oltre ai backup erano presenti anche altri dati. Tutto questo è stato distrutto durante la rotazione.
Inoltre, con l'attivazione di ForceDeleteBackupFiles, funziona per tutti i tipi di repository, quindi anche i repository su Windows smetteranno di applicare il retention e inizieranno a eliminare il contenuto. In altre parole, il disco locale su Windows è la scelta migliore per un sistema di archiviazione di backup di questo tipo.
Copie di backup e repository Windows
Con BCJ le cose diventano ancora più interessanti. Non solo c'è un sistema di retention completo, ma non è necessario eseguire un backup completo ad ogni cambio di disco! Funziona in questo modo:
Innanzitutto, B&R inizia a creare punti sul primo disco. Supponiamo che abbiamo impostato una retention su 3 punti. L'attività funzionerà in modalità infinitamente incrementale e unirà tutto ciò che è superfluo (ricordo che la retention GFS in questo caso non è supportata).
Dopo, colleghiamo il secondo disco. Poiché non c'è ancora una catena su di esso, creiamo un backup completo, dopo di che appare la seconda catena di tre punti:
Infine, è il momento di ricollegare il primo disco. E qui inizia la magia, poiché l'attività non creerà un backup completo, ma semplicemente continuerà la catena incrementale:
Dopo di ciò, essenzialmente ogni disco avrà la propria catena indipendente. Pertanto, il retention qui non si riferisce al numero di punti su tutti i dischi, ma al numero di punti su ciascun disco individualmente.
Backup copy e repository Linux su archiviazione di rete
E ancora, tutta l'eleganza svanisce se il repository non è su un disco locale Windows. Questo scenario funziona in modo simile a quello discusso sopra con l'assegnazione semplice. Ad ogni rotazione, BCJ creerà un backup completo e i punti esistenti verranno dimenticati. Per non rimanere senza spazio libero, è necessario utilizzare DWORD ForceDeleteBackupFiles.
Conclusione
Quindi, in seguito a questo lungo testo, abbiamo esaminato due tipi di assegnazione. Certamente ci sono molte più assegnazioni, ma non possiamo coprire tutte in un solo articolo. Se dopo la lettura avete domande, scrivetele nei commenti, sarei felice di rispondere personalmente.
Fonte: habr.com
