{"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 in Capacity Tier, quando Veeam \u00e8 diventato v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Il Capacity Tier (o come lo chiamiamo internamente \u2014 kapitir) \u00e8 apparso 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 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.<\/p>\n<p>Per eseguire questa semplice (o cos\u00ec 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 \u00e8 definita esplicitamente nell'interfaccia utente. E secondo: la catena deve essere in quello che si chiama formato \u00absigillato\u00bb (sealed backup chain o Inactive Backup Chain). Vale a dire, nel tempo non devono verificarsi cambiamenti in questa catena.<\/p>\n<p>Ma in VBR v10 il concetto \u00e8 stato arricchito con nuove funzionalit\u00e0 \u2014 \u00e8 stato introdotto il Copy Mode, il Sealed Mode e una funzionalit\u00e0 con un nome difficile da pronunciare: Immutability.<\/p>\n<p>Di queste cose interessanti parleremo oggi. Prima di come funzionava in VBR9.5u4, e poi delle modifiche nella decima versione.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE perdonatemi, sostenitori della lingua pura, ma ci sono troppi termini impossibili da tradurre.<br \/>\nQuindi qui ci saranno molti anglicismi.<br \/>\nE molte gif. <br \/>\nE immagini.<\/p>\n<ul>\n<li>Senza il minimo pentimento. L'autore dell'articolo.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Come riportato<\/h1>\n<p>\nAllora, 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\u00e0 possibile spiegare ulteriormente.<\/p>\n<p>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 \u00e8 collegato il Capacity Tier. La nostra finestra di backup operativo dura tre giorni.<\/p>\n<p>Pertanto, il .vbk creato luned\u00ec sigilla la catena precedente, la cui finestra \u00e8 fissata a tre giorni. E, quindi, possiamo tranquillamente iniziare a spostare 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 in Capacity Tier, quando Veeam \u00e8 diventato 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 che 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, ci saranno tutti i rollback e .vbk, se nel performance extent c'\u00e8 un altro .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOra consideriamo un'opzione di lavoro con le catene di Backup Copy. Qui si portava solo ci\u00f2 che rientra 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 in Capacity Tier, quando Veeam \u00e8 diventato 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: 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\u00e0 stati copiati nel capacity tier. <\/p>\n<p>Esaminiamo come appare con un esempio: supponiamo di avere un .vbk che \u00e8 uscito dalla finestra operativa e appartiene a una catena sigillata. Significa che abbiamo piena autorit\u00e0 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, \u00e8 descritto da quali blocchi \u00e8 composto il nostro file. Nella figura, il nostro primo file \u00e8 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\u00e0 link ai due blocchi precedenti e uno nuovo.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDi conseguenza, il processo di riempimento inverso di questi segnaposto con i dati \u00e8 chiamato reidratazione. Qui si utilizza gi\u00e0 il proprio indice di reidratazione, basato sul pi\u00f9 vecchio file .vbk nel performance extent locale. Cio\u00e8, se l'utente vuole recuperare un file dal capacity tier, prima creiamo un indice dei blocchi del backup completo pi\u00f9 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 \u00e8 un oggetto di storage cloud, questo consente di risparmiare enormi somme di denaro.<\/p>\n<p>Qui potrebbe sembrare che questa tecnologia sia identica a quella utilizzata negli acceleratori WAN, ma \u00e8 solo un'apparenza. Negli acceleratori la deduplicazione \u00e8 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato 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! C'\u00e8 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Come \u00e8 stato<\/h1>\n<p>\nCon questa introduzione abbiamo finito. \u00c8 piuttosto dettagliata, ma come detto prima, senza questi dettagli non possiamo spiegare come funzionano le nuove funzionalit\u00e0. Quindi, senza ulteriori preamboli, passiamo al primo argomento.<\/p>\n<h3>Modalit\u00e0 copia<\/h3>\n<p>\nIn gran parte si basa su tecnologie esistenti, tuttavia porta con s\u00e9 una logica d'uso del tutto diversa.\u00a0<\/p>\n<p>L'obiettivo di questa modalit\u00e0 \u00e8 garantire che tutti i dati situati sull'extent locale abbiano una copia nel capacity tier.<\/p>\n<p>Se confrontiamo direttamente le modalit\u00e0 Move e Copy, risulta cos\u00ec:<\/p>\n<ul>\n<li>Puoi spostare solo una catena sigillata. Nel caso della modalit\u00e0 copia, vengono portati via assolutamente tutti, indipendentemente da ci\u00f2 che accade nel lavoro di backup.<\/li>\n<li>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.<\/li>\n<li>Il monitoraggio dei nuovi dati da copiare avviene continuamente, mentre per lo spostamento avveniva ogni 4 ore.<\/li>\n<\/ul>\n<p>\nNella trattazione della nuova modalit\u00e0 propongo di passare da esempi semplici a esempi complessi.<\/p>\n<p>Nel caso pi\u00f9 banale abbiamo semplicemente nuovi file con incrementi, e li copiamo nel capacity tier. Indipendentemente dalla modalit\u00e0 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.<\/p>\n<p>Il processo alla base di questo \u00e8 ancora la disidratazione nella forma descritta sopra. In modalit\u00e0 copia, monitora anche affinch\u00e9 non si copiano blocchi gi\u00e0 presenti nel nostro storage. L'unica differenza \u00e8 che, mentre in modalit\u00e0 spostamento sostituivamo i file reali con file fittizi, qui non li tocchiamo affatto e lasciamo tutto com'\u00e8. Tutto il resto \u00e8 esattamente lo stesso indice di disidratazione, che si impegna a risparmiare i vostri soldi e tempo.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSorge una domanda: se guardiamo nell'interfaccia utente, abbiamo 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 in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIniziamo.<\/p>\n<p>L'inizio \u00e8 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'\u00e8 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\u00e0.<\/p>\n<p>Tutta questa logica affascinante \u00e8 controllata semplicemente da una casella di controllo nell'interfaccia: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>A cosa ci serve questa modalit\u00e0 Copy? <\/h3>\n<p>\n\u00c8 ancora meglio riformulare la domanda in questo modo: quali rischi stiamo proteggendo con essa? Quale problema ci aiuta a risolvere?<\/p>\n<p>La risposta \u00e8 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.<\/p>\n<p>Pertanto, diamo un'occhiata agli scenari possibili, dal pi\u00f9 semplice al pi\u00f9 complesso.<\/p>\n<p>Il pi\u00f9 semplice problema che potrebbe colpirci \u00e8 l'inaccessibilit\u00e0 di uno dei file nella catena di backup.<\/p>\n<p>Una storia pi\u00f9 triste \u00e8 quando uno degli extents del nostro repository SOBR si rompe.<\/p>\n<p>Le cose si fanno ancora pi\u00f9 brutte quando l'intero repository SOBR diventa inaccessibile, ma il tier di capacit\u00e0 \u00e8 operativo.<br \/>\nE tutto va male quando il server di backup muore e il tuo primo desiderio \u00e8 cercare di correre verso il confine canadese in dieci minuti.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOra esaminiamo ogni situazione separatamente.<\/p>\n<p>Quando abbiamo perso uno (ok, anche pi\u00f9 di uno) dei file di backup, basta avviare il processo di riscanalizzazione del repository e il file perso sar\u00e0 sostituito da un file vuoto. Grazie al processo di reidratazione (di cui si \u00e8 parlato all'inizio dell'articolo), l'utente potr\u00e0 scaricare i dati dal capacity tier verso lo storage locale.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOra la situazione si complica. Supponiamo che il nostro SOBR sia composto da due extent, funzionanti 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 una macchina, parte dei cui 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 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\u00ec, se ne parlava anche all'inizio dell'articolo).<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato 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 tal caso, non abbiamo nulla da copiare dagli storage 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 in crash. Qui ci sono due possibilit\u00e0: l'amministratore \u00e8 stato saggio e ha effettuato backup della configurazione, oppure l'amministratore \u00e8 stato un Burattino malvagio e non ha effettuato il backup della configurazione.<\/p>\n<p>Nel primo caso, gli baster\u00e0 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\u00e0 come prima. In alternativa, sar\u00e0 ripristinato secondo uno degli scenari sopra descritti.<\/p>\n<p>Ma se l'amministratore \u00e8 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 \u00e8 la richiesta di inserire una password, se i vostri backup sono stati cifrati.<\/p>\n<p>A questo punto, per quanto riguarda la modalit\u00e0 Copy, diciamo che \u00e8 tutto e passiamo a<\/p>\n<h3>Modalit\u00e0 Sealed<\/h3>\n<p>\nL'idea principale \u00e8 che sul extent selezionato del repository SOBR non possono apparire nuovi backup. Fino alla v10 avevamo solo la modalit\u00e0 Maintenance, in cui era completamente vietato qualsiasi lavoro con il repository. Era una sorta di modalit\u00e0 hardcore per disattivare lo storage, dove era disponibile solo il pulsante Evacuate, che trasferiva i backup su un altro extent.<\/p>\n<p>La modalit\u00e0 Sealed \u00e8 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\u00e0 di ripristinare dai punti memorizzati. \u00c8 molto utile quando ci avviciniamo alla fine della vita dell'hardware e deve essere sostituito, oppure deve semplicemente essere liberato per qualcosa di pi\u00f9 importante, senza avere la possibilit\u00e0 di trasferire tutto in una sola volta. O non si pu\u00f2 eliminare. <\/p>\n<p>Di conseguenza, il principio di funzionamento \u00e8 piuttosto semplice: \u00e8 necessario vietare tutte le operazioni di scrittura (l'emergere di nuovi dati), consentendo solo letture (ripristini) e cancellazioni (retention).<\/p>\n<p>Entrambe le modalit\u00e0 possono essere utilizzate contemporaneamente, ma bisogna considerare che la modalit\u00e0 Maintenance ha una priorit\u00e0 superiore.<\/p>\n<p>Come esempio, consideriamo un SOBR composto da due extents. Supponiamo che nei primi quattro giorni siano stati creati backup in modalit\u00e0 Forward Forever Incremental, e poi sigilliamo l'extent. Ci\u00f2 porta all'innesco della creazione di un nuovo full attivo sul secondo extent disponibile. Se la nostra retention \u00e8 di quattro, quando l'intera catena situata sull'extent sigillato supera i suoi limiti, viene rimossa senza problemi.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCi 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\u00ec decidiamo di sigillare il repository, allora venerd\u00ec, quando verr\u00e0 creato un nuovo backup completo, il file di luned\u00ec sar\u00e0 eliminato poich\u00e9 a questo punto non ci sono dipendenze. E il punto stesso non dipende da nessuno. Dopodich\u00e9 aspettiamo che vengano creati quattro punti sull'estensione disponibile e eliminiamo i restanti tre, che non possono essere eliminati indipendentemente l'uno dall'altro.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa situazione \u00e8 pi\u00f9 semplice con il Reverse Incremental. In questo caso, i punti pi\u00f9 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.<\/p>\n<p>A proposito, perch\u00e9 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\u00e0, impedendone l'eliminazione. Pertanto, \u00e8 stata presa la decisione che non appena l'estensione viene sigillata, creiamo un backup completo su una nuova estensione.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa situazione \u00e8 pi\u00f9 complicata con il capacity tier. <\/p>\n<p>Iniziamo a considerare la modalit\u00e0 copy. Supponiamo di avere creato backup attivamente per quattro giorni e poi il capacity tier \u00e8 stato sigillato. Non eliminiamo nulla, ma attendiamo pazientemente il periodo di retention, dopodich\u00e9 eliminiamo i dati dal capacity tier.<\/p>\n<p>Circa la stessa cosa accade nella modalit\u00e0 move: aspettiamo il periodo di retention, eliminiamo il vecchio nello storage locale, eliminiamo quello presente nell'object storage.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn esempio interessante con Forever forward incremental. Impostiamo il retention a tre punti e iniziamo a creare backup dal luned\u00ec, 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\u00ec, quando il nostro .vbk supera il periodo di retention, e solo allora possiamo eliminare tranquillamente l'intera catena salvata.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE una piccola nota: tutti gli esempi qui mostrati riguardano una sola macchina. Se nel backup ce ne sono pi\u00f9 di una, il retention varier\u00e0 a seconda che sia stato effettuato un Active Full o meno.<\/p>\n<p>In effetti, \u00e8 tutto. Quindi passiamo alla funzione pi\u00f9 hardcore \u2014 <\/p>\n<h3>Immutabilit\u00e0 <\/h3>\n<p>\nCome 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\u00f2 consente di proteggerli da danni accidentali o deliberati. Chi lavora con AWS potrebbe avere incontrato una funzione simile chiamata Object Lock.<\/p>\n<p>Ora esaminiamo il modo di funzionare in generale, per poi approfondire i dettagli. Nel nostro esempio, l'Immutability sar\u00e0 attivato per il nostro capacity tier con un retention di quattro giorni. E nel backup \u00e8 attivata la modalit\u00e0 Copy.<\/p>\n<p>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\u00f2 eliminare i file dei backup. Se si effettua un backup luned\u00ec, si potr\u00e0 eliminare il file solo venerd\u00ec.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato 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 un'unica condizione: il blocco \u00e8 applicato non solo ai dati, ma anche ai metadati. Questo \u00e8 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.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE ora \u00e8 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.<\/p>\n<p>Prendiamo una scala temporale di sei giorni e segnaliamo in basso il tempo di scadenza atteso dell'immutabilit\u00e0. Creiamo il primo giorno un file composto dal blocco a, insieme ai suoi metadati. Se l'immutabilit\u00e0 \u00e8 impostata a tre giorni, \u00e8 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\u00f2 significa che per il blocco a la sua bandiera di immutabilit\u00e0 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\u00e0, \u00e8 necessario effettuare un numero enorme di richieste ogni volta. E, di fatto, sar\u00e0 un processo quotidiano quasi infinito, poich\u00e9 con alta probabilit\u00e0, ogni volta che copiamo, troveremo enormi pacchi di blocchi deduplicati. E cosa significa una grande quantit\u00e0 di richieste dai fornitori di oggetti di archiviazione? Giusto! Una fattura enorme alla fine del mese.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE per non far segnare ai miei amati clienti somme consistenti senza motivo, \u00e8 stato inventato un meccanismo di generazione dei blocchi. Si tratta di un periodo aggiuntivo che aggiungiamo al periodo di immutabilit\u00e0 stabilito. Nell'esempio qui sotto, tale periodo \u00e8 pari a due giorni. Ma questo \u00e8 solo un esempio. In realt\u00e0, si utilizza una propria formula che conferisce circa dieci giorni aggiuntivi per un blocco mensile. <\/p>\n<p>Continuiamo a esaminare la stessa situazione, ma gi\u00e0 con la generazione di blocchi. Creiamo il primo giorno file1 dal blocco a e dai metadati. Sommiamo il periodo di generazione e l'immutabilit\u00e0: ci\u00f2 significa che la possibilit\u00e0 di eliminare il file sar\u00e0 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\u00f2 essere spostata \u00e8 se il periodo di generazione \u00e8 scaduto. Cio\u00e8, se il terzo giorno il nuovo File3 conterr\u00e0 un riferimento al blocco a, verr\u00e0 aggiunta la generazione 2 poich\u00e9 Gen1 \u00e8 gi\u00e0 scaduta. E la data prevista di eliminazione del blocco a si sposter\u00e0 all'ottavo giorno. Ci\u00f2 ci consente di ridurre drasticamente il numero di richieste per il prolungamento della vita dei blocchi deduplicati, risparmiando un sacco di soldi ai clienti.<\/p>\n<p><img decoding=\"async\" alt=\"Cosa \u00e8 cambiato in Capacity Tier, quando Veeam \u00e8 diventato 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 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\u00e9 Azure non sia supportato: hanno una funzionalit\u00e0 simile, ma funziona a livello di contenitori e non di singoli oggetti. A proposito, in 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 pi\u00f9 grande di tutti gli amministratori e il root dei root, nonostante l'object lock, possa comunque eliminare i dati. In caso di compliance, tutto \u00e8 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\u00e0.<\/p>\n<p>\nE, tradizionalmente, alcune link utili:<\/p>\n<ul>\n<li>Su <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> nella migliore forma<\/li>\n<li>O <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.1.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.1.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 internamente in Veeam \u2014 captier) \u00e8 stato introdotto 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}]}}