Il Capacity Tier (o come lo chiamiamo internamente, captir) è stato introdotto ai tempi di Veeam Backup and Replication 9.5 Update 4 con il nome di Archive Tier. L'idea alla base è quella di consentire il trasferimento dei backup che sono scaduti dal cosiddetto operational restore window verso gli oggetti di archiviazione. Questo ha aiutato a liberare spazio su disco per gli utenti che ne avevano poco. Questa opzione era chiamata Move Mode.

Per eseguire questa semplice (o così sembrava) operazione, era sufficiente soddisfare due condizioni: tutti i punti del backup da spostare devono essere al di fuori del suddetto operational restore window, che è specificato esplicitamente nell'interfaccia utente. In secondo luogo: la catena deve essere in quello che viene definito 'modo sigillato' (sealed backup chain o Inactive Backup Chain). Ciò significa che nel tempo non ci sono modifiche all'interno di questa catena.

Ma nella VBR v10, il concetto è stato arricchito con nuove funzionalità — è stato introdotto il Copy Mode, il Sealed Mode e un'opzione con un nome difficile da pronunciare: Immutability.

Di queste affascinanti novità parleremo oggi. Cominceremo con il modo in cui funzionava in VBR 9.5u4, per poi passare alle modifiche nella decima versione.

E scusatemi puristi del linguaggio, ma è impossibile tradurre troppi termini.
Quindi ci saranno molti anglicismi.
E molte gif.
E immagini.

• Senza alcun rimpianto. L'autore dell'articolo.

Come era

Bene, iniziamo con l'analisi della finestra di ripristino operativo e del backup sigillato (o come vengono chiamati nella documentazione Inactive Backup Chain). Senza la loro comprensione, non sarà possibile spiegare ulteriormente.

Come possiamo vedere nell'immagine, abbiamo una certa catena di backup con blocchi di dati, che si trova nel repositorio Performance tier SOBR, a cui è collegato il Capacity Tier. La nostra finestra di backup operativo è di tre giorni.

Pertanto, il .vbk creato lunedì sigilla la precedente catena, il cui intervallo è impostato su tre giorni. E, quindi, possiamo tranquillamente iniziare a trasferire nel capacity tier tutto ciò che è più vecchio di questi tre giorni.

Ma cosa si intendeva esattamente per catena sigillata e cosa poteva essere inviato nel capacity tier nell'update 4?

Per il Forward Incremental, il segno di sigillatura della catena è la creazione di un nuovo full backup. E non importa come viene ottenuto questo full backup: si considerano sia i backup full sintetici sia i backup full attivi.

Nel caso del Reverse, si tratta di tutti i file che non rientrano nella finestra operativa.

Nel caso di Forward increment con rollback, si tratta di tutti i rollback e dei file .vbk, se c'è un altro .vbk nell'extent di performance.

Ora consideriamo il funzionamento con le catene di Backup Copy. Qui veniva inviato solo ciò che rientrava nella retention GFS. Perché tutto ciò che è contenuto in catene di backup copy più recenti può essere in un modo o nell'altro modificato.

Ora diamo un'occhiata sotto il cofano. Qui avviene un processo chiamato deidratazione: si lasciano i placeholder dei file di backup sull'extent e si spostano i blocchi da questi file al capacity tier. Per ottimizzare questo processo, si utilizza l'indice di deidratazione, che consente di non copiare i blocchi già copiati nel capacity tier.

Vediamo come si presenta con un esempio: supponiamo di avere un file .vbk, uscito dalla finestra operativa e appartenente a una catena sigillata. Questo significa che abbiamo il pieno diritto di trasferirlo nel capacity tier. Al momento del trasferimento, viene creato un file di metadati nel capacity tier e i blocchi del file trasferito. Nel file di metadati a livello di riferimenti viene descritto di quali blocchi è composto il nostro file. Nel caso dell'immagine, il nostro primo file è composto dai blocchi a, b, c e nel metadati sono presenti riferimenti a questi blocchi. Quando abbiamo un secondo file .vbk pronto per il trasferimento e composto dai blocchi a, b e d, analizzando l'indice di deidratazione, ci rendiamo conto che dobbiamo trasferire solo il blocco d. E il suo file di metadati conterrà riferimenti ai due blocchi precedenti e uno nuovo.

