Il Capacity Tier (o come lo chiamiamo internamente — kapitir) è apparso 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 fuori dalla cosiddetta finestra di ripristino operativo, verso archiviazione oggetti. Questo aiutava a liberare spazio su disco per quegli utenti che ne avevano poco. Questa opzione si chiama Move Mode.

Per eseguire questa semplice (o così sembra) operazione bastava rispettare due condizioni: tutti i punti del backup da spostare devono trovarsi oltre i confini della suddetta finestra di ripristino operativo, che è definita esplicitamente nell'interfaccia utente. E secondo: la catena deve essere in quello che si chiama formato «sigillato» (sealed backup chain o Inactive Backup Chain). Vale a dire, nel tempo non devono verificarsi cambiamenti in questa catena.

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

Di queste cose interessanti parleremo oggi. Prima di come funzionava in VBR9.5u4, e poi delle modifiche nella decima versione.

E perdonatemi, sostenitori della lingua pura, ma ci sono troppi termini impossibili da tradurre.
Quindi qui ci saranno molti anglicismi.
E molte gif.
E immagini.

Senza il minimo pentimento. L'autore dell'articolo.

Come riportato

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

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

Pertanto, il .vbk creato lunedì sigilla la catena precedente, la cui finestra è fissata a tre giorni. E, quindi, possiamo tranquillamente iniziare a spostare 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 che 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, ci saranno tutti i rollback e .vbk, se nel performance extent c'è un altro .vbk.

Ora consideriamo un'opzione di lavoro con le catene di Backup Copy. Qui si portava solo ciò che rientra 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: lasciare dei segnaposto dei file di backup sull'extent e spostare i blocchi da questi file nel capacity tier. Per ottimizzare questo processo si utilizza il cosiddetto indice di deidratazione, che permette di non copiare i blocchi che sono già stati copiati nel capacity tier.

Esaminiamo come appare con un esempio: supponiamo di avere un .vbk che è uscito dalla finestra operativa e appartiene a una catena sigillata. Significa che abbiamo piena autorità per spostarlo 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 link, è descritto da quali blocchi è composto il nostro file. Nella figura, il nostro primo file è composto dai blocchi a, b, c e nei metadati sono presenti i link 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 comprendiamo che dobbiamo trasferire solo il blocco d. E il suo file di metadati conterrà link ai due blocchi precedenti e uno nuovo.

Di conseguenza, il processo di riempimento inverso di questi segnaposto con i dati è chiamato reidratazione. Qui si utilizza già il proprio indice di reidratazione, basato sul più vecchio file .vbk nel performance extent locale. Cioè, se l'utente vuole recuperare un file dal capacity tier, prima creiamo un indice dei blocchi del backup completo più vecchio e trasferiamo dal capacity tier solo i blocchi mancanti. Nel caso presentato nella figura, per reidratare FullBackup1.vbk secondo l'indice di reidratazione ci manca solo il blocco C, che recuperiamo dal capacity tier. Se il capacity tier è un oggetto di storage cloud, questo consente di risparmiare enormi somme di denaro.

Qui potrebbe sembrare che questa tecnologia sia identica a quella utilizzata negli acceleratori WAN, ma è solo un'apparenza. Negli acceleratori la deduplicazione è globale, mentre qui si utilizza quella locale all'interno di ciascun file su un determinato offset. Questo avviene a causa della differenza nei problemi risolti: qui dobbiamo copiare grandi file di backup completi e, secondo le nostre ricerche, anche se tra di essi passa un lungo periodo, tale algoritmo di deduplicazione offre i risultati migliori.

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

Come è stato

Con questa introduzione abbiamo finito. È piuttosto dettagliata, ma come detto prima, senza questi dettagli non possiamo spiegare come funzionano le nuove funzionalità. Quindi, senza ulteriori preamboli, passiamo al primo argomento.

Modalità copia

In gran parte si basa su tecnologie esistenti, tuttavia porta con sé una logica d'uso del tutto diversa.

L'obiettivo di questa modalità è garantire che tutti i dati situati sull'extent locale abbiano una copia nel capacity tier.

Se confrontiamo direttamente le modalità Move e Copy, risulta così:

