Capacity Tier (või nagu me seda oma sees nimetame — kaptir) ilmus juba Veeam Backup and Replication 9.5 Update 4 ajal nimega Archive Tier. Selle idee on anda võimalus liikuda varukoopiatele, mis on jäänud välja nii nimetatud operatiivse taastamise aknast, objektivaramudesse. See aitas vabastada kettaruumi kasutajatele, kellel seda oli vähe. Ning seda valikut nimetatakse Move Mode.

Selle lihtsa (kui nii saab öelda) tegevuse teostamiseks tuli järgida kahte tingimust: kõik punktid liigutatavast varukoopiast peavad jääma välja nimetatud operatiivse taastamise aknast, mis on määratud selgelt kasutajaliideses. Ja teine: ahel peab olema nii nimetatud 'pitseeritud kujul' (sealed backup chain või Inactive Backup Chain). See tähendab, et aja jooksul ei toimu selle ahela muutusi.

Kuid VBR v10 kontseptsioon on rikastunud uute funktsioonidega — ilmus Copy Mode, Sealed Mode ja keeruliselt hääldatav omadus Immutability.

Just nendest põnevustest me täna räägime. Esiteks, kuidas see töötas VBR9.5u4-s, ja siis kümnenda versiooni muudatustest.

Ja olgu mind andestatud puhta keele toetajate poolt, kuid liiga palju termineid ei ole võimalik tõlkida.
Nii et siin on palju anglicisme.
Ja palju gif'e.
Ja pilte.

Ilma vähimagi kahetsuseta. Artikli autor.

Kuidas oli

Noh, alustame operatiivse taastamise akna ja pitsitatud varukoopia (või kuidas neid dokumentatsioonis nimetatakse Inactive Backup Chain) analüüsiga. Ilma nende mõistmiseta ei saa edasist selgitada.

Nagu näeme pildilt, on meil mingi varukoopia ahel andmeplokkidega, mis asub Performance tier SOBR hoidlas, millele on ühendatud Capacity Tier. Meie operatiivse varukoopia akna pikkus on kolm päeva.

Seega, esmaspäeval loodud .vbk pitsitab eelneva ahela, mille aken on määratud kolmeks päevaks. Ja seega võib rahulikult alustada kõike, mis on vanem kui need kolm päeva, üleviimist kapasitati tier'i.

Aga mida täpselt mõeldi pitsitatud ahela all ja mis võis Update 4-s Capacity Tier'i minna?

Eesmine Incremental puhul on pitsitamise märgiks uue täis varukoopia loomine. Ja ei ole oluline, kuidas see täis varukoopia saadakse: loetakse nii sünteetilised täis- kui ka aktiivsed täis varukoopiad.

Tagurpidi on kõik failid, mis jäävad välja operatiivse akna.

Forward increment'i puhul koos rullimistamiseks, on kõik rullimist piirid ja .vbk, kui perforeerimise ulatuses on veel üks .vbk.

Nüüd vaatame varukoopia ahelate töövarianti. Siin viidi ära ainult GFS hoidmise alla kuuluv. Sest kõik, mis on uuemates backup copy ahelates, võib olla mingil viisil muudetud.

Nüüd vaatame, mis toimub kapoti all. Seal toimub protsess, mida nimetatakse dehüpraatideks — tühjade varufailide jätmine ulatusesse ja plokkide tõstmine nendest failidest mahtude aega. Selle protsessi optimeerimiseks kasutatakse nn dehüpraatide indeksit, mis võimaldab mitte kopeerida plokke, mis on juba mahu tingimusse kopeeritud.

Vaatame, kuidas see näeb välja näite põhjal: oletame, et meil on .vbk, mis on välja läinud operatiivaknast ja kuulub suletud ahelasse. See tähendab, et meil on täielik õigus seda mahtude aega kanda. Üleviimise hetkedel luuakse mahtude ajal metaandmefail ja üle kantud faili plokid. Metaandmefaili linkide tasandil kirjeldatakse, millistest plokkidest meie fail koosneb. Pildil on meie esime fail koondunud plokkidest a, b, c ja metaandmetes on lingid nendele plokkidele. Kui meil on teisene .vbk fail, mis on valmis üleviimiseks ja koosneb plokkidest a, b ja d, mõistame, analüüsides dehüpraati indeksi, et peame üle viima ainult ploki d. Ja selle metaandmefail sisaldab linke kahe varasema ploki ja ühe uue kohta.