Di conseguenza, il processo di riempimento di questi placeholder con i dati è chiamato rigenerazione. Qui si utilizza un indice di rigenerazione che si basa sul file .vbk più vecchio presente sull'estensione di performance locale. Quindi, se l'utente desidera ripristinare un file dal tier di capacità, creiamo innanzitutto un indice dei blocchi del backup completo più vecchio e trasferiamo dal tier di capacità solo i blocchi mancanti. Nel caso rappresentato nell'immagine, per rigenerare FullBackup1.vbk secondo l'indice di rigenerazione, abbiamo bisogno solo del blocco C, che preleviamo dal tier di capacità. Se il tier di capacità è un oggetto di storage cloud, questo consente di risparmiare enormi somme di denaro.

Può sembrare che questa tecnologia sia identica a quella utilizzata negli acceleratori WAN, ma non è così. Negli acceleratori, la deduplicazione è globale, mentre qui si utilizza la deduplicazione locale per ciascun file a un determinato offset. Questo è dovuto alla differenza nei compiti risolti: qui dobbiamo copiare grandi file di backup completi e, secondo le nostre ricerche, anche se tra di essi passa un lungo periodo di tempo, tale algoritmo di deduplicazione offre i migliori risultati.

Ma più indici al dio degli indici! Esiste ancora un indice per il ripristino dei dati! Quando avviamo il ripristino di una macchina situata nel capacity tier, leggeremo solo i blocchi di dati unici che non sono presenti nel performance tier.

Come è

Con questa parte introduttiva è tutto. È piuttosto dettagliata, ma, come già detto, senza questi dettagli non sarebbe possibile spiegare come funzionano le nuove funzionalità. Quindi, senza ulteriori introduzioni, passiamo al primo.

Modalità di copia

È in gran parte basata su tecnologie esistenti, ma presenta una logica di utilizzo completamente diversa. 

L'obiettivo di questa modalità è garantire che tutti i dati presenti sullo storage locale abbiano una copia nel campione di capacità.

Se confrontiamo direttamente le modalità Move e Copy, si può dire che:

• È possibile spostare solo una catena sigillata. Nel caso della modalità copia, tutto viene trasferito, indipendentemente da ciò che accade nel lavoro di backup.
• Il trasferimento si attiva quando i file escono dai limiti della finestra di backup operativo, mentre la copia si attiva non appena viene creato un file di backup.
• Il monitoraggio dei nuovi dati da copiare avviene costantemente, mentre per lo spostamento avveniva ogni 4 ore.

Nella valutazione della nuova modalità, suggerisco di partire da esempi semplici a quelli complessi.

Nel caso più banale, semplicemente compaiono nuovi file con incrementi, e noi li copiamo nel campione di capacità. Indipendentemente dalla modalità utilizzata nel lavoro di backup, dal fatto che appartenga o meno alla parte sigillata della catena, e che la nostra finestra operativa sia scaduta o meno. Abbiamo semplicemente preso e copiato.

Il processo alla base di questo rimane comunque la deidratazione come descritto sopra. In modalità copia, si assicura anche che non copiamo blocchi già presenti nel nostro storage. L'unica differenza è che, mentre in modalità spostamento sostituivamo i file reali con file vuoti, qui non li tocchiamo e lasciamo tutto com'è. Per il resto, si tratta dello stesso indice di deidratazione che si impegna a risparmiare i vostri soldi e il vostro tempo.

Sorge la domanda: se guardiamo nell'interfaccia utente, c'è la possibilità di scegliere entrambe le opzioni contemporaneamente. Come funzionerà questa modalità combinata?

Analizziamo.

L'inizio è standard: viene creato un file di backup e coperto immediatamente. Viene creato anche un incremento e anch'esso copiato. Questo continua fino a quando ci rendiamo conto che i file sono usciti dalla nostra finestra operativa e si è formata una catena sigillata. A questo punto, eseguiamo l'operazione di deidratazione e sostituiamo questi file con file vuoti. Naturalmente, non copiamo nuovamente nulla su capacity tier.

Tutta questa logica affascinante è gestita semplicemente da un solo flag nell'interfaccia: Copy backups to object storage as soon as they are created.

Ma a cosa ci serve questa modalità Copy?

Meglio riformulare la domanda in questo modo: quali rischi stiamo proteggendo con questo strumento? Quale problema ci aiuta a risolvere?

La risposta è chiara: si tratta del recupero dei dati. Se abbiamo una copia completa dei dati locali sullo storage degli oggetti, non importa cosa succeda al nostro ambiente di produzione, possiamo sempre recuperare i dati dai file archiviati in un ipotetico Amazon.

