Capacity Tier (o cum'è a chjamemu in Vim - captir) hè apparsu in i tempi di Veeam Backup and Replication 9.5 Update 4 sottu u nome Archive Tier. L'idea daretu à questu hè di fà pussibule di trasfurmà e copie di salvezza chì sò cascate da a chjamata finestra di restaurazione operativa à u almacenamentu di l'ughjettu. Questu hà aiutatu à sguassà u spaziu di discu per quelli utilizatori chì avianu pocu di questu. E sta opzione hè stata chjamata Move Move.

Per fà sta azione simplice (cum'è pare), bastava à scuntrà duie cundizioni: tutti i punti da a copia di salvezza mossa deve esse fora di e fruntiere di a finestra di restaurazione operativa sopra citata, chì hè stabilitu esplicitamente in l'UI. E siconda: a catena deve esse in a chjamata "forma sigillata" (catena di salvezza sigillata o Inactive Backup Chain). Vale à dì, ùn ci sò micca cambiamenti in questa catena cù u tempu.

Ma in VBR v10, u cuncettu hè stata cumplementata cù e funzioni novi - Modu Copia, Modu Sealed è una cosa cù u nome difficiuli di pronunzia Immutabilità apparsu.

Quessi sò e cose affascinanti chì avemu da parlà oghje. Prima, nantu à cumu hà travagliatu in VBR9.5u4, è dopu nantu à i cambiamenti in a decima versione.

È chì i campioni di a lingua pura mi perdonanu, ma ci sò troppu termini chì ùn ponu esse tradutti.
Allora ci sarà una tonna di anglicismi quì.
È assai gif.
E ritratti.

• Senza u minimu rimpianti. Autore di l'articulu.

Cume era

Ebbè, cuminciamu à analizà a finestra di restaurazione operativa è a copia di salvezza sigillata (o cum'è chjamati in a documentazione di a catena di salvezza inattiva). Senza a so capiscitura, più spiegazione ùn serà micca pussibule.

Cumu vedemu in a stampa, avemu un tipu di catena di salvezza cù blocchi di dati, chì si trova nantu à u Performance tier SOBR di u repository à quale u Capacity Tier hè cunnessu. A nostra finestra di salvezza operativa hè di trè ghjorni.

In cunseguenza, u .vbk creatu u luni sigilla a catena precedente, chì a so finestra hè stallata à trè ghjorni. È questu significa chì pudete inizià in modu sicuru à trasportà tuttu ciò chì hè più vechju di questi trè ghjorni à u campu di tirò.

Ma chì era esattamente significatu da una catena sigillata è chì puderia esse mandatu à a gamma di capacità di tirò in l'aghjurnamentu 4?

Per Forward Incremental, un signu di sigillatura di a catena hè a creazione di una nova copia di salvezza completa. È ùn importa micca quantu hè ottenuta sta copia di salvezza completa: sò cunsiderate sia e copie di salvezza cumplete sintetiche sia attive.

In u casu di Reverse, quessi sò tutti i schedari chì ùn cascà micca in a finestra di u funziunamentu.

In u casu di Forward increment with rollbacks, quessi sò tutti i rollbacks è .vbk, se ci hè un altru .vbk nantu à l'estensione di rendiment.

Avà cunsideremu l'opzione di travaglià cù e catene di copia di salvezza. Solu l'articuli chì cascanu sottu a retenzioni GFS sò stati trasportati quì. Perchè tuttu ciò chì hè guardatu in catene di copia di salvezza più recenti pò esse cambiatu in un modu o un altru.

Avà guardemu sottu à u cappucciu. Ci hè un prucessu chjamatu disidratazione - lascendu i fugliali di salvezza vacanti nantu à l'estensione è trascinendu blocchi da questi schedari à a gamma di capacità di tirò. Per ottimisà stu prucessu, hè utilizatu l'indici di disidratazione chjamatu, chì permette di evità di cupià blocchi chì sò digià copiati à a gamma di capacità di sparazione.

Videmu ciò chì s'assumiglia cù un esempiu: Dicemu chì avemu un .vbk chì hè vinutu da a finestra di a transazzione è appartene à una catena sigillata. Questu significa chì avemu tuttu u dirittu di trasfurmà in u campu di shooting di capacità. À u mumentu di u muvimentu, un schedariu di metadati hè creatu in u dash di capacità è blocchi di u schedariu trasferitu. U schedariu di metadata à livellu di ligame descrive ciò chì blocchi u nostru schedariu hè custituitu. In u casu in a stampa, u nostru primu schedariu hè custituitu di blocchi a, b, c è i metadati cuntenenu ligami à questi blocchi. Quandu avemu un secondu schedariu .vbk, prontu à spustà è custituitu di blocchi a, b è d, noi, analizendu l'indici di desidratazione, capiscenu chì solu u bloccu d deve esse trasferitu. È u so schedariu di metadata cuntene ligami à dui blocchi precedenti è unu novu.

In cunsiquenza, u prucessu di riempie questi spazii vacanti cù dati hè chjamatu reidratazione. Hè digià utilizatu u so propiu indici di reidratazione, basatu annantu à u più anticu schedariu .vbk nantu à l'estensione di u rendiment lucale. Vale à dì, se l'utilizatore vole vultà un schedariu da a gamma di capacità di tirò, prima creamu un indexu di i blocchi di a copia di salvezza completa più antica è trasfirìu solu i blocchi mancanti da a galeria di capacità. In u casu prisentatu in a stampa, per rehydrate FullBackup1.vbk secondu l'indici di reidratazione, avemu solu bisognu di u bloccu C, chì pigliamu da a capacità di sparà. Se un ughjettu di nuvola di almacenamentu serve cum'è una gamma di tirò di capacità, questu permette di salvà enormi quantità di soldi.

Quì pò pare chì sta tecnulugia hè identica à quella utilizata in Accelerators WAN, ma solu pare cusì. In l'acceleratori, a deduplicazione hè globale; quì, a deduplicazione lucale hè aduprata in ogni schedariu à un offset specificu. Stu succèri a causa di a diffarenza in i compiti esse risolta: quì avemu bisognu di cupià grandi schedari di salvezza piena, è sicondu a nostra ricerca, ancu s'è un longu piriudu di tempu passa trà elli, stu algoritmu deduplication dà u megliu risultatu.

Ma più indici per u diu di l'indici ! Ci hè ancu un indice per a ricuperazione di dati! Quandu avemu principiatu à restaurà una macchina situata in u dash di capacità, leghjemu solu blocchi di dati unichi chì ùn sò micca in u dash di rendiment.

Cumu hè accadutu ?

Hè tuttu per a parte introduttiva. Hè abbastanza detallatu, ma cum'è dettu sopra, senza questi dettagli ùn serà micca pussibule di spiegà cumu funziona e funzioni novi. Dunque, senza più disgrazia, andemu à u primu.

Modu di copia

Hè largamente basatu nantu à e tecnulugii esistenti, ma porta una logica di usu completamente diversa. 

U scopu di stu modu hè di assicurà chì tutti i dati situati nantu à l'estensione lucale anu una copia in u trattu di capacità.

Se paragunate i modi Move è Copy head-on, serebbe cusì:

• Solu a catena sigillata pò esse spustata. In u casu di un modu di copia, assolutamente tuttu hè trasferitu, indipendentemente da ciò chì succede in u travagliu di salvezza.
• U muvimentu hè attivatu quandu i schedari vanu oltre i limiti di a finestra di salvezza operativa, è a copia hè attivata appena u schedariu di salvezza appare.
• U monitoraghju di novi dati per a copia hè sempre constantemente, è per u muvimentu hè attivatu una volta ogni 4 ore.

In cunsiderà u novu modu, pruponu di passà da l'esempii simplici à quelli cumplessi.

In u casu più cumuni, avemu solu novi fugliali cù incrementi, è simpricimenti li copiamu à a gamma di capacità di tirò. Indipendentemente da quale modu hè utilizatu in u travagliu di salvezza, a priscinniri di s'ellu appartene à a parte sigillata di a catena o micca, a priscinniri di s'ellu a nostra finestra operativa hè scaduta. L'anu pigliatu solu è l'anu copiatu.

U prucessu daretu à questu hè sempre a desidratazione cum'è descrittu sopra. In u modu di copia, assicura ancu chì ùn copiemu micca blocchi chì sò digià in u nostru almacenamentu. L'unica diferenza hè chì se in u modu di filmu avemu rimpiazzatu i fugliali veri cù i schedarii dummy, quì ùn li toccu micca in ogni modu è lasciate tuttu cum'è. Altrimenti, hè esattamente u listessu indice di desidratazione, chì attentamente prova di salvà u vostru soldi è u tempu.

A quistione sorge - se fighjate à l'UI, ci hè l'uppurtunità di selezziunà e duie opzioni à u stessu tempu. Cumu funziona un modu cumminatu cusì?

Scupremu.

U principiu hè standard: un schedariu di salvezza hè creatu è copiatu immediatamente. Un incrementu hè creatu è ancu copiatu. Questu succede finu à u mumentu quandu avemu capitu chì i schedari anu lasciatu a nostra finestra operativa è una catena sigillata hè apparsa. À questu puntu, facemu una operazione di disidratazione è rimpiazzà questi schedarii cù schedarii manichi. Di sicuru, ùn avemu micca copiatu nunda di novu à a capacità di sparà.

Tuttu sta logica affascinante hè rispunsevule per una sola casella di spunta in l'interfaccia: Copia copia di salvezza in u almacenamentu di l'ughjettu appena sò creati.

Perchè avemu bisognu di stu modu Copia?

Hè ancu megliu di rinfurzà a quistione in questu modu: da chì risichi simu prutetti cù u so aiutu? Chì prublema ci aiuta à risolve ?

A risposta hè ovvia: di sicuru, questu hè a ricuperazione di dati. Se avemu una copia cumpleta di e dati lucali nantu à l'almacenamiento di l'ughjettu, allora ùn importa ciò chì succede à u nostru pruduttu, pudemu sempre restaurà dati da i fugliali situati in l'Amazonia cundizionale.

Allora andemu à traversu i scenarii pussibuli, da u più simplice à u più cumplessu.

A disgrazia più simplice chì pò falà nantu à i nostri capi hè l'inaccessibilità di unu di i schedari in a catena di salvezza.

Una storia più triste hè chì una di e estensioni di u nostru repository SOBR si ruttu.

Hè ancu peghju quandu tuttu u repositoriu SOBR hè diventatu inaccessibile, ma a capacità di sparghjera funziona.
È tuttu hè veramente male - questu hè quandu u servitore di salvezza mori è u vostru primu desideriu hè di pruvà à curriri à a fruntiera canadiana in deci minuti.

Avà guardemu ogni situazione separatamente.

Quandu avemu persu unu (è ancu parechji) fugliali di salvezza, allora tuttu ciò chì avemu da fà hè di inizià u prucessu di rescanu di u repository, è u schedariu persu serà rimpiazzatu cù un schedariu fittiziu. E utilizendu u prucessu di reidratazione (chì hè statu discutitu à l'iniziu di l'articulu), l'utilizatore puderà scaricà e dati da a capacità di sparghjera à l'almacenamiento lucale.

Avà a situazione hè più cumplicata. Assumimu chì u nostru SOBR hè custituitu di dui estensioni in u modu Performance, chì significa chì i nostri .vbk è .vib sò spargugliati nantu à elli in una strata piuttostu irregulare. È in un certu puntu in u tempu, una di e estensioni diventa indisponibile, è l'utilizatore hà bisognu urgente di restaurà a macchina, una parte di e dati di quale si trova precisamente nantu à questa misura.

L'utilizatore lancia l'assistente di ricuperazione, selezziunà u puntu à quale ellu vole restaurà, è l'assistente, mentre travaglia, vene à a realizazione chì ùn hà micca tutti i dati necessarii per a ricuperazione in u locu è per quessa deve esse scaricatu da a capacità di shooting. galerie. À u listessu tempu, i blocchi chì restanu in u almacenamentu locale ùn saranu micca scaricati da u nuvulu. Gloria à l'indici di restaurazione (iè, hè statu ancu mintuatu à u principiu di l'articulu).

Un subtipu di stu casu hè chì tuttu u repositoriu SOBR hè diventatu inaccessibile. In questu casu, ùn avemu nunda di cupià da u almacenamentu locale, è tutti i blocchi sò scaricati da u nuvulu.

È a situazione più interessante hè chì u servitore di salvezza hè mortu. Ci hè duie opzioni quì: l'amministratore hè grande è hà fattu una copia di salvezza di cunfigurazione, è l'amministratore hè un Pinocchiu cattivu stessu è ùn hà micca fattu backups di cunfigurazione.

In u primu casu, serà abbastanza per ellu solu implementà una stallazione pulita di VBR in qualchì locu è restaurà a so basa di dati da una copia di salvezza cù i mezi standard. À a fine di stu prucessu, tuttu tornerà à u normale. O serà restauratu secondu unu di i scenarii sopra.

Ma s'è l'admin hè o u so nemicu, o a copia di salvezza di cunfigurazione hà ancu patitu un fallimentu epicu, allora ancu quì ùn l'abbanduneremu micca à a misericòrdia di u destinu. Per questu casu, avemu introduttu una nova prucedura chjamata Import Object Storage. Permette di saltà u prucessu di ricreà manualmente un repository SOBR è attaccà un intervallu di capacità di tirò cù una successiva scansione, è simpricimenti aghjunghje un oggettu di almacenamiento à l'interfaccia di Vim è eseguisce a prucedura di Repository d'Importazione. L'unicu ciò chì pò esse in u modu trà voi è i vostri backups hè una dumanda per inserisce una password se i vostri backups sò stati criptati.

Questu hè probabilmente tuttu nantu à u Modu di Copia è andemu à

Modu sigillatu

L'idea principale hè chì e novi copie di salvezza ùn ponu micca appare nantu à l'estensione SOBR selezziunata di u repository. Prima di v10, avemu avutu solu u Modu di Mantenimentu, quandu ogni travagliu cù u repositoriu era completamente pruibitu. Una spezia di modalità hardcore per chjude l'almacenamiento, induve solu u buttone Evacuate hè dispunibule, chì trasporta backups in un altru puntu una volta.

È u modu Sealed hè una spezia di opzione "soft": pruibitemu a creazione di novi backups è sguassate gradualmente i vechji secondu a retenzione selezziunata, ma in u prucessu ùn perdemu a capacità di restaurà da i punti almacenati. Una cosa assai utile quandu avemu un pezzu di hardware vicinu à a fine di a so vita è avemu bisognu di rimpiazzà, o avemu solu bisognu di liberà per qualcosa di più impurtante, ma ùn ci hè nunda per piglià è spustà tuttu in una volta. O ùn pò esse sguassatu.

In cunsiquenza, u principiu di u funziunamentu hè abbastanza sèmplice: hè necessariu di pruibisce tutte l'operazioni di scrittura (apparizione di novi dati), lascendu leghje (restaurazioni) è sguassà (retention).

I dui modi ponu esse aduprati simultaneamente, ma tenite in mente chì u Mantenimentu hà una priorità più alta.

Per esempiu, cunzidira un SOBR custituitu di dui estensioni. Assumimu chì per i primi quattru ghjorni avemu creatu copia di salvezza in u modu Forward Forever Incremental, è poi sigillamu l'estensione. Questu porta à u fattu chì avemu principiatu a creazione di un novu attivu pienu nantu à a seconda estensione dispunibule. Se a nostra retenzioni hè quattru, allora quandu tutta a catena situata nantu à l'estensione sigillata supera i so limiti, hè sguassata cù una cuscenza limpida.

Ci sò situazioni quandu a cancellazione si faci prima. Per esempiu, questu hè Forward incremental with periodic fulls. Se avemu creatu backups cumpleti per i primi dui ghjorni, è u ghjovi decidemu di sigillà u repository, dopu u venneri, quandu una nova copia di salvezza hè creata, u schedariu per u luni serà sguassatu perchè ùn ci sò micca dipendenze à questu puntu. È u puntu stessu ùn dipende micca di nimu. Allora aspittemu finu à chì quattru punti sò creati nantu à l'estensione dispunibule è sguassate i trè restanti, chì ùn ponu esse eliminati indipindentamente l'un l'altru.

E cose sò più simplici cù Reverse Incremental. In questu, i punti più antichi ùn dependenu micca di nunda è ponu esse eliminati in modu sicuru. Dunque, appena un novu .vbk hè creatu nantu à una nova misura, i vechji .vrbs seranu sguassati unu per unu.

In modu, perchè avemu crià un novu .vbk ogni volta: se ùn l'avemu micca creatu, ma cuntinuò a vechja catena di incrementi, allura u vechju .vbk si congelava per un tempu infinitu longu in ogni modu, impediscendu a so eliminazione. Per quessa, hè statu decisu chì appena l'estensione hè sigillata, creamu una copia di salvezza completa nantu à l'estensione libera.

E cose sò più complicate cù a gamma di tirò di capacità.

Prima, fighjemu u modu di copia. Assumimu chì avemu criatu attivamente copia di salvezza per quattru ghjorni, è dopu a capacità di tiru hè stata sigillata. Ùn sguassate micca nunda, ma umilmente suppurtà a retenzioni, dopu chì sguassate i dati da a gamma di capacità di tirò.

Approssimativamente a listessa cosa succede in u modu di muvimentu - aspittemu u ritoccu, sguassate u vechju in u almacenamentu lucale, è sguassate quellu almacenatu in u almacenamentu di l'ughjettu.

Un esempiu interessante cù Forever forward incremental. Installemu a retenzioni in trè punti è cuminciamu à fà backups u luni, chì sò regularmente copiati in u nuvulu. Dopu à u sigillu di l'almacenamiento, i backups cuntinueghjanu à esse creati, mantenendu trè punti, ma i dati guardati in a capacità dash restanu dipendente è ùn ponu micca esse eliminati. Dunque, aspittemu finu à u ghjovi, quandu u nostru .vbk va oltre a retenzioni, è solu allora sguassate tranquillamente tutta a catena salvata.

È una piccula disclaimer: tutti l'esempii quì sò mostrati cù una macchina. Sè vo avete parechji di elli in a vostra copia di salvezza, allura u so retouch sarà differente sicondu s'ellu Active Full hè statu fattu o micca.

Hè basicamente tuttu ciò chì ci hè. Allora andemu à a funzione più hardcore -

Immutabilità

Cum'è cù i punti precedenti, a prima cosa hè chì prublema sta funzione risolve. Appena caricate e nostre copie di salvezza in un locu per u almacenamentu, ci hè un forte desideriu di guarantiscenu a so sicurità, vale à dì, di pruibisce fisicamente a so eliminazione è qualsiasi mudificazione durante una data ritenzione. Cumpresu l'amministratori, ancu sottu à i so cunti radichi. Questu permette di prutezzione di i danni accidentali o intenzionale. Qualchese chì travaglia cù AWS pò avè scontru una funzione simili chjamata Object Lock.

Avà fighjemu u modu in termini ginirali, è poi sfondate in i dettagli. In u nostru esempiu, l'immutabilità serà attivata per a nostra capacità di tirò cù una retenzioni di quattru ghjorni. È u modu Copia hè attivatu in a copia di salvezza.

L'immutabilità ùn interagisce micca cù a retenzioni generale in ogni modu. Per esempiu, ùn aghjunghje micca punti extra o qualcosa cusì. Hè solu chì una persona ùn pò micca sguassà i schedari di salvezza in quattru ghjorni. Se fate una copia di salvezza u luni, solu puderà sguassà u so schedariu u venneri.

Tutti i cuncetti spiegati prima di disidratazione, indici è metadata cuntinueghjanu à travaglià esattamente u listessu. Ma cù una cundizione - u bloccu hè stallatu micca solu per i dati, ma ancu per i metadata. Questu hè fattu in casu chì un astutu attaccu decide di sguassà a nostra basa di dati di metadati è di impedisce chì i blocchi di dati si trasformanu in mush binariu inutile.

Avà hè un bellu tempu per spiegà a nostra tecnulugia di generazione di blocchi. O generazione di blocchi. Per fà questu, cunzidira a situazione chì hà purtatu à a so apparizione.

Pigliemu una scala di tempu di sei ghjorni è quì sottu marcaremu u tempu di a scadenza prevista di l'immutabilità. U primu ghjornu avemu pigliatu è creà un schedariu custituitu di data block a è i so metadata. Se l'immutabilità hè stabilita à trè ghjorni, hè logicu per assume chì u quartu ghjornu i dati seranu sbloccati è sguassati. U sicondu ghjornu aghjunghjemu un novu file2, custituitu di bloccu b cù i stessi paràmetri. U bloccu un deve esse eliminatu u quartu ghjornu. Ma u terzu ghjornu succede qualcosa terribili - un schedariu File3 hè creatu, custituitu da un novu bloccu d è un ligame à u vechju bloccu a. Questu significa chì per un bloccu è a so bandiera immutabilità deve esse resettata à una nova data, chì hè spustata à u sestu ghjornu. È quì hè un prublema - in i veri backups ci sò un gran numaru di tali blocchi. È per allargà u so periodu di immutabilità, avete bisognu di fà un gran numaru di dumande ogni volta. È in fattu, questu serà un prucessu di ogni ghjornu quasi infinitu, postu chì cù un altu gradu di probabilità truvemu pile pesanti di blocchi deduplicati cù ogni copia. Chì significanu un gran numaru di dumande da i fornitori di almacenamentu d'ughjettu ? Diritta! Una fattura enorme à a fine di u mese.

È per ùn esce da u turchinu i vostri clienti preferiti per soldi sustinibili, u mecanismu di generazione di blocchi hè statu inventatu. Questu hè un periodu supplementu chì aghjunghje à u periodu di immutabilità stabilitu. In l'esempiu sottu, stu periodu hè di dui ghjorni. Ma questu hè solu un esempiu. In realtà, usanu a so propria formula, chì dà circa deci ghjorni supplementari durante una serratura mensuale.

Continuemu à cunsiderà a stessa situazione, ma cù a generazione di blocchi. U primu ghjornu avemu creatu file1 da u bloccu a è metadata. Aghjunghjemu u periodu di generazione è l'immutabilità - questu significa chì l'uppurtunità di sguassà u schedariu serà u sestu ghjornu. Se u sicondu ghjornu avemu creatu File2, custituitu da u bloccu b è un ligame per bluccà a, ùn succede nunda à a data di eliminazione prevista. Idda stava cum'è hà fattu u sestu ghjornu. È cusì avemu pruvatu à salvà soldi nantu à u numeru di richieste. L'unica situazione quandu u termini pò esse spustatu hè se u periodu di generazione hè scadutu. Questu hè, se u terzu ghjornu u novu File3 cuntene un ligame per bluccà a, allora a generazione 2 serà aghjunta postu chì Gen1 hà digià scadutu. È a data prevista per a cancellazione di u bloccu a cambiarà à l'ottu ghjornu. Questu ci permette di riduce dramaticamente u nùmeru di richieste per allargà a vita di i blocchi deduplicati, chì risparmia i clienti una tonna di soldi.

A tecnulugia stessu hè dispunibule per l'utilizatori di hardware S3 è S3-compatibile, chì i pruduttori guarantiscenu chì a so implementazione ùn hè micca diffirenti da Amazon. Da quì a risposta à a quistione legittima perchè Azure ùn hè micca supportatu - anu una funzione simili, ma travaglia à u livellu di cuntenituri, micca ogetti individuali. Per via, Amazon stessu hà u bloccu di l'ughjettu in dui modi: rispettu è guvernanza. In u sicondu casu, ci ferma a pussibilità chì u più grande admin sopra admins è root above roots, malgradu a serratura di l'ughjettu, sempre sguassate i dati. In u casu di rispettu, tuttu hè inchiodatu strettu è nimu pò sguassà e copia di salvezza. Ancu l'amministratori di Amazon (sicondu i so dichjarazioni ufficiali). Questu hè u modu chì sustenemu.

È, cum'è di solitu, alcuni ligami utili:

• nantu Generazione di blocchi in ogni dettu.
• Tutte l'infurmazioni nantu à Veeam Backup & Replication 10 à u so megliu
• О Livellu di capacità in dettu

Source: www.habr.com