Il livello di capacità (o come lo chiamiamo in Vim - captir) è apparso ai tempi di Veeam Backup and Replication 9.5 Update 4 con il nome Archive Tier. L'idea alla base è quella di rendere possibile lo spostamento dei backup che sono caduti fuori dalla cosiddetta finestra di ripristino operativo nell'object storage. Ciò ha contribuito a liberare spazio su disco per gli utenti che ne avevano poco. E questa opzione si chiamava Modalità spostamento.

Per eseguire questa semplice (come sembra) azione, è stato sufficiente soddisfare due condizioni: tutti i punti del backup spostato devono trovarsi all'esterno dei limiti della finestra di ripristino operativo sopra menzionata, impostata esplicitamente nell'interfaccia utente. E secondo: la catena deve essere nella cosiddetta “forma sigillata” (catena di backup sigillata o catena di backup inattiva). Cioè, nel tempo non si verificano cambiamenti in questa catena.

Ma in VBR v10, il concetto è stato integrato con nuove funzioni: modalità copia, modalità sigillata ed è apparsa una cosa con il nome difficile da pronunciare Immutabilità.

Queste sono le cose affascinanti di cui parleremo oggi. Innanzitutto su come funzionava in VBR9.5u4 e poi sui cambiamenti nella decima versione.

E mi perdonino i paladini del linguaggio puro, ma ci sono troppi termini che non possono essere tradotti.
Quindi ci saranno un sacco di anglicismi qui.
E un sacco di gif.
E immagini.

• Senza il minimo rammarico. Autore dell'articolo.

Com'era

Bene, iniziamo analizzando la finestra di ripristino operativo e il backup sigillato (o come vengono chiamati nella documentazione della catena di backup inattiva). Senza la loro comprensione non sarà possibile alcuna ulteriore spiegazione.

Come vediamo nell'immagine, abbiamo una sorta di catena di backup con blocchi di dati, che si trova sul Performance tier SOBR del repository a cui è connesso il tier di capacità. La nostra finestra di backup operativo è di tre giorni.

Di conseguenza, il .vbk creato lunedì sigilla la catena precedente, la cui finestra è fissata a tre giorni. Ciò significa che puoi tranquillamente iniziare a trasportare tutto ciò che è più vecchio di questi tre giorni al poligono di tiro.

Ma cosa si intendeva esattamente per catena sigillata e cosa si poteva inviare al poligono di tiro capiente nell'aggiornamento 4?

Per Forward Incremental, un segno di chiusura della catena è la creazione di un nuovo backup completo. E non importa come viene ottenuto questo backup completo: vengono considerati sia i backup completi sintetici che quelli completi attivi.

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

Nel caso dell'incremento in avanti con rollback, si tratta di tutti i rollback e .vbk, se è presente un altro .vbk nell'estensione della prestazione

Consideriamo ora la possibilità di lavorare con le catene di copie di backup. Qui sono stati trasportati solo gli elementi che rientrano nella conservazione GFS. Perché tutto ciò che è archiviato nelle catene di copie di backup più recenti può essere modificato in un modo o nell'altro.

Ora guardiamo sotto il cofano. Lì si verifica un processo chiamato disidratazione, che lascia file di backup vuoti nell'estensione e trascina i blocchi da questi file al poligono di tiro della capacità. Per ottimizzare questo processo viene utilizzato il cosiddetto indice di disidratazione, che consente di evitare di copiare blocchi già copiati nel poligono di capacità.

Vediamo come appare con un esempio: diciamo di avere un .vbk che è uscito dalla finestra della transazione e appartiene a una catena sigillata. Ciò significa che abbiamo tutto il diritto di spostarlo nel poligono di tiro con capacità. Al momento dello spostamento, viene creato un file di metadati nel trattino di capacità e nei blocchi del file trasferito. Il file di metadati a livello di collegamento descrive in quali blocchi è costituito il nostro file. Nel caso in figura, il nostro primo file è costituito dai blocchi a, b, c e i metadati contengono collegamenti a questi blocchi. Quando abbiamo un secondo file .vbk, pronto da spostare e composto dai blocchi a, b e d, noi, analizzando l'indice di disidratazione, comprendiamo che è necessario trasferire solo il blocco d. E il suo file di metadati conterrà collegamenti a due blocchi precedenti e uno nuovo.