Pertanto, esaminiamo i possibili scenari, partendo dal più semplice fino ad arrivare al più complesso.

La minaccia più semplice che possiamo affrontare è l'inaccessibilità di uno dei file nella catena di backup.

Una storia più triste è quando uno degli extent del nostro repository SOBR si guasta.

La situazione peggiora ulteriormente quando l'intero repository SOBR diventa inaccessibile, ma il capacity tier continua a funzionare.
E la situazione è disperata quando il server di backup smette di funzionare e il tuo primo istinto è correre verso il confine canadese in dieci minuti.

Adesso esaminiamo ogni situazione separatamente.

Quando perdiamo uno (anche più di uno) dei file di backup, è sufficiente avviare il processo di riscanalizzazione del repository e il file perso sarà sostituito da un file vuoto. E con il processo di reidratazione (menzionato all'inizio dell'articolo), l'utente potrà scaricare i dati dal capacity tier nello storage locale.

La situazione è ora più complessa. Supponiamo che il nostro SOBR sia costituito da due extent, operanti in modalità Performance, il che significa che i nostri .vbk e .vib sono distribuiti su di essi in uno strato piuttosto irregolare. A un certo punto, uno degli extent diventa inaccessibile e l'utente deve urgentemente ripristinare la macchina di cui una parte dei dati si trova proprio su quell'extent.

L'utente avvia la procedura guidata di ripristino, seleziona il punto a cui desidera ripristinare, e la procedura guidata si rende conto, durante il processo, che non ha tutti i dati necessari per il ripristino disponibili localmente e quindi deve scaricarli dal capacity tier. Tuttavia, i blocchi rimasti nello storage locale non verranno scaricati dal cloud. Grazie all'indice di ripristino (sì, di questo si parlava anche all'inizio dell'articolo).

Una variante di questo caso è che l'intero repository SOBR è diventato inaccessibile. In questo caso non abbiamo nulla da copiare dai depositi locali e tutti i blocchi vengono scaricati dal cloud.

E la situazione più interessante è che il server di backup è andato offline. Qui ci sono due possibilità: l'amministratore ha fatto un buon lavoro e ha eseguito backup di configurazione, oppure l'amministratore è stato un Burattino cattivo e non ha effettuato backup di configurazione.

Nel primo caso, sarà sufficiente avviare un'installazione pulita di VBR da qualche parte e ripristinare il database dal backup utilizzando gli strumenti di sistema. Una volta completato questo processo, tutto tornerà alla normalità. Oppure sarà ripristinato secondo uno degli scenari sopra.

Ma se l'amministratore è il suo stesso nemico, o se anche il backup della configurazione ha subito un misfatto leggendario, anche in questo caso non lo lasceremo in balia del destino. Per questa situazione abbiamo introdotto una nuova procedura chiamata Import Object Storage. Essa consente di saltare il processo di ricreazione manuale del repository SOBR e di collegare a esso una capacità di tier con successivo rescansione, e di semplicemente aggiungere l'object storage nell'interfaccia di Veeam e avviare la procedura di Import Storage Repository. L'unica cosa che potrebbe ostacolare il vostro accesso ai backup è la richiesta di inserire una password, se i vostri backup sono stati cifrati.

Questo è tutto riguardo il Copy Mode, e ora passiamo a

Sealed Mode

L'idea principale è che in un'estensione selezionata del repository SOBR non possano apparire nuovi backup. Fino alla versione 10 avevamo solo il Maintenance Mode, in cui era completamente vietato lavorare sul repository. Una sorta di modalità hardcore per disattivare lo storage, in cui era disponibile solo il pulsante Evacuate, che trasferiva i backup su un'altra estensione in modo temporaneo.

La modalità Sealed è una sorta di versione "soft": vietiamo la creazione di nuovi backup e rimuoviamo gradualmente quelli vecchi in base alla retention selezionata, ma non perdiamo la possibilità di recuperare dalle punti archiviati. È molto utile quando il nostro hardware sta per terminare la sua vita utile e deve essere sostituito, o deve essere liberato per qualcosa di più importante, e non abbiamo un posto dove trasferire tutto in una volta. O non possiamo eliminare.