Puoi spostare solo una catena sigillata. Nel caso della modalità copia, vengono portati via assolutamente tutti, indipendentemente da ciò che accade nel lavoro di backup.
Lo spostamento si attiva quando i file eccedono i confini della finestra di backup operativo, mentre la copia si attiva non appena compare un file di backup.
Il monitoraggio dei nuovi dati da copiare avviene continuamente, mentre per lo spostamento avveniva ogni 4 ore.

Nella trattazione della nuova modalità propongo di passare da esempi semplici a esempi complessi.

Nel caso più banale abbiamo semplicemente nuovi file con incrementi, e li copiamo nel capacity tier. Indipendentemente dalla modalità utilizzata nel lavoro di backup, indipendentemente dal fatto che appartenga o meno alla parte sigillata della catena, indipendentemente dall'aver superato o meno la nostra finestra operativa. Semplicemente, abbiamo preso e copiato.

Il processo alla base di questo è ancora la disidratazione nella forma descritta sopra. In modalità copia, monitora anche affinché non si copiano blocchi già presenti nel nostro storage. L'unica differenza è che, mentre in modalità spostamento sostituivamo i file reali con file fittizi, qui non li tocchiamo affatto e lasciamo tutto com'è. Tutto il resto è esattamente lo stesso indice di disidratazione, che si impegna a risparmiare i vostri soldi e tempo.

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

Iniziamo.

L'inizio è standard: viene creato un file di backup e copiato immediatamente. Viene creato un incremento e anche questo viene copiato. Questo continua fino a quando non ci rendiamo conto che i file sono usciti dalla nostra finestra operativa e c'è una catena sigillata. A questo punto eseguiamo l'operazione di disidratazione e sostituiamo questi file con dei fittizi. Naturalmente, non copiamo nulla di nuovo nel tier di capacità.

Tutta questa logica affascinante è controllata semplicemente da una casella di controllo nell'interfaccia: Copy backups to object storage as soon as they are created.

A cosa ci serve questa modalità Copy?

È ancora meglio riformulare la domanda in questo modo: quali rischi stiamo proteggendo con essa? Quale problema ci aiuta a risolvere?

La risposta è ovvia: ovviamente si tratta di ripristino dei dati. Se abbiamo nel nostro object storage una copia completa dei dati locali, non importa cosa accada al nostro ambiente di produzione, possiamo sempre recuperare i dati dai file presenti nell'ipotetico Amazon.

Pertanto, diamo un'occhiata agli scenari possibili, dal più semplice al più complesso.

Il più semplice problema che potrebbe colpirci è l'inaccessibilità di uno dei file nella catena di backup.

Una storia più triste è quando uno degli extents del nostro repository SOBR si rompe.

Le cose si fanno ancora più brutte quando l'intero repository SOBR diventa inaccessibile, ma il tier di capacità è operativo.
E tutto va male quando il server di backup muore e il tuo primo desiderio è cercare di correre verso il confine canadese in dieci minuti.

Ora esaminiamo ogni situazione separatamente.

Quando abbiamo perso uno (ok, anche più di uno) dei file di backup, basta avviare il processo di riscanalizzazione del repository e il file perso sarà sostituito da un file vuoto. Grazie al processo di reidratazione (di cui si è parlato all'inizio dell'articolo), l'utente potrà scaricare i dati dal capacity tier verso lo storage locale.

Ora la situazione si complica. Supponiamo che il nostro SOBR sia composto da due extent, funzionanti 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 una macchina, parte dei cui 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 realizza durante il processo che non ha a disposizione localmente tutti i dati necessari per il ripristino, quindi deve scaricarli dal capacity tier. I blocchi che sono rimasti nello storage locale non verranno scaricati dal cloud. Grazie all'indice di ripristino (sì, se ne parlava anche all'inizio dell'articolo).

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

E la situazione più interessante è che il server di backup è andato in crash. Qui ci sono due possibilità: l'amministratore è stato saggio e ha effettuato backup della configurazione, oppure l'amministratore è stato un Burattino malvagio e non ha effettuato il backup della configurazione.

Nel primo caso, gli basterà semplicemente avviare un'installazione pulita di VBR da qualche parte e ripristinare il suo database da un backup utilizzando gli strumenti standard. Alla fine di questo processo, tutto tornerà come prima. In alternativa, sarà ripristinato secondo uno degli scenari sopra descritti.