Di conseguenza, il processo di riempimento di questi spazi vuoti con i dati è chiamato reidratazione. Utilizza già il proprio indice di reidratazione, basato sul file .vbk più vecchio nell'estensione delle prestazioni locali. Cioè, se l'utente desidera restituire un file dal poligono di tiro di capacità, creiamo prima un indice dei blocchi del backup completo più vecchio e trasferiamo solo i blocchi mancanti dal poligono di tiro di capacità. Nel caso presentato in figura, per reidratare FullBackup1.vbk secondo l'indice di reidratazione, abbiamo bisogno solo del blocco C, che preleviamo dal poligono di tiro di capacità. Se un oggetto cloud di archiviazione funge da poligono di tiro capiente, ciò consente di risparmiare enormi quantità di denaro.

Qui può sembrare che questa tecnologia sia identica a quella utilizzata negli acceleratori WAN, ma sembra solo così. Negli acceleratori, la deduplicazione è globale; in questo caso, la deduplicazione locale viene utilizzata all'interno di ciascun file con un offset specifico. Ciò accade a causa della differenza nei compiti da risolvere: qui dobbiamo copiare file di backup completi di grandi dimensioni e, secondo la nostra ricerca, anche se passa un lungo periodo di tempo tra loro, questo algoritmo di deduplicazione dà il risultato migliore.

Ma più indici per il dio degli indici! C'è anche un indice per il recupero dei dati! Quando iniziamo a ripristinare una macchina situata nel trattino capacità, leggeremo solo i blocchi di dati univoci che non si trovano nel trattino prestazioni.

Come è diventato

Questo è tutto per la parte introduttiva. È abbastanza dettagliato, ma come accennato in precedenza, senza questi dettagli non sarà possibile spiegare come funzionano le nuove funzioni. Pertanto, senza ulteriori indugi, passiamo al primo.

Modalità di copia

Si basa in gran parte su tecnologie esistenti, ma porta con sé una logica di utilizzo completamente diversa. 

Lo scopo di questa modalità è garantire che tutti i dati posizionati nell'estensione locale abbiano una copia nel trattino della capacità.

Se confronti frontalmente le modalità Sposta e Copia, apparirà così:

• È possibile spostare solo la catena sigillata. Nel caso della modalità copia, viene trasferito assolutamente tutto, indipendentemente da ciò che accade nel processo di backup.
• Lo spostamento viene attivato quando i file superano i limiti della finestra di backup operativa e la copia viene avviata non appena viene visualizzato il file di backup.
• Il monitoraggio dei nuovi dati per la copia avviene costantemente e per lo spostamento viene attivato una volta ogni 4 ore.

Nel considerare la nuova modalità, propongo di passare dagli esempi semplici a quelli complessi.

Nel caso più comune, abbiamo semplicemente nuovi file con incrementi e li copiamo semplicemente nel poligono di tiro con capacità. Indipendentemente dalla modalità utilizzata nel processo di backup, indipendentemente dal fatto che appartenga o meno alla parte sigillata della catena, indipendentemente dal fatto che la nostra finestra operativa sia scaduta. L'hanno semplicemente preso e copiato.

Il processo alla base di questo è ancora la disidratazione come descritto sopra. In modalità copia, si assicura anche di non copiare i blocchi già presenti nel nostro spazio di archiviazione. L’unica differenza è che se in modalità filmato sostituivamo i file reali con file fittizi, qui non li tocchiamo in alcun modo e lasciamo tutto così com’è. Altrimenti, è esattamente lo stesso indice di disidratazione, che cerca attentamente di risparmiare tempo e denaro.

La domanda sorge spontanea: se guardi l'interfaccia utente, è possibile selezionare entrambe le opzioni contemporaneamente. Come funzionerà questa modalità combinata?

Capiamo

L'inizio è standard: un file di backup viene creato e copiato immediatamente. Viene creato un incremento e anche copiato. Ciò accade fino al momento in cui ci rendiamo conto che i file sono usciti dalla nostra finestra operativa ed è apparsa una catena sigillata. A questo punto eseguiamo un'operazione di disidratazione e sostituiamo questi file con file fittizi. Naturalmente non copiamo nulla nel poligono di tiro con capacità.

Tutta questa affascinante logica è responsabile di una sola casella di controllo nell'interfaccia: Copia i backup nell'archivio oggetti non appena vengono creati.

Perché abbiamo bisogno di questa modalità Copia?

È ancora meglio riformulare la domanda in questo modo: da quali rischi siamo protetti con il suo aiuto? Quale problema ci aiuta a risolvere?