Di conseguenza, il principio di funzionamento è abbastanza semplice: dobbiamo vietare tutte le operazioni di scrittura (l'emergere di nuovi dati), lasciando quelle di lettura (ripristini) e cancellazione (retention).

Entrambe le modalità possono essere utilizzate contemporaneamente, ma è importante considerare che la modalità Maintenance ha una priorità più alta.

Prendiamo come esempio un SOBR composto da due estremi. Supponiamo che nei primi quattro giorni siano stati creati backup in modalità Forward Forever Incremental, e poi sigilliamo l'estremo. Questo porta all'iniziativa di creare un nuovo attivo completo sul secondo estremo disponibile. Se la nostra retention è pari a quattro, quando l'intera catena situata sull'estremo sigillato supera il suo limite, può essere rimossa senza problemi.

Ci sono situazioni in cui la cancellazione avviene prima. Ad esempio, questo accade con il backup incrementale forward con full periodici. Se nei primi due giorni abbiamo creato backup full, e giovedì decidiamo di sigillare il repository, allora venerdì, quando viene creato un nuovo backup full, il file di lunedì verrà eliminato poiché a quel punto non ci sono dipendenze. E quel punto non dipende da nessun altro. Dopo di che aspettiamo che vengano create quattro istantanee nell'estensione disponibile e rimuoviamo le restanti tre, che non possono essere cancellate indipendentemente l'una dall'altra.

Le cose sono più semplici con il Reverse Incremental. In questo caso, i punti più vecchi non dipendono da nulla e possono essere facilmente rimossi. Pertanto, non appena viene creato un nuovo .vbk su un nuovo extent, i vecchi .vrb verranno rimossi uno alla volta.

A proposito, perché creiamo ogni volta un nuovo .vbk: se non lo facessimo e continuassimo a usare la vecchia catena di incrementi, il vecchio .vbk rimarrebbe bloccato indefinitamente in qualsiasi modalità, impedendone la cancellazione. Quindi è stata presa la decisione che, non appena l'estensione viene sigillata, creiamo un full backup su un'estensione libera.

Le cose sono più complicate con il capacity tier.

Iniziamo a considerare la modalità copy. Supponiamo che abbiamo creato backup attivamente per quattro giorni e poi il capacity tier è stato sigillato. Non eliminiamo nulla, ma attendiamo con pazienza la retention, dopodiché rimuoviamo i dati dal capacity tier.

Avviene più o meno la stessa cosa in modalità move: attendiamo la retention, eliminiamo il vecchio nello storage locale e rimuoviamo ciò che è conservato nell'object storage.

Un esempio interessante è quello del Forever forward incremental. Impostiamo la retention su tre punti e iniziamo a fare backup da lunedì, che vengono copiati regolarmente nel cloud. Dopo la sigillatura dello storage, i backup continuano a essere creati, mantenendo i tre punti, ma i dati conservati nel capacity tier rimangono dipendenti e non possono essere eliminati. Quindi aspettiamo giovedì, quando il nostro .vbk supera la retention, e solo allora possiamo eliminare tranquillamente l'intera catena salvata.

E una piccola precisazione: tutti gli esempi qui sono mostrati con una sola macchina. Se nel backup ne avete più di una, la retention varierà a seconda che sia stata eseguita una Active Full o meno.

Ecco, fondamentalmente è tutto. Passiamo quindi alla funzione più hardcore —

Immutability

Come nei punti precedenti, prima di tutto, parliamo del problema che questa funzione risolve. Una volta che carichiamo i nostri backup per l'archiviazione, sorge un forte desiderio di garantire la loro integrità, cioè di vietarne fisicamente l'eliminazione e qualsiasi modifica durante il periodo di retention stabilito. Questo vale anche per gli amministratori, anche sotto i loro account root. Questo consente di proteggere i backup da danni accidentali o intenzionali. Chi lavora con AWS potrebbe aver incontrato una funzione simile chiamata Object Lock.

Ora consideriamo la modalità in termini generali e poi approfondiremo i dettagli. Nel nostro esempio, l'Immutability sarà attivata per il nostro capacity tier con una retention di quattro giorni. E nel backup sarà abilitata la modalità Copy.

L'Immutability non interagisce in alcun modo con la retention generale. Ad esempio, non aggiunge punti aggiuntivi o qualcosa del genere. Semplicemente, per quattro giorni la persona non può eliminare i file dei backup. Se si esegue un backup lunedì, il file potrà essere eliminato solo venerdì.

Tutti i concetti precedentemente spiegati riguardanti la deidrazione, gli indici e i metadati continuano a funzionare esattamente allo stesso modo. Ma con una condizione: il blocco è applicato non solo ai dati, ma anche ai metadati. Questo è stato fatto nel caso in cui un malintenzionato decidesse di cancellare il nostro database di metadati, affinché i blocchi con i dati non si trasformassero in una pura massa binaria senza valore.

E ora è il momento perfetto per spiegare la nostra tecnologia di generazione dei blocchi. O block generation. A tal fine, consideriamo la situazione che ha portato alla sua nascita.

Prendiamo una timeline di sei giorni e segniamo in basso il tempo di attesa per la scadenza dell'immutabilità. Creiamo, quindi, nel primo giorno un file composto dal blocco a e dai suoi metadati. Se l'immutabilità è fissata a tre giorni, è logico supporre che nel quarto giorno i dati saranno sbloccati e rimossi. Nel secondo giorno aggiungeremo un nuovo file2, composto dal blocco b con le stesse impostazioni. Il blocco a dovrebbe ancora essere rimosso nel quarto giorno. Ma nel terzo giorno succede qualcosa di terribile: viene creato il file File3, composto da un nuovo blocco d e un collegamento al vecchio blocco a. Ciò significa che per il blocco a il suo flag di immutabilità deve essere ripristinato a un nuovo periodo, che si sposta al sesto giorno. E qui sorge il problema: nei backup reali di tali blocchi si genera un'enorme quantità. E per estendere il loro periodo di immutabilità, è necessario effettuare un enorme numero di richieste ogni volta. E in effetti sarà un processo quotidiano quasi infinito, poiché con grande probabilità ogni volta che copiamo troveremo enormi pacchetti di blocchi deduplicati. E cosa significa un gran numero di richieste per i fornitori di storage oggetti? Esatto! Un enorme conto a fine mese.

E per non far pagare ingenti somme ai nostri clienti fidati senza motivo, è stato ideato un meccanismo di generazione dei blocchi. Si tratta di un periodo aggiuntivo che integriamo al periodo di immutabilità stabilito. Nell'esempio sottostante, questo periodo è di due giorni. Ma si tratta solo di un esempio. Nella realtà, si utilizza una formula specifica che fornisce circa dieci giorni aggiuntivi in caso di blocco mensile.

Continuiamo a considerare la stessa situazione, ma ora con la generazione di blocchi. Creiamo nel primo giorno il file1 dal blocco a e dai metadati. Sommiamo il periodo di generazione e l'immutabilità — quindi, la possibilità di eliminare il file sarà il sesto giorno. Se nel secondo giorno creiamo File2, costituito dal blocco b e da un riferimento al blocco a, la data prevista per l'eliminazione non cambia. Rimane fissata al sesto giorno. In questo modo speriamo di risparmiare denaro riducendo il numero di richieste. L'unica situazione in cui la scadenza può essere spostata è se il periodo di generazione è scaduto. Cioè, se al terzo giorno il nuovo File3 contiene un riferimento al blocco a, verrà aggiunta la generazione 2 poiché la Gen1 è già scaduta. E la data prevista per l'eliminazione del blocco a si sposterà all'ottavo giorno. Questo ci consente di ridurre drasticamente il numero di richieste per prolungare la vita dei blocchi deduplicati, risparmiando notevolmente ai clienti.

La tecnologia è disponibile per gli utenti di S3 e hardware compatibile con S3, i cui produttori garantiscono che la loro implementazione non differisce da quella di Amazon. Da qui la risposta alla legittima domanda sul perché non sia supportato Azure: hanno una funzionalità simile, ma funziona a livello di contenitori e non di oggetti singoli. A proposito, su Amazon stesso l'object lock è disponibile in due modalità: compliance e governance. Nel secondo caso, c'è la possibilità che l'amministratore supremo possa comunque eliminare i dati nonostante l'object lock. Nel caso di compliance, tutto è bloccato definitivamente e i backup non possono essere rimossi da nessuno. Nemmeno dagli amministratori di Amazon (secondo le loro dichiarazioni ufficiali). Supportiamo proprio questa modalità.

E, tradizionalmente, qualche link utile:

• Riguardo Generazione di Blocchi in tutti i dettagli.
• Tutte le informazioni su Veeam Backup & Replication 10 nel miglior modo possibile
• maggiore numero di partizioni. Capacity Tier nei dettagli

Fonte: habr.com