Seega, nende tühikute täitmise protsessi nimetatakse regidratatsiooniks. Siin kasutatakse juba oma regidratatsiooni indeksit, mis põhineb kõige vanemal .vbk failil kohalikes perforeerimise ulatustes. See tähendab, et kui kasutaja soovib faili tagasi tuua mahtude ajast, loome esmalt kõige vanema täieliku varukoopia plokkide indeksi ja kanname mahtude ajast tagasi ainult puuduvad plokid. Näidatud olukorras, et regidreerida FullBackup1.vbk vastavalt regidratatsiooni indeksi nõudmistele, on meil puudu ainult plokk C, mille me kanname mahtude ajast. Kui mahtude ajaks on pilve objektide salvestus, võimaldab see säästa tohutult raha.

Siin võib tunduda, et see tehnoloogia sarnaneb WAN kiirendites kasutatavale, kuid see on vaid näilisus. Kiirendites toimub globaale deduplikatsioon, siinkohal kasutatakse kohaliku deduplikatsiooni mehhanismi iga faili teatud offseti ulatuses. See tuleneb lahendatavate probleemide erinevusest: siin peame kopeerima suuri täisvarukoopia faile ja meie uuringute kohaselt annab selline deduplikatsioonine algoritm parima tulemuse, isegi kui nende vahel on suur ajavahemik.

Aga rohkem indekseid jumalate indekseid! On veel andmete taastamise indeks! Kui käivitame masina taastamise, mis asub kapasititeeditarustuses, loeme ainult unikaalseid andmeplokke, mida ei ole jõudluse tarus.

Kuidas on muutunud

Sissejuhatava osa osas on kõik. See on üsna põhjalik, kuid nagu eespool mainitud, ei saa me ilma nende detailideta selgitada, kuidas uued funktsioonid töötavad. Seega liigume ilma ülearuste sissejuhatusteta esimesele teemale.

Kopeerimisrežiim

Põhimõtteliselt põhineb see olemasolevatel tehnoloogiatel, kuid toob kaasa täiesti teistsuguse kasutusloogika.

Selle režiimi eesmärk on tagada, et kõik andmed, mis asuvad kohalikul ulatusel, omavad koopiaid kapasititeeditarust.

Kui võrrelda otseselt Liikumis- ja Kopeerimisrežiime, siis tulemused on järgmised:

Liikuda saab ainult pitseeritud ahelaga. Kopeerimisrežiimis viiakse üle kõik, sõltumata sellest, mis toimub varukoopia töös.
Liikumine aktiveerub siis, kui failid ületavad varukoopiate operatiivakna piire, samas kui kopeerimine aktiveerub kohe, kui varukoopia fail ilmub.
Uute andmete jälgimine kopeerimiseks toimub pidevalt, samas kui liikumine toimib iga 4 tunni järel.

Uue režiimi arutamisel soovitan liikuda alates lihtsatest näidetest keerukamate suunas.

Kõige lihtsamas variandis ilmnevad meil lihtsalt uued failid koos inkremendiga ja me kopeerime need kapasititeeditarusse. Olenemata sellest, millist režiimi kasutatakse varukoopia töös, olenemata sellest, kas see kuulub pitseeritud osa ahelasse või mitte, olenemata sellest, kas meie operatiivaken on möödunud. Lihtsalt võtame ja kopeerime.

Protsess, mis sellega kaasneb, on endiselt dehüdreerimine, nagu eelnevalt kirjeldatud. Kopeerimisrežiimis jälgib ta ka, et me ei kopeeriks bloke, mis juba meie objektide salvestuses on. Ainus erinevus on see, et kui liikumisrežiimis asendasime reaalsed failid tühjade failidega, siis siin me neid üldse ei puutu ja jätame kõik nii, nagu on. Ülejäänud on just selline dehüdreerimise indeks, mis püüab hoolikalt säästa teie raha ja aega.

Küsimus on — kui vaadata kasutajaliidest (UI), siis seal on võimalus valida mõlemat valikut korraga. Kuidas selline kombineeritud režiim töötab?

Hakkame mõtlema.

Standard algus: luuakse varukoopia fail ja see kopeeritakse kohe. Sellele luuakse inkrement ja see kopeeritakse samuti. Nii toimub kuni hetkeni, mil me mõistame, et failid on välja tulnud meie tegevusaknast ja on tekkinud suletud ahel. Sel hetkel teostame dehüdreerimise operatsiooni ja asendame selle failid tühjadega. Loomulikult ei kopeeri me uuesti kapatsitiirele midagi.

Kogu selle põneva loogika taga on vaid üks linnuke liideses: Kopeeri varukoopiad objektide salvestusse kohe pärast nende loomist.

