{"id":84809,"date":"2020-06-11T01:42:41","date_gmt":"2020-06-10T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10"},"modified":"2020-06-11T01:42:41","modified_gmt":"2020-06-10T23:42:41","slug":"chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Il Capacity Tier (o come lo chiamiamo internamente, captir) \u00e8 stato introdotto ai tempi di Veeam Backup and Replication 9.5 Update 4 con il nome di Archive Tier. L'idea alla base \u00e8 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.<\/p>\n<p>Per eseguire questa semplice (o cos\u00ec 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 \u00e8 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\u00f2 significa che nel tempo non ci sono modifiche all'interno di questa catena.<\/p>\n<p>Ma nella VBR v10, il concetto \u00e8 stato arricchito con nuove funzionalit\u00e0 \u2014 \u00e8 stato introdotto il Copy Mode, il Sealed Mode e un'opzione con un nome difficile da pronunciare: Immutability.<\/p>\n<p>Di queste affascinanti novit\u00e0 parleremo oggi. Cominceremo con il modo in cui funzionava in VBR 9.5u4, per poi passare alle modifiche nella decima versione.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE scusatemi puristi del linguaggio, ma \u00e8 impossibile tradurre troppi termini.<br \/>\nQuindi ci saranno molti anglicismi.<br \/>\nE molte gif. <br \/>\nE immagini.<\/p>\n<ul>\n<li>Senza alcun rimpianto. L'autore dell'articolo.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Come era<\/h1>\n<p>\nBene, 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\u00e0 possibile spiegare ulteriormente.<\/p>\n<p>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 \u00e8 collegato il Capacity Tier. La nostra finestra di backup operativo \u00e8 di tre giorni.<\/p>\n<p>Pertanto, il .vbk creato luned\u00ec sigilla la precedente catena, il cui intervallo \u00e8 impostato su tre giorni. E, quindi, possiamo tranquillamente iniziare a trasferire nel capacity tier tutto ci\u00f2 che \u00e8 pi\u00f9 vecchio di questi tre giorni.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa cosa si intendeva esattamente per catena sigillata e cosa poteva essere inviato nel capacity tier nell'update 4?<\/p>\n<p>Per il Forward Incremental, il segno di sigillatura della catena \u00e8 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.<\/p>\n<p>Nel caso del Reverse, si tratta di tutti i file che non rientrano nella finestra operativa. <\/p>\n<p>Nel caso di Forward increment con rollback, si tratta di tutti i rollback e dei file .vbk, se c'\u00e8 un altro .vbk nell'extent di performance.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOra consideriamo il funzionamento con le catene di Backup Copy. Qui veniva inviato solo ci\u00f2 che rientrava nella retention GFS. Perch\u00e9 tutto ci\u00f2 che \u00e8 contenuto in catene di backup copy pi\u00f9 recenti pu\u00f2 essere in un modo o nell'altro modificato.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOra 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\u00e0 copiati nel capacity tier. <\/p>\n<p>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 \u00e8 composto il nostro file. Nel caso dell'immagine, il nostro primo file \u00e8 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\u00e0 riferimenti ai due blocchi precedenti e uno nuovo.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDi conseguenza, il processo di riempimento di questi placeholder con i dati \u00e8 chiamato rigenerazione. Qui si utilizza un indice di rigenerazione che si basa sul file .vbk pi\u00f9 vecchio presente sull'estensione di performance locale. Quindi, se l'utente desidera ripristinare un file dal tier di capacit\u00e0, creiamo innanzitutto un indice dei blocchi del backup completo pi\u00f9 vecchio e trasferiamo dal tier di capacit\u00e0 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\u00e0. Se il tier di capacit\u00e0 \u00e8 un oggetto di storage cloud, questo consente di risparmiare enormi somme di denaro.<\/p>\n<p>Pu\u00f2 sembrare che questa tecnologia sia identica a quella utilizzata negli acceleratori WAN, ma non \u00e8 cos\u00ec. Negli acceleratori, la deduplicazione \u00e8 globale, mentre qui si utilizza la deduplicazione locale per ciascun file a un determinato offset. Questo \u00e8 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa pi\u00f9 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Come \u00e8<\/h1>\n<p>\nCon questa parte introduttiva \u00e8 tutto. \u00c8 piuttosto dettagliata, ma, come gi\u00e0 detto, senza questi dettagli non sarebbe possibile spiegare come funzionano le nuove funzionalit\u00e0. Quindi, senza ulteriori introduzioni, passiamo al primo.<\/p>\n<h3>Modalit\u00e0 di copia<\/h3>\n<p>\n\u00c8 in gran parte basata su tecnologie esistenti, ma presenta una logica di utilizzo completamente diversa.\u00a0<\/p>\n<p>L'obiettivo di questa modalit\u00e0 \u00e8 garantire che tutti i dati presenti sullo storage locale abbiano una copia nel campione di capacit\u00e0.<\/p>\n<p>Se confrontiamo direttamente le modalit\u00e0 Move e Copy, si pu\u00f2 dire che:<\/p>\n<ul>\n<li>\u00c8 possibile spostare solo una catena sigillata. Nel caso della modalit\u00e0 copia, tutto viene trasferito, indipendentemente da ci\u00f2 che accade nel lavoro di backup.<\/li>\n<li>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.<\/li>\n<li>Il monitoraggio dei nuovi dati da copiare avviene costantemente, mentre per lo spostamento avveniva ogni 4 ore.<\/li>\n<\/ul>\n<p>\nNella valutazione della nuova modalit\u00e0, suggerisco di partire da esempi semplici a quelli complessi.<\/p>\n<p>Nel caso pi\u00f9 banale, semplicemente compaiono nuovi file con incrementi, e noi li copiamo nel campione di capacit\u00e0. Indipendentemente dalla modalit\u00e0 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.<\/p>\n<p>Il processo alla base di questo rimane comunque la deidratazione come descritto sopra. In modalit\u00e0 copia, si assicura anche che non copiamo blocchi gi\u00e0 presenti nel nostro storage. L'unica differenza \u00e8 che, mentre in modalit\u00e0 spostamento sostituivamo i file reali con file vuoti, qui non li tocchiamo e lasciamo tutto com'\u00e8. Per il resto, si tratta dello stesso indice di deidratazione che si impegna a risparmiare i vostri soldi e il vostro tempo.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSorge la domanda: se guardiamo nell'interfaccia utente, c'\u00e8 la possibilit\u00e0 di scegliere entrambe le opzioni contemporaneamente. Come funzioner\u00e0 questa modalit\u00e0 combinata?<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAnalizziamo.<\/p>\n<p>L'inizio \u00e8 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 \u00e8 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.<\/p>\n<p>Tutta questa logica affascinante \u00e8 gestita semplicemente da un solo flag nell'interfaccia: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Ma a cosa ci serve questa modalit\u00e0 Copy? <\/h3>\n<p>\nMeglio riformulare la domanda in questo modo: quali rischi stiamo proteggendo con questo strumento? Quale problema ci aiuta a risolvere?<\/p>\n<p>La risposta \u00e8 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.<\/p>\n<p>Pertanto, esaminiamo i possibili scenari, partendo dal pi\u00f9 semplice fino ad arrivare al pi\u00f9 complesso.<\/p>\n<p>La minaccia pi\u00f9 semplice che possiamo affrontare \u00e8 l'inaccessibilit\u00e0 di uno dei file nella catena di backup.<\/p>\n<p>Una storia pi\u00f9 triste \u00e8 quando uno degli extent del nostro repository SOBR si guasta.<\/p>\n<p>La situazione peggiora ulteriormente quando l'intero repository SOBR diventa inaccessibile, ma il capacity tier continua a funzionare.<br \/>\nE la situazione \u00e8 disperata quando il server di backup smette di funzionare e il tuo primo istinto \u00e8 correre verso il confine canadese in dieci minuti.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAdesso esaminiamo ogni situazione separatamente.<\/p>\n<p>Quando perdiamo uno (anche pi\u00f9 di uno) dei file di backup, \u00e8 sufficiente avviare il processo di riscanalizzazione del repository e il file perso sar\u00e0 sostituito da un file vuoto. E con il processo di reidratazione (menzionato all'inizio dell'articolo), l'utente potr\u00e0 scaricare i dati dal capacity tier nello storage locale.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa situazione \u00e8 ora pi\u00f9 complessa. Supponiamo che il nostro SOBR sia costituito da due extent, operanti in modalit\u00e0 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. <\/p>\n<p>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\u00ec, di questo si parlava anche all'inizio dell'articolo).<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna variante di questo caso \u00e8 che l'intero repository SOBR \u00e8 diventato inaccessibile. In questo caso non abbiamo nulla da copiare dai depositi locali e tutti i blocchi vengono scaricati dal cloud.<\/p>\n<p>E la situazione pi\u00f9 interessante \u00e8 che il server di backup \u00e8 andato offline. Qui ci sono due possibilit\u00e0: l'amministratore ha fatto un buon lavoro e ha eseguito backup di configurazione, oppure l'amministratore \u00e8 stato un Burattino cattivo e non ha effettuato backup di configurazione.<\/p>\n<p>Nel primo caso, sar\u00e0 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\u00e0 alla normalit\u00e0. Oppure sar\u00e0 ripristinato secondo uno degli scenari sopra.<\/p>\n<p>Ma se l'amministratore \u00e8 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\u00e0 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 \u00e8 la richiesta di inserire una password, se i vostri backup sono stati cifrati.<\/p>\n<p>Questo \u00e8 tutto riguardo il Copy Mode, e ora passiamo a<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nL'idea principale \u00e8 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\u00e0 hardcore per disattivare lo storage, in cui era disponibile solo il pulsante Evacuate, che trasferiva i backup su un'altra estensione in modo temporaneo.<\/p>\n<p>La modalit\u00e0 Sealed \u00e8 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\u00e0 di recuperare dalle punti archiviati. \u00c8 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\u00f9 importante, e non abbiamo un posto dove trasferire tutto in una volta. O non possiamo eliminare. <\/p>\n<p>Di conseguenza, il principio di funzionamento \u00e8 abbastanza semplice: dobbiamo vietare tutte le operazioni di scrittura (l'emergere di nuovi dati), lasciando quelle di lettura (ripristini) e cancellazione (retention).<\/p>\n<p>Entrambe le modalit\u00e0 possono essere utilizzate contemporaneamente, ma \u00e8 importante considerare che la modalit\u00e0 Maintenance ha una priorit\u00e0 pi\u00f9 alta.<\/p>\n<p>Prendiamo come esempio un SOBR composto da due estremi. Supponiamo che nei primi quattro giorni siano stati creati backup in modalit\u00e0 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 \u00e8 pari a quattro, quando l'intera catena situata sull'estremo sigillato supera il suo limite, pu\u00f2 essere rimossa senza problemi.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCi 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\u00ec decidiamo di sigillare il repository, allora venerd\u00ec, quando viene creato un nuovo backup full, il file di luned\u00ec verr\u00e0 eliminato poich\u00e9 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe cose sono pi\u00f9 semplici con il Reverse Incremental. In questo caso, i punti pi\u00f9 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.<\/p>\n<p>A proposito, perch\u00e9 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\u00e0, impedendone la cancellazione. Quindi \u00e8 stata presa la decisione che, non appena l'estensione viene sigillata, creiamo un full backup su un'estensione libera.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe cose sono pi\u00f9 complicate con il capacity tier. <\/p>\n<p>Iniziamo a considerare la modalit\u00e0 copy. Supponiamo che abbiamo creato backup attivamente per quattro giorni e poi il capacity tier \u00e8 stato sigillato. Non eliminiamo nulla, ma attendiamo con pazienza la retention, dopodich\u00e9 rimuoviamo i dati dal capacity tier.<\/p>\n<p>Avviene pi\u00f9 o meno la stessa cosa in modalit\u00e0 move: attendiamo la retention, eliminiamo il vecchio nello storage locale e rimuoviamo ci\u00f2 che \u00e8 conservato nell'object storage.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn esempio interessante \u00e8 quello del Forever forward incremental. Impostiamo la retention su tre punti e iniziamo a fare backup da luned\u00ec, 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\u00ec, quando il nostro .vbk supera la retention, e solo allora possiamo eliminare tranquillamente l'intera catena salvata.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE una piccola precisazione: tutti gli esempi qui sono mostrati con una sola macchina. Se nel backup ne avete pi\u00f9 di una, la retention varier\u00e0 a seconda che sia stata eseguita una Active Full o meno.<\/p>\n<p>Ecco, fondamentalmente \u00e8 tutto. Passiamo quindi alla funzione pi\u00f9 hardcore \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nCome 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\u00e0, cio\u00e8 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.<\/p>\n<p>Ora consideriamo la modalit\u00e0 in termini generali e poi approfondiremo i dettagli. Nel nostro esempio, l'Immutability sar\u00e0 attivata per il nostro capacity tier con una retention di quattro giorni. E nel backup sar\u00e0 abilitata la modalit\u00e0 Copy.<\/p>\n<p>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\u00f2 eliminare i file dei backup. Se si esegue un backup luned\u00ec, il file potr\u00e0 essere eliminato solo venerd\u00ec.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTutti 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 \u00e8 applicato non solo ai dati, ma anche ai metadati. Questo \u00e8 stato fatto nel caso in cui un malintenzionato decidesse di cancellare il nostro database di metadati, affinch\u00e9 i blocchi con i dati non si trasformassero in una pura massa binaria senza valore.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE ora \u00e8 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.<\/p>\n<p>Prendiamo una timeline di sei giorni e segniamo in basso il tempo di attesa per la scadenza dell'immutabilit\u00e0. Creiamo, quindi, nel primo giorno un file composto dal blocco a e dai suoi metadati. Se l'immutabilit\u00e0 \u00e8 fissata a tre giorni, \u00e8 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\u00f2 significa che per il blocco a il suo flag di immutabilit\u00e0 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\u00e0. E per estendere il loro periodo di immutabilit\u00e0, \u00e8 necessario effettuare un enorme numero di richieste ogni volta. E in effetti sar\u00e0 un processo quotidiano quasi infinito, poich\u00e9 con grande probabilit\u00e0 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE per non far pagare ingenti somme ai nostri clienti fidati senza motivo, \u00e8 stato ideato un meccanismo di generazione dei blocchi. Si tratta di un periodo aggiuntivo che integriamo al periodo di immutabilit\u00e0 stabilito. Nell'esempio sottostante, questo periodo \u00e8 di due giorni. Ma si tratta solo di un esempio. Nella realt\u00e0, si utilizza una formula specifica che fornisce circa dieci giorni aggiuntivi in caso di blocco mensile. <\/p>\n<p>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\u00e0 \u2014 quindi, la possibilit\u00e0 di eliminare il file sar\u00e0 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\u00f2 essere spostata \u00e8 se il periodo di generazione \u00e8 scaduto. Cio\u00e8, se al terzo giorno il nuovo File3 contiene un riferimento al blocco a, verr\u00e0 aggiunta la generazione 2 poich\u00e9 la Gen1 \u00e8 gi\u00e0 scaduta. E la data prevista per l'eliminazione del blocco a si sposter\u00e0 all'ottavo giorno. Questo ci consente di ridurre drasticamente il numero di richieste per prolungare la vita dei blocchi deduplicati, risparmiando notevolmente ai clienti.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato nel Capacity Tier da quando Veeam \u00e8 passato alla v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa tecnologia \u00e8 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\u00e9 non sia supportato Azure: hanno una funzionalit\u00e0 simile, ma funziona a livello di contenitori e non di oggetti singoli. A proposito, su Amazon stesso l'object lock \u00e8 disponibile in due modalit\u00e0: compliance e governance. Nel secondo caso, c'\u00e8 la possibilit\u00e0 che l'amministratore supremo possa comunque eliminare i dati nonostante l'object lock. Nel caso di compliance, tutto \u00e8 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\u00e0.<\/p>\n<p>\nE, tradizionalmente, qualche link utile:<\/p>\n<ul>\n<li>Riguardo <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Generazione di Blocchi<\/a><\/noindex> in tutti i dettagli.<\/li>\n<li>Tutte le informazioni su <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> nel miglior modo possibile<\/li>\n<li>maggiore numero di partizioni. <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> nei dettagli<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cosa \u00e8 cambiato nel Capacity Tier quando Veeam \u00e8 diventato v10 | ProHoster","description":"Il Capacity Tier (o come lo chiamiamo noi all'interno di Veeam - kapitir) \u00e8 apparso per la prima volta ai tempi di Veeam Backup and Replication 9.5 Update 4 con il nome di Archive Tier.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster","og:description":"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-10T23:42:41+00:00","article:modified_time":"2020-06-10T23:42:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84809","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:49:54","updated":"2022-09-29 08:38:47","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}