La risposta è ovvia: ovviamente si tratta di recupero dati. Se disponiamo di una copia completa dei dati locali sull'archiviazione degli oggetti, indipendentemente da ciò che accade al nostro prodotto, possiamo sempre ripristinare i dati dai file situati nell'Amazzonia condizionale.

Esaminiamo quindi gli scenari possibili, dal più semplice al più complesso.

La disgrazia più semplice che può capitarci è l'inaccessibilità di uno dei file nella catena di backup.

La storia più triste è che una delle estensioni del nostro repository SOBR si è rotta.

La situazione diventa ancora peggiore quando l'intero deposito SOBR diventa inaccessibile, ma il poligono di tiro funziona.
E tutto va davvero male: è allora che il server di backup muore e il tuo primo desiderio è provare a correre al confine canadese in dieci minuti.

Ora esaminiamo ciascuna situazione separatamente.

Quando abbiamo perso uno (e anche più) file di backup, tutto ciò che dobbiamo fare è avviare il processo di nuova scansione del repository e il file perso verrà sostituito con un file fittizio. E utilizzando il processo di reidratazione (di cui si è parlato all'inizio dell'articolo), l'utente sarà in grado di scaricare i dati dal poligono di tiro della capacità nella memoria locale.

Adesso la situazione è più complicata. Supponiamo che il nostro SOBR sia costituito da due estensioni in esecuzione in modalità Performance, il che significa che i nostri .vbk e .vib sono distribuiti su di essi in uno strato piuttosto irregolare. E ad un certo punto, una delle estensioni diventa non disponibile e l'utente ha urgente bisogno di ripristinare la macchina, parte dei cui dati si trova proprio su questa estensione.

L'utente avvia la procedura guidata di ripristino, seleziona il punto in cui desidera ripristinare e la procedura guidata, mentre lavora, si rende conto che non dispone di tutti i dati necessari per il ripristino in locale e quindi è necessario scaricarli dalla capacità di ripresa galleria. Allo stesso tempo, i blocchi che rimangono nello spazio di archiviazione locale non verranno scaricati dal cloud. Gloria all'indice di ripristino (sì, se ne parlava anche all'inizio dell'articolo).

Un sottotipo di questo caso è che l'intero repository SOBR è diventato inaccessibile. In questo caso, non abbiamo nulla da copiare dall'archivio locale e tutti i blocchi vengono scaricati dal cloud.

E la situazione più interessante è che il server di backup è morto. Ci sono due opzioni qui: l'amministratore è eccezionale e ha effettuato i backup della configurazione, e l'amministratore è un malvagio Pinocchio in persona e non ha eseguito i backup della configurazione.

Nel primo caso, gli basterà semplicemente implementare un'installazione pulita di VBR da qualche parte e ripristinare il suo database da un backup utilizzando mezzi standard. Alla fine di questo processo tutto tornerà alla normalità. Oppure verrà ripristinato secondo uno degli scenari sopra.

Ma se l'amministratore è il suo stesso nemico, o anche il backup della configurazione ha subito un fallimento epico, allora anche qui non lo lasceremo in balia del destino. Per questo caso, abbiamo introdotto una nuova procedura chiamata Import Object Storage. Ti consente di saltare il processo di ricreazione manuale di un repository SOBR e di allegarvi un poligono di tiro con successiva scansione, e di aggiungere semplicemente un oggetto di archiviazione all'interfaccia Vim ed eseguire la procedura di importazione del repository di archiviazione. L'unica cosa che può ostacolare te e i tuoi backup è la richiesta di inserimento di una password se i tuoi backup sono crittografati.

Probabilmente è tutto incentrato sulla modalità Copia e passiamo a

Modalità sigillata

L'idea principale è che i nuovi backup non possano apparire nell'estensione SOBR selezionata del repository. Prima della v10, avevamo solo la modalità di manutenzione, quando qualsiasi lavoro con il repository era completamente proibito. Una sorta di modalità hardcore per la chiusura dello spazio di archiviazione, in cui è disponibile solo il pulsante Evacua, che trasporta i backup in un'altra misura una volta.

E la modalità Sealed è una sorta di opzione "soft": proibiamo la creazione di nuovi backup ed eliminiamo gradualmente quelli vecchi in base alla conservazione selezionata, ma nel processo non perdiamo la capacità di ripristinare dai punti memorizzati. Una cosa molto utile quando abbiamo un componente hardware prossimo alla fine della sua vita e dobbiamo sostituirlo, oppure dobbiamo semplicemente liberarlo per qualcosa di più importante, ma non c'è nessun posto dove prenderlo e spostare tutto in una volta. Oppure non può essere cancellato.