Ma se l'amministratore è anche un suo nemico, o se il backup della configurazione ha subito un'epica sfortuna, anche in questo caso non lo lasceremo al suo destino. Per questa evenienza abbiamo introdotto una nuova procedura chiamata Import Object Storage. Essa permette di saltare il processo di ricreazione manuale del repository SOBR e di allegare ad esso il capacity tier con successivo rescansione, ma basta aggiungere l'object storage nell'interfaccia Veeam e avviare la procedura Import Storage Repository. L'unica cosa che potrebbe frapporsi tra voi e i vostri backup è la richiesta di inserire una password, se i vostri backup sono stati cifrati.

A questo punto, per quanto riguarda la modalità Copy, diciamo che è tutto e passiamo a

Modalità Sealed

L'idea principale è che sul extent selezionato del repository SOBR non possono apparire nuovi backup. Fino alla v10 avevamo solo la modalità Maintenance, in cui era completamente vietato qualsiasi lavoro con il repository. Era una sorta di modalità hardcore per disattivare lo storage, dove era disponibile solo il pulsante Evacuate, che trasferiva i backup su un altro extent.

La modalità Sealed è una sorta di versione 'morbida': vietiamo di creare nuovi backup e rimuoviamo gradualmente quelli vecchi secondo la retention selezionata, ma nel processo non perdiamo la possibilità di ripristinare dai punti memorizzati. È molto utile quando ci avviciniamo alla fine della vita dell'hardware e deve essere sostituito, oppure deve semplicemente essere liberato per qualcosa di più importante, senza avere la possibilità di trasferire tutto in una sola volta. O non si può eliminare.