Aga miks me seda Kopeerimise režiimi vajame?

Isegi paremini oleks küsida: milliste riskide eest me end selle abil kaitseme? Millist probleemi ta aitab meil lahendada?

Vastus on ilmne: muidugi, see on andmete taastamine. Kui meil on objektide salvestuses täielik koopia kohalikest andmetest, siis pole oluline, mis meie tootmises juhtub, me saame alati andmed taastada failidest, mis asuvad tingimuslikult Amazoni serveris.

Seega, las käime läbi võimalikud stsenaariumid, alates kõige lihtsamast kuni keerukamate juurde.

Lihtsaim mure, mis meie pea kohale võib langeda, on ühe faili kättesaamatus varukoopiate ahelas.

Karmim lugu on see, et üks meie SOBR-repositooriumi ekstrektidest on katki.

Isegi hullem on see, kui kogu SOBR-repositoorium on kättesaamatu, kuid kapatsitiir töötab.
Ja olukord on täiesti halb, kui varukoopia server sureb ja sinu esimene soov on proovida kümne minuti jooksul kanada piiri joosta.

Nüüd vaatame iga olukorda eraldi.

Kui me kaotasime ühe (jah, isegi mitu) varukoopiat, siis piisab, kui käivitada repositooriumi skaneerimise protsess, ja kadunud fail asendatakse tühja failiga. Ja taaskasutamise protsessi abil (mille kohta räägiti artikli alguses) saab kasutaja alla laadida andmed mahutustasandilt kohalikku salvestusse.

Nüüd on olukord keerulisem. Oletame, et meie SOBR koosneb kahest ekstensioonist, mis töötavad jõudluse režiimis, seega on meie .vbk ja .vib nende vahel üsna ebatasaselt jaotatud. Ja mingil hetkel muutub üks ekstensioon kättesaamatuks, kuid kasutaja peab kiiresti taastama masina, mille osad andmed asuvad just selles ekstensioonis.

Kasutaja käivitab taastamisviisardi, valib punkt, kuhu soovib taastada, ja viisard töö käigus mõistab, et tal ei ole vajalikku taastamiseks vajalikku andmeid kohalikult ning seetõttu tuleb need alla laadida mahutustasandilt. Samuti ei laadi pilvest alla blokid, mis on jäänud kohalikku salvestusse. Tänu taastamise indeksile (jah, ka sellest räägiti artikli alguses).

Selle juhtumi alaliik – kogu SOBR repositoorium on muutunud kättesaamatuks. Sellisel juhul ei ole meil midagi kopeerida kohalikest salvestustest ja kõik blokid laevad pilvest alla.

Ja kõige huvitavam olukord – varundusserver on läbi. Siin on kaks varianti: admin on tubli ja tegi konfiguratsiooni varukoopiaid, või admin on ise endale kuri Buratino ja ei teinud konfiguratsiooni varukoopiat.

Esimesel juhul piisab lihtsalt puhta VBR installatsiooni kuskil üles seadmisest ja tema andmebaasi taastamisest varukoopiast tavapäraste vahenditega. Selle protsessi lõpuks naaseb kõik oma kohale. Või taastatakse see ühe eelneva stsenaariumi kohaselt.

Kuid kui administraator on endale ise vaenlane või on varukoopia konfiguratsioon kaotanud kaasaegse ebaõnne, siis isegi siin me ei jäta teda saatuse hooleks. Selle juhtumi jaoks oleme käivitanud uue protseduuri nimega Import Object Storage. See võimaldab vältida käsitsi SOPR-i reposiitri taastamise protsessi ning selle mahtütleva kapi ühendamist, vaid lihtsalt lisada objektide salvestuse liideses ja käivitada Import Storage Repository protseduur. Ainus, mis võib teie ja teie varukoopiate vahel teele seista, on palve sisestada parool, kui teie varukoopiad on krüpteeritud.

Sellega Copy Mode kohta on kõik ja liigume edasi

Sealed Mode

Põhjus on selles, et valitud SOBR reposiitri ulatuses ei saa ilmneda uusi varukoopiaid. Kuni v10-ni oli meil ainult hooldusrežiim, kus igasugune töö reposiitariga oli täielikult keelatud. See oli selline karm režiim, kus oli saadaval ainult Evacuate nupp, mis korduvasti tõi varukoopiad teise ulatusse.

Sealed mode on omamoodi "pehme" variant: keeldume uute varukoopiate loomisel ja järk-järgult kustutame vanu vastavalt valitud säilitamisele, kuid protsessis ei kaota me võimalust taastuda salvestatud punktidest. Väga kasulik asi, kui meie seadme eluiga on lõppemas ja seda tuleb asendada, või tuleb lihtsalt midagi olulisemat selle jaoks vabastada, samas ei ole võimalik kõike korraga üle tuua. Või ei saa kustutada.