Di conseguenza, il principio di funzionamento è abbastanza semplice: è necessario vietare tutte le operazioni di scrittura (la comparsa di nuovi dati), lasciando la lettura (ripristino) e l'eliminazione (conservazione).

Entrambe le modalità possono essere utilizzate contemporaneamente, ma tieni presente che la Manutenzione ha una priorità più alta.

Ad esempio, considera un SOBR composto da due estensioni. Supponiamo che per i primi quattro giorni abbiamo creato i backup in modalità Forward Forever Incremental e poi sigilliamo l'extent, questo porta al fatto di avviare la creazione di un nuovo full attivo sulla seconda estensione disponibile. Se la nostra ritenzione è quattro, quando l'intera catena situata nell'area sigillata va oltre i suoi limiti, viene cancellata con la coscienza pulita.

Ci sono situazioni in cui la cancellazione avviene prima. Ad esempio, questo è Inoltra incrementale con completi periodici. Se abbiamo creato backup completi per i primi due giorni e giovedì decidiamo di sigillare il repository, venerdì, quando verrà creato un nuovo backup, il file di lunedì verrà eliminato perché non ci sono dipendenze fino a questo punto. E il punto in sé non dipende da nessuno. Quindi aspettiamo che sull'estensione disponibile vengano creati quattro punti e cancelliamo i restanti tre, che non possono essere cancellati indipendentemente l'uno dall'altro.

Le cose sono più semplici con Reverse Incremental. In esso, i punti più vecchi non dipendono da nulla e possono essere cancellati in sicurezza. Pertanto non appena verrà creato un nuovo .vbk su una nuova estensione, i vecchi .vrbs verranno eliminati uno ad uno.

A proposito, perché creiamo un nuovo .vbk ogni volta: se non lo creassimo, ma continuassimo la vecchia catena di incrementi, il vecchio .vbk si bloccherebbe per un tempo infinito in qualsiasi modalità, impedendone l'eliminazione. Pertanto si è deciso che non appena l'estensione sarà sigillata, creeremo un backup completo sull'estensione libera.

Le cose sono più complicate con la capacità del poligono di tiro.

Per prima cosa, diamo un'occhiata alla modalità copia. Supponiamo di aver creato attivamente dei backup per quattro giorni e quindi di sigillare la capacità del poligono di tiro. Non cancelliamo nulla, ma sopportiamo umilmente la conservazione, dopodiché cancelliamo i dati dal poligono di tiro.

Approssimativamente la stessa cosa accade in modalità spostamento: aspettiamo il ritocco, eliminiamo quello vecchio nella memoria locale ed eliminiamo quello memorizzato nella memoria oggetti.

Un esempio interessante con Forever forward incremental. Installiamo la conservazione in tre punti e lunedì iniziamo a eseguire i backup, che vengono regolarmente copiati nel cloud. Dopo aver sigillato l'archiviazione, si continuano a creare backup, mantenendo tre punti, ma i dati archiviati nel trattino della capacità rimangono dipendenti e non possono essere eliminati. Aspettiamo quindi fino a giovedì, quando il nostro .vbk va oltre la conservazione, e solo allora eliminiamo con calma l'intera catena salvata.

E un piccolo disclaimer: tutti gli esempi qui sono mostrati con una macchina. Se ne hai diversi nel backup, il loro ritocco sarà diverso a seconda che sia stato effettuato o meno l'Active Full.

Questo è fondamentalmente tutto quello che c'è da fare. Passiamo quindi alla caratteristica più hardcore:

Immutabilità

Come per i punti precedenti, la prima cosa è quale problema risolve questa funzione. Non appena carichiamo i nostri backup da qualche parte per l'archiviazione, c'è un forte desiderio di garantirne la sicurezza, cioè di vietarne fisicamente la cancellazione e qualsiasi modifica durante un determinato periodo di conservazione. Inclusi gli amministratori, anche sotto i loro account root. Ciò consente di proteggerli da danni accidentali o intenzionali. Chiunque lavori con AWS potrebbe essersi imbattuto in una funzionalità simile chiamata Object Lock.

Ora diamo un'occhiata alla modalità in termini generali, quindi approfondiamo i dettagli. Nel nostro esempio, l'immutabilità sarà abilitata per il nostro poligono di tiro con una conservazione di quattro giorni. E la modalità Copia è abilitata nel backup.