Di conseguenza, il principio di funzionamento è piuttosto semplice: è necessario vietare tutte le operazioni di scrittura (l'emergere di nuovi dati), consentendo solo letture (ripristini) e cancellazioni (retention).

Entrambe le modalità possono essere utilizzate contemporaneamente, ma bisogna considerare che la modalità Maintenance ha una priorità superiore.

Come esempio, consideriamo un SOBR composto da due extents. Supponiamo che nei primi quattro giorni siano stati creati backup in modalità Forward Forever Incremental, e poi sigilliamo l'extent. Ciò porta all'innesco della creazione di un nuovo full attivo sul secondo extent disponibile. Se la nostra retention è di quattro, quando l'intera catena situata sull'extent sigillato supera i suoi limiti, viene rimossa senza problemi.

Ci sono situazioni in cui l'eliminazione avviene prima. Ad esempio, in caso di Forward incremental con fusioni periodiche. Se nei primi due giorni abbiamo creato backup completi e giovedì decidiamo di sigillare il repository, allora venerdì, quando verrà creato un nuovo backup completo, il file di lunedì sarà eliminato poiché a questo punto non ci sono dipendenze. E il punto stesso non dipende da nessuno. Dopodiché aspettiamo che vengano creati quattro punti sull'estensione disponibile e eliminiamo i restanti tre, che non possono essere eliminati indipendentemente l'uno dall'altro.

La situazione è più semplice con il Reverse Incremental. In questo caso, i punti più vecchi non dipendono da nulla e possono essere eliminati tranquillamente. Pertanto, non appena viene creato un nuovo .vbk su una nuova estensione, i vecchi .vrb verranno eliminati uno alla volta.

A proposito, perché creiamo ogni volta un nuovo .vbk: se non lo creassimo e continuassimo la vecchia catena di incrementi, il vecchio .vbk rimarrebbe in sospeso per un tempo indefinito in qualsiasi modalità, impedendone l'eliminazione. Pertanto, è stata presa la decisione che non appena l'estensione viene sigillata, creiamo un backup completo su una nuova estensione.

La situazione è più complicata con il capacity tier.

Iniziamo a considerare la modalità copy. Supponiamo di avere creato backup attivamente per quattro giorni e poi il capacity tier è stato sigillato. Non eliminiamo nulla, ma attendiamo pazientemente il periodo di retention, dopodiché eliminiamo i dati dal capacity tier.

Circa la stessa cosa accade nella modalità move: aspettiamo il periodo di retention, eliminiamo il vecchio nello storage locale, eliminiamo quello presente nell'object storage.

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

E una piccola nota: tutti gli esempi qui mostrati riguardano una sola macchina. Se nel backup ce ne sono più di una, il retention varierà a seconda che sia stato effettuato un Active Full o meno.

In effetti, è tutto. Quindi passiamo alla funzione più hardcore —

Immutabilità

Come con i punti precedenti, per prima cosa parliamo del problema che risolve questa funzione. Non appena esportiamo i nostri backup per l'archiviazione, nasce un forte desiderio di garantirne la sicurezza, ovvero di vietare fisicamente la loro eliminazione e qualsiasi modifica durante il periodo di retention stabilito. Questo vale anche per gli amministratori, anche per i loro account root. Ciò consente di proteggerli da danni accidentali o deliberati. Chi lavora con AWS potrebbe avere incontrato una funzione simile chiamata Object Lock.

Ora esaminiamo il modo di funzionare in generale, per poi approfondire i dettagli. Nel nostro esempio, l'Immutability sarà attivato per il nostro capacity tier con un retention di quattro giorni. E nel backup è attivata la modalità Copy.

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

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

E ora è arrivato il momento perfetto per spiegare la nostra tecnologia di generazione dei blocchi. O block generation. Per questo, consideriamo la situazione che ha portato alla sua creazione.

Prendiamo una scala temporale di sei giorni e segnaliamo in basso il tempo di scadenza atteso dell'immutabilità. Creiamo il primo giorno un file composto dal blocco a, insieme ai suoi metadati. Se l'immutabilità è impostata a tre giorni, è logico supporre che il quarto giorno i dati saranno sbloccati e rimossi. Il secondo giorno aggiungeremo un nuovo file2, composto dal blocco b con le stesse impostazioni. Il blocco a deve ancora essere rimosso il quarto giorno. Ma al terzo giorno accade l'orribile: viene creato un file File3, composto da un nuovo blocco d e da un riferimento al vecchio blocco a. Ciò significa che per il blocco a la sua bandiera di immutabilità deve essere ripristinata a un nuovo termine, che si sposta al sesto giorno. E qui sorge il problema: nei backup reali di tali blocchi si verifica un numero enorme di essi. E per prolungare il periodo di immutabilità, è necessario effettuare un numero enorme di richieste ogni volta. E, di fatto, sarà un processo quotidiano quasi infinito, poiché con alta probabilità, ogni volta che copiamo, troveremo enormi pacchi di blocchi deduplicati. E cosa significa una grande quantità di richieste dai fornitori di oggetti di archiviazione? Giusto! Una fattura enorme alla fine del mese.

E per non far segnare ai miei amati clienti somme consistenti senza motivo, è stato inventato un meccanismo di generazione dei blocchi. Si tratta di un periodo aggiuntivo che aggiungiamo al periodo di immutabilità stabilito. Nell'esempio qui sotto, tale periodo è pari a due giorni. Ma questo è solo un esempio. In realtà, si utilizza una propria formula che conferisce circa dieci giorni aggiuntivi per un blocco mensile.

Continuiamo a esaminare la stessa situazione, ma già con la generazione di blocchi. Creiamo il primo giorno file1 dal blocco a e dai metadati. Sommiamo il periodo di generazione e l'immutabilità: ciò significa che la possibilità di eliminare il file sarà al sesto giorno. Se il secondo giorno creiamo File2, composto dal blocco b e da un riferimento al blocco a, nulla accade alla data di eliminazione prevista. Rimane come era al sesto giorno. In questo modo stiamo cercando di risparmiare soldi sul numero di richieste. L'unica situazione in cui la scadenza può essere spostata è se il periodo di generazione è scaduto. Cioè, se il terzo giorno il nuovo File3 conterrà un riferimento al blocco a, verrà aggiunta la generazione 2 poiché Gen1 è già scaduta. E la data prevista di eliminazione del blocco a si sposterà all'ottavo giorno. Ciò ci consente di ridurre drasticamente il numero di richieste per il prolungamento della vita dei blocchi deduplicati, risparmiando un sacco di soldi ai clienti.

La tecnologia è disponibile per gli utenti S3 e per 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é Azure non sia supportato: hanno una funzionalità simile, ma funziona a livello di contenitori e non di singoli oggetti. A proposito, in Amazon stesso l'object lock è disponibile in due modalità: compliance e governance. Nel secondo caso, c'è la possibilità che l'amministratore più grande di tutti gli amministratori e il root dei root, nonostante l'object lock, possa comunque eliminare i dati. In caso di compliance, tutto è bloccato saldamente e i backup non possono essere eliminati da nessuno. Anche dagli amministratori di Amazon (secondo le loro dichiarazioni ufficiali). Sosteniamo proprio questa modalità.