Seega tööpõhimõte on üsna lihtne: tuleb keelata kõik kirjutamisoperatsioonid (uudsete andmete ilmumine), jättes lugemis- (taastused) ja kustutamis- (säilitamine) tegevused.

Mõlemat režiimi saab kasutada samaaegselt, kuid tuleb arvestada, et hoolduse prioriteet on kõrgem.

Näitena vaatame SOBR-i, mis koosneb kahest ulatusest. Oletame, et esimestel neljal päeval loodi varukoopiad Forward Forever Incremental režiimis, ja siis me pitseerime ulatuse. See viib selleni, et me käivitame uue aktiivse täisloomise loomise teises kättesaadavas ulatuses. Kui meie säilitamine on neli, siis kui kogu kett, mis asub pitseeritud ulatuses, ületab selle piire, saab see rahuliku südamega kustutada.

On olemas olukordi, kus kustutamine toimub varem. Näiteks, see on Forward incremental koos perioodiliste full backup'idega. Kui esimesed kaks päeva oli meil tehtud full backup'id, ja neljapäeval otsustame reposiiti pitseerida, siis reede hommikul, kui luuakse uus full backup, eemaldatakse esmaspäeva fail, kuna sellel punktidel ei ole sõltuvusi. Ja see punkt iseenesest ei sõltu kelleltki. Pärast seda ootame, kuni tehakse neli punkti saadaval oleval ulatusel ja kustutame kolm ülejäänud, mis ei saa üksteisest sõltumatult eemaldatud olla.

Reverse Incrementali korral on asjad lihtsamad. Seal ei sõltu vanimad punktid kellestki ja need saab rahulikult eemaldada. Seetõttu, kui uus .vbk luuakse uuel ulatusel, vanad .vrb eemaldatakse ükshaaval.

Muide, miks me iga kord uue .vbk loome: kui seda ei tehta ja jätkatakse vana inkrementide jada, siis vana .vbk jääks igavesti rippuma, takistades selle kustutamist. Seetõttu on otsustatud, et kohe kui ulatus pitseeritakse, loome uue full backup'i vabale ulatusele.

Asjad on keerulisemad kapasitatiivse tihedusega.

Esmalt vaatame copy režiimi. Oletame, et nelja päeva jooksul loodi aktiivselt varukoopiaid, ja siis pitseeriti kapasitatiivne tihedus. Me ei kustuta midagi, vaid kannatlikult kannatame säilitamise aja, mille järel kustutame andmed kapasitatiivse tihedusega.

Põhimõtteliselt toimub sama ka move režiimis — ootame säilitamise aega, kustutame vana kohalikus ladustamises, ja kustutame objektide salvestuses hoitava.

Huvitav näide Forever forward incremental'i kohta. Seame säilitamise ajaks kolm punkti ja hakkame esmaspäevast alustama varukoopiaid, mis kopeeritakse usinalt pilve. Pärast ladustamise pitseerimist jätkub varukoopiate loomine, säilitades kolm punkti, kuid kapasitatiivse tiheduse andmed jäävad sõltuvaks ja ei saa kustutada. Seetõttu ootame neljapäeva, kui meie .vbk jääb säilitamise ajast välja, ja alles siis kustutame kogu salvestatud jada rahulikult.

Ja väike täpsustus: kõik siin toodud näited puudutavad ühte masinat. Kui teil on varukoopias mitu, siis nende säilitamine võib erineda sõltuvalt sellest, kas on tehtud Active Full või mitte.

Peale seda ongi kõik. Nii et liigume edasi kõige karmima funktsiooni juurde —

Immutability

Nagu ka eelnevate punktide puhul, räägime esmalt sellest, millist probleemi see funktsioon lahendab. Niipea, kui salvestame oma varukoopiad kuhugi, tekib suur soov tagada nende säilimine, see tähendab füüsiliselt keelata nende kustutamine ja igasugused muudatused määratud retentsiooniperioodi jooksul. See kehtib ka administraatorite ja nende juurkontode puhul. See kaitseb varukoopiaid juhusliku või tahtliku kahjustamise eest. Need, kes töötavad AWS-iga, on võinud kohtuda sellise funktsiooniga nimega Object Lock.

Nüüd vaatame režiimi üldiselt ja seejärel süveneme detailidesse. Meie näites on Immutability aktiveeritud meie mahutite jaoks, mille retentsiooniperiood on neli päeva. Varukoopias on aktiveeritud Copy režiim.