L'immutabilità non interagisce in alcun modo con la ritenzione generale. Ad esempio, non aggiunge punti extra o cose del genere. È solo che una persona non può eliminare i file di backup entro quattro giorni. Se esegui un backup lunedì, potrai eliminare il file solo venerdì.

Tutti i concetti di disidratazione, indici e metadati spiegati in precedenza continuano a funzionare esattamente allo stesso modo. Ma con una condizione: il blocco è impostato non solo sui dati, ma anche sui metadati. Questo viene fatto nel caso in cui un astuto utente malintenzionato decida di cancellare il nostro database di metadati e di impedire che i blocchi di dati si trasformino in inutile poltiglia binaria.

Ora è il momento ideale per spiegare la nostra tecnologia di generazione dei blocchi. Oppure blocca la generazione. Per fare ciò, considera la situazione che ha portato alla sua comparsa.

Prendiamo una scala temporale di sei giorni e di seguito segneremo il tempo della scadenza prevista dell'immutabilità. Il primo giorno prendiamo e creiamo un file composto dal blocco dati a e dai relativi metadati. Se l'immutabilità è impostata su tre giorni, è logico supporre che il quarto giorno i dati verranno sbloccati ed eliminati. Il secondo giorno aggiungeremo un nuovo file2, composto dal blocco b con le stesse impostazioni. Il blocco deve ancora essere rimosso il quarto giorno. Ma il terzo giorno accade qualcosa di terribile: viene creato un file File3, costituito da un nuovo blocco d e da un collegamento al vecchio blocco a. Ciò significa che per un blocco e il suo flag di immutabilità deve essere reimpostato su una nuova data, che viene spostata al sesto giorno. E qui sorge un problema: nei backup reali esiste un numero enorme di tali blocchi. E per prolungare il loro periodo di immutabilità, è necessario effettuare ogni volta un numero enorme di richieste. E in effetti, questo sarà un processo quotidiano quasi infinito, poiché con un alto grado di probabilità troveremo pesanti pile di blocchi deduplicati con ogni copia. Cosa significa un gran numero di richieste da parte dei fornitori di object storage? Giusto! Conto enorme a fine mese.

E per non esporre all'improvviso i tuoi clienti preferiti a ingenti somme di denaro, è stato inventato il meccanismo di generazione dei blocchi. Questo è un periodo aggiuntivo che aggiungiamo al periodo di immutabilità impostato. Nell'esempio seguente, questo periodo è di due giorni. Ma questo è solo un esempio. In realtà, usano la loro formula, che dà circa dieci giorni aggiuntivi durante un blocco mensile.

Continuiamo a considerare la stessa situazione, ma con la generazione di blocchi. Il primo giorno creiamo il file1 dal blocco a e dai metadati. Sommiamo il periodo di generazione e l'immutabilità: ciò significa che l'opportunità di eliminare il file sarà il sesto giorno. Se il secondo giorno creiamo il File2, composto dal blocco b e da un collegamento al blocco a, non succede nulla alla data di eliminazione prevista. Si alzò come il sesto giorno. E così cerchiamo di risparmiare 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 contiene un collegamento per bloccare a, allora verrà aggiunta la generazione 2 poiché la Gen1 è già scaduta. E la data prevista per l'eliminazione del blocco a verrà spostata all'ottavo giorno. Ciò ci consente di ridurre drasticamente il numero di richieste per estendere la durata dei blocchi deduplicati, facendo risparmiare ai clienti un sacco di soldi.

La tecnologia stessa è disponibile per gli utenti di hardware S3 e compatibile con S3, i cui produttori garantiscono che la loro implementazione non differisce da quella di Amazon. Da qui la risposta alla domanda legittima sul perché Azure non è supportato: hanno una funzionalità simile, ma funziona a livello di contenitori, non di singoli oggetti. A proposito, Amazon stessa ha il blocco degli oggetti in due modalità: conformità e governance. Nel secondo caso rimane la possibilità che il più grande admin sopra admin e root sopra root, nonostante il blocco dell'oggetto, cancelli comunque i dati. In caso di conformità, tutto è saldamente inchiodato e nessuno può eliminare i backup. Anche gli amministratori di Amazon (secondo le loro dichiarazioni ufficiali). Questa è la modalità che supportiamo.

E, come al solito, alcuni link utili:

• Про Generazione di blocchi in ogni dettaglio.
• Tutte le informazioni su Veeam Backup & Replica 10 al suo meglio
• О Livello di capacità nei dettagli

Fonte: habr.com