Immutability ei mõjuta üldist retentsiooniperioodi. Näiteks ei lisa see lisapunkte ega midagi sellist. Lihtsalt nelja päeva jooksul ei saa inimene varukoopia faile kustutada. Kui esmaspäeval varukoopia teha, saab selle faili kustutada ainult reedel.

Kõik varem selgitatud dehüdratsiooni, indeksite ja metaandmete kontseptsioonid töötavad täpselt samamoodi. Kuid ühe tingimuse täitmisega — blokk kehtestatakse mitte ainult andmete, vaid ka metaandmete osas. See on tehtud selleks, et olukordades, kus kurjategija proovib meie metaandmebaasi kustutada, ei muutuks andmeblokkides olevad andmed kasutu binaarseks segaduseks.

Ja nüüd on suurepärane aeg selgitada meie plokkide genereerimise tehnoloogiat. Või block generation. Selleks vaatame olukorda, mis viis selle tekkimiseni.

Võtame ajaskaala kuue päeva jooksul ja tähistame allpool oodatud immutability lõppemise aega. Loome esimesel päeval faili, mis koosneb plokist a ja selle metaandmetest. Kui immutability on seadistatud kolme päeva jooksul, on loogiline eeldada, et neljandal päeval andmed avatakse ja kustutatakse. Teisel päeval lisame uue file2, mis koosneb plokist b samade seadistustega. Plokk a peab endiselt olema kustutatud neljandal päeval. Kuid kolmandal päeval juhtub õuduste aeg — luuakse fail File3, mis koosneb uuest plokist d ja lingist vana ploki a peale. See tähendab, et ploki a immutability lipp peab olema uuesti seatud uue tähtaja jaoks, mis nihkub kuuendale päevale. Siin tekib probleem — tegelikes varukoopiate plokkides tekib tohutu hulk. Ja kuna immutability perioodi pikendamiseks tuleb iga kord teha tohutu hulk päringuid, kujuneb tegelikult välja peaaegu lõpmatu igapäevane protsess, kuna suure tõenäosusega leiame iga kopeerimise korral suured kuhjad deduplica kohta. Ja mis tähendab suur hulk päringute korral objektide salvestuspakkujate juures? Õige! Suur arve kuu lõpuks.

Ja et mitte oma armastatud kliente suure raha eest tühja kohta jätta, loodi block generation mehhanism. See on lisaperiood, mida me lisame seatud immutability perioodile. Allolevas näites on see periood kaks päeva. Kuid see on ainult näide. Tegelikult kasutatakse seal oma valemit, mis annab umbes kümme täiendavat päeva kuu lukustamise puhul.

Jätkame sama olukorra vaatlemist, kuid juba block generation'i kontekstis. Looma esimesel päeval file1 plokist a ja metaandmetest. Koondame genereerimisperioodi ja immutability — see tähendab, et faili kustutamise võimalus on kuuendal päeval. Kui teisel päeval loome File2, mis koosneb plokist b ja lingist plokile a, siis oodatav kustutamise kuupäev ei muutu. See jääb kuuendaks päevaks. Ja me üritame säästa raha päringute arvu pealt. Ainus olukord, kus tähtaega saab nihutada, on siis, kui genereerimisperiood on lõppenud. See tähendab, et kui kolmandal päeval uus File3 sisaldab linki plokile a, siis lisandub genereerimine 2, kuna Gen1 on juba lõppenud. Oodatav ploki a kustutamise kuupäev nihkub kaheksandale päevale. See võimaldab meil dramaatiliselt vähendada päringute arvu deduplicaeritud plokkide eluea pikendamiseks, mis säästab kliente tohutult raha.

Tehnoloogia on saadaval S3 ja S3 ühilduvate seadmete kasutajatele, mille tootjad garantii, et nende rakendus ei erine Amazoni omast. Seega on vastus seaduslikule küsimusele, miks Azure't ei toetata — neil on sarnane funktsioon, kuid see töötab konteinerite tasemel, mitte eraldi objektide tasemel. Muide, Amazoni enda obkject lock on kahes režiimis: compliance ja governance. Teises režiimis jääb võimalus, et suurim administraator, kes on üle administreerijatest ja juur juurtest, hoolimata obkject lock'ist, suudab andmeid siiski kustutada. Compliance'i korral on kõik naelutatud kindlalt ja varukoopiad ei saa keegi kustutada. Isegi Amazoni administraatorid (nende ametlike avalduste kohaselt). Me toetame just seda režiimi.