Capacity Tier (või nagu me oma vahel nimetame — kaptir) tuli algselt välja Veeam Backup and Replication 9.5 Update 4 all nimega Archive Tier. Selle idee oli võimaldada liigutada varukoopiaid, mis on väljaspool nii nimetatud operational restore window, objektihoidlasse. See aitas kasutada diskiruumi kasutajatele, kellel seda vähe oli. Seda valikut nimetati Move Mode.

Selle lihtsa (nagu võib tunduda) tegevuse teostamiseks tuli täita kaks tingimust: kõik punktid liigutatavast varukoopiast peavad olema väljaspool ülalmainitud operational restore window, mis on kasutajaliideses selgelt määratletud. Teiseks peab ahel olema nii nimetatud «suleeritud» (sealed backup chain või Inactive Backup Chain). See tähendab, et aja jooksul ei toimu selle ahela muutusi.

Kuid VBR v10-s täienes kontseptsioon uute funktsioonidega — lisandusid Copy Mode, Sealed Mode ja keeruliselt hääldatav termi Immutability.

Täna räägime neist põnevates asjadest. Esiteks, kuidas see töötas VBR9.5u4-s, ja seejärel muudatustest kümnendas versioonis.

Ja palun vabandust puhta keele kaitsjate ees, aga liiga palju termineid ei ole võimalik tõlkida.
Nii et siia tuleb palju anglicisme.
Ja palju giffe.
Ja pilte.

Ilma vähimagi kahetsuseta. Artikli autor.

Kuidas oli

Nii et alustame operational restore window'i ja sealed backup'i (või kuidas neid dokumentatsioonis nimetatakse Inactive Backup Chain). Ilma nende mõistmiseta ei saa edasi seletada.

Nagu näeme pildilt, on meil olemas teatud backup-ahel koos andmepakettidega, mis asub Performance tier SOBR-repositooriumis, millega on ühendatud Capacity Tier. Meie operatiivse backup'i aken on kolm päeva.

Seega esmaspäeval loodud .vbk pitseerib eelneva ahela, mille aken on seatud kolme päeva peale. Ja seega võib rahulikult alustada vanemate kolme päeva varade saatmist kapasitatiirimisse.

Aga mida täpselt mõeldi pitseeritud ahela all ja mis võidi saata kapasitatiirimisse update 4-s?

Forward Incremental'i puhul on uut täiskohustuslikku (full) backup'i loomine ahela pitseerimise tunnuseks. Pole tähtis, kuidas see täiskohustuslik (full) saavutatakse: arvestatakse nii synthetic full kui ka active full backups.

Reverse'i puhul on kõik failid, mis ei mahu operatiivse aknasse.

Forward increment'i puhul koos rullimisega on need kõik rullimised ja .vbk, kui jõudluslauses on veel üks .vbk.

Räägime nüüd Backup Copy ahelate töövariandist. Siin viidi ära ainult see, mis kuulus GFS hoidmise alla. Sest kõik, mis on uuemas backup copy ahelas, võib mingil viisil olla muudetud.

Uurime nüüd, mis toimub seadme all. Seal toimub protsess, mida nimetatakse dehüdratsiooniks — varukoopiafailide tühikute jätmine lausesse ja plokkide tõstmine nendest failidest kapatsitiirisse. Selle protsessi optimeerimiseks kasutatakse nn dehüdratsiooninäidikut, mis ei võimalda juba kapatsitiirisse kopeeritud blokke uuesti kopeerida.

Vaata, kuidas see välja näeb näite kaudu: oletame, et meil on .vbk, mis on tulnud operatiivaknast ja kuulub suletud ahelasse. See tähendab, et meil on täielik õigus see liigutada kapasitatihti. Liikumise hetkel luuakse kapasitatihti metadatafail ja liigutatava faili plokid. Metadatafaili linkide tasemel on kirjeldatud, millistest plokkidest meie fail koosneb. Pildil olevas näites koosneb meie esimene fail plokkidest a, b, c ja metadatades on lingid nende plokkide juurde. Kui meil on teine .vbk fail, mis on liikumiseks valmis ja koosneb plokkidest a, b ja d, saame dehüdratsiooni indeksi analüüsimisel aru, et peame liigutama vaid ploki d. Selle metadatafail sisaldab linke kahe eelmise bloki ja ühe uue juurde.

Seega, nende tüüpide andmetega täitmise protsessi nimetatakse rehidreerimiseks. Siin kasutatakse juba olemasolevat rehidreerimise indeksit, mis põhineb kõige vanemal .vbk failil kohaliku jõudluse ulatuses. See tähendab, et kui kasutaja soovib faili taastada kapassiivsetest saadetistest, loome esmalt kõige vanema täisvarukoopia plokkide indeksi ja kanname kapassiivse saadetise saadud puuduvad plokid. Näidatud juhul on meil vaja regidreerida FullBackup1.vbk vastavalt rehidreerimise indeksile, mistõttu on meil puudu ainult plokk C, mille kannamegi kapassiivsetest saadetistest. Kui kapassiivne saade on pilve objektide salvestus, võimaldab see säästa tohutult raha.

Siin võib tunduda, et see tehnoloogia on sama, mis WAN-kiirendites, kuid see on vaid näilisus. Kiirendites toimub deduplication globaalne tasand, siin kasutatakse aga kohalikke tulemusi iga faili jaoks teatud offset'i ulatuses. See tuleneb lahendatavast probleemist: peame kopeerima suuri faile täielikest varukoopiatest, ja meie uuringute kohaselt, isegi kui nende vahel on suur ajavahemik, annab selline deduplication algoritm parema tulemuse.

Aga rohkem indeksit, rohkem indeksit! On olemas ka indeks andmete taastamiseks! Kui me käivitame masina taastamise, mis asub kapasiti aknas, siis loeme ainult unikaalseid andmeplokke, mida ei ole tulemuslikkuse aknas.

Nii on saanud

Sissejuhatusega on kõik. See on üsna põhjalik, kuid nagu varem öeldud, ei saa ilma nende detailideta selgitada, kuidas uued funktsioonid toimivad. Seega, ilma liialdava eessõnna, liigume edasi esimesele.

Kopeerimisrežiim

Järjest enam põhineb see olemasolevatel tehnoloogiatel, kuid sisaldab täiesti teistsugust kasutusloogikat.

Selle režiimi eesmärk on tagada, et kõik lokaalsetel ulatustel asuvad andmed omavad koopiat kapasitiviirus.

Kui võrrelda otseselt Move ja Copy režiime, saab tulemuseks järgmise:

Liigutada saab ainult pitsatatud ahelat. Koopi režiimi puhul viiakse ära absoluutne kõik, sõltumata sellest, mis varundustöös toimub.
Liikumine toimub, kui failid ületavad operatiivse varunduse akna piire, kuid kopeerimine toimub kohe, kui varundusfail ilmub.
Uute andmete jälgimine kopeerimiseks toimub pidevalt, samas kui liikumine toimus iga 4 tunni tagant.

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

Kõige elementalmas olukorras ilmuvad meil lihtsalt uued failid koos inkrementidega, ja me kopeerime need lihtsalt kapasitiviirusse. Sõltumata sellest, millist režiimi kasutatakse varundustöös, kas see kuulub pitsatatud osa ahelasse või mitte, ning olgu meie operatiivne aken möödunud või mitte. Lihtsalt võtame ja kopeerime.

Protsess, mille taga on dehüdraatsioon, on endiselt sama, nagu juba eespool mainitud. Kopeerimisrežiimis jälgib see ka, et me ei kopeeriks plokke, mis juba meie salvestuses on. Ainsaks erinevuseks on see, et kui liikumisrežiimis asendasime reaalsed failid tühjade failidega, siis siin me neid kuidagi ei puutu ja jätame kõik nii, nagu on. Ülejäänud osa on täpselt sama dehüdreerimise indeks, mis hoolikalt püüab säästa teie raha ja aega.

Tõuseb küsimus — kui vaadata UI-d, siis seal on võimalus valida mõlemad valikud samal ajal. Kuidas selline kombineeritud režiim töötab?

Hakkame kohe asja selgitama.

Algus on standardne: luuakse varukoopia fail, ja see kopeeritakse kohe. Temaga luuakse inkrement ja see kopeeritakse samuti. Nii toimub kuni hetkeni, mil mõistame, et failid on meie operatiivaknast väljaulatuvad ja on tekkinud pitseeritud ahel. Sel hetkel viime läbi dehüdreerimise operatsiooni ja asendame need failid tühjadega. Loomulikult ei kopeeri me uuesti kapatsi tirile midagi.

Kogu selle põneva loogika eest vastutab vaid üks linnuke liideses: Copy backups to object storage as soon as they are created.

Miks meil on see Copy režiim?

Isegi parem oleks küsimust ümber sõnastada — milliste riskide eest me end selle abil kaitseme? Millist probleemi see aitab lahendada?

Vastus on ilmne: loomulikult on see andmete taastamine. Kui meie objektide salvestuses on täielik koopia lokaalsetest andmetest, siis pole tähtis, mis meie tootmises juhtub, me saame alati taastada andmed failidest, mis asuvad tinglikus Amazoni süsteemis.

Seega, vaatame võimalikke stsenaariume lihtsaimast keerulisemani.

Lihtsaim häda, mis meie peale võib langeda, on üksikute failide kättesaamatuse probleem varukopeerimise ahelas.

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

Veel hullem on see, kui kogu SOBR repositoorium muutub kättesaamatuks, kuid kapasitatiivne tiir töötab.
Ja täiesti halb on see, kui varukoopiaseerver sureb ja sinu esimene soov on üritada kümne minutiga Kanada piirini joosta.

Nüüd vaatame iga olukorda eraldi.

Kui oleme kaotanud ühe (ja isegi mitu) varukoopiafaili, siis piisab, kui käivitame reposi reskanimise protsessi, ja kadunud fail asendatakse tühjaga. Protsessi regidreerimise abil (millest räägiti artikli alguses) saab kasutaja andmed alla laadida kapasitatiivses tiirus kohalikku salvestusse.

Nüüd on olukord keerulisem. Kujutame ette, et meie SOBR koosneb kahest ekstensioonist, mis töötavad jõudlusrežiimis, mistõttu on meie .vbk ja .vib neile ebaühtlaselt jaotatud kihina. Ja mingil hetkel muutub üks ekstensioon kättesaamatuks ning kasutaja peab kiiresti taastama masina, mille osa andmetest on just sellel ekstensioonil.

Kasutaja käivitab taastamisvõluri, valib punkti, kuhu soovib taastada, kuid võlur jõuab oma töö käigus arusaamisele, et tal puuduvad kõik vajalikud taastamise andmed lokaalsetes salvestustes ning need tuleb alla laadida kapasitatiivsetest tiirudest. Sellega jäävad kohalikku salvestusse jäänud blokid pilvest alla laadimata. Tänu taastamisindeksile (jah, sellestki räägiti artikli alguses).

Selle juhtumi alaliik — kogu SOBR hoidla on muutunud kättesaamatuks. Sel juhul ei ole meil midagi kohalikest ladustustest kopeerida, ja kõik plokid laaditakse pilvest alla.

Ja kõige huvitavam olukord — varundusserver on surnud. Siin on kaks varianti: adminn on tubli ja tegi konfiguratsioonivarundusi, või adminn on ise endale kuri Buratino ja ei teinud konfiguratsioonivarundust.

Esimesel juhul piisab, kui kuskil käivitada puhas VBR paigaldus ja taastada oma andmebaas varundusest tavapäraste vahenditega. Selle protsessi lõpetamisel naaseb kõik oma algseisundisse. Või taastatakse see mõne ülalmainitud stsenaariumi põhjal.

Kuid kui administraator on endale vaenlane või varukoopia konfigureerimisega on juhtunud mütoloogiline ebaõnn, siis me ei jäta teda ka sellisel juhul oma saatuse hooleks. Selle jaoks oleme rakendanud uue protseduuri, mida nimetatakse Import Object Storage. See võimaldab vahele jätta käsitsi SOBR-repositooriumi taastamisprotsessi ja selle liitmise kapasitatiivse tiiruga, ning lihtsalt lisada objektide salvestus liidese kaudu ja käivitada Import Storage Repository protsess. Ainus asi, mis võib teie ja teie varukoopiate vahel seista, on palve sisestada parool, kui teie varukoopiad on krüpteeritud.

Copy Mode'ist on selleks korraks kõik ja liigume edasi

Sealed Mode

Põhiasi on see, et valitud SOBR-repositooriumi ulatuses ei saa ilmuda uusi varukoopiaid. Enne v10 oli meil ainult Maintenance Mode, kus oli täielikult keelatud igasugune töö repositooriumiga. Selline karm režiim salvestusruumi töölt välja viimiseks, kus on saadaval ainult Evacuate nupp, mis ühe korra viib varukoopiad teise ulatusse.

Sealed mode on sarnaste seisundite puhul tähendab, et me keelame uute varukoopiate loomise ja järk-järgult kustutame vanad vastavalt valitud retentsioonile, kuid protsessi käigus säilitame võimaluse taastuda salvestatud punktidest. See on väga kasulik, kui meie seadme eluiga on lõppemas ja seda tuleb asendada, või kui seda tuleb lihtsalt vabastada millegi olulisema jaoks, kuid ei ole kohta, kuhu kõike ühekorraga üle kanda. Või ei ole võimalik kustutada.

Seega on tööpõhimõte üsna lihtne: tuleb keelata kõik write operatsioonid (uute andmete ilmumine), jättes alles ainult read (taastamised) ja delete (retentsioon).

Kumbagi režiimi saab kasutada samaaegselt, kuid peab arvestama, et Maintenance'i prioriteet on kõrgem.

Näiteks võtame SOBR, mis koosneb kahest ekstreemist. Oletame, et esimesed neli päeva loodi varukoopiad edasiarendatud Forever Incremental režiimis ja seejärel tihendame ekstree. See toob kaasa uue aktiivse täiskoopia loomise teisel saadaval ekstree. Kui meie retentsioon on neli, siis kui kogu ahel, mis asub tihendatud ekstrees, ületab tema piire, kustutatakse see rahuliku südametunnistusega.

On olemas olukordi, kus kustutamine toimub varem. Näiteks on see Forward incremental koos perioodiliste täisvarukoopiate tegemisega. Kui esimesel kahel päeval teeme täisvarukoopiaid ja neljapäeval otsustame repositooriumi suletult, siis reedel, kui luuakse uus täisvarukoopia, eemaldatakse fail esmaspäevast, sest sellel hetkel pole sõltuvusi. Ja see hetk ei sõltu kellestki. Pärast seda ootame, kuni luuakse neli punkti kättesaadaval ulatusel, ja kustutame kolm muud, mida ei saa üksteisest sõltumatult kustutada.

Reverse Incremental on olukordades lihtsam. Seal ei sõltu vanimad punktid kellestki ja neid saab rahulikult kustutada. Seetõttu, kui uus .vbk luuakse uuel ulatusel, siis vanad .vrb eemaldatakse üksikult.

Muide, miks me iga kord loome uue .vbk: kui seda ei looda ja jätkatakse vana inkremendi ahelat, hakkaks vana .vbk igavesti jääma igasse režiimi, takistades selle kustutamist. Seetõttu otsustati, et niipea kui ulatus suletakse, loome täisvarukoopia vabale ulatusele.

Kapassitiiruga on asjad keerulisemad.

Alustame koopia režiimist. Oletame, et meil on neli päeva aktiivselt varukoopiate loomisega ja seejärel on kapatsiti tir suletud. Me ei kustuta midagi, vaid kannatame hoidmise ajast ära ning seejärel kustutame andmed kapatsiti tirist.

Sarnane protsess toimub ka liikuva režiimi korral — ootame hoidmise aega, kustutame vanad andmed kohalikust salvestusest ja kustutame objektisalvestuses hoitavad andmed.

Huvitav näide Forever forward incremental'ist. Seame hoidmise ajaks kolm punkti ja alates esmaspäevast teeme varukoopiaid, mis korrektselt kopeeritakse pilve. Pärast salvestusse suletust jätkatakse varukoopiate loomist, säilitades kolm punkti, kuid kapatsiti tiris hoitavad andmed jäävad sõltuvaks ja ei saa kustutada. Seetõttu ootame neljapäeva, mil meie .vbk ületab hoidmise aja, ja alles siis kustutame rahulikult kogu salvestatud ahela.

Ja väike märk: kõik näited on siin näidatud ühe masinaga. Kui teil on varukoopias mitu masinat, siis nende hoidmine sõltub sellest, kas on tehtud Active Full või mitte.

Sellega on põhimõtteliselt kõik. Nii et liigume edasi kõige karmima funktsiooni juurde —

Immutability

Nagu ka varasemate punktide puhul, alustan sellest, millist probleemi see funktsioon lahendab. Kui me laadime oma varukoopiaid kuhugi salvestamiseks, tekib tungiv vajadus tagada nende turvalisus, see tähendab füüsiliselt keelata nende kustutamine ja igasugune muutmine määratud säilitamisperioodi jooksul. Sealhulgas administratorite poolt, sealhulgas nende juurkontode kaudu. See kaitseb varukoopiaid juhusliku või tahtliku hävitamise eest. Kes töötab AWS-iga, on võinud kokku puutuda sellise funktsiooniga nimega Object Lock.

Vaatame nüüd režiimi üldiselt, seejärel süveneme üksikasjadesse. Meie näites on immutamine aktiveeritud meie mahutuse tüübile säilitamise ajaga neli päeva. Ja varukoopas on aktiveeritud kopeerimisrežiim.

Immutamine ei suhtle üldise säilitamisega. Näiteks ei lisa see lisapunkte ega midagi sarnast. Lihtsalt nelja päeva jooksul ei saa inimene kustutada varukoopia faile. Kui esmaspäeval tehakse varukoopia, siis on failide kustutamine võimalik alles reedel.

Kõik eelnevalt selgitatud dehüdratsiooni, indeksite ja metaandmete kontseptsioonid toimivad täpselt samamoodi. Kuid on üks tingimus — blokk kehtib mitte ainult andmete, vaid ka metaandmete jaoks. See on välja töötatud selleks, et kaitsta meie metaandmete baasi võimalike rünnakute eest ja et andmeplokid ei muutuks kasutuks binaarseks pudruks.

Nüüd on suurepärane hetk meie plokkide genereerimise tehnoloogia selgitamiseks. Vaatame olukorda, mis viis selle tekkimiseni.

Võtame kuue päeva ajaskaala ja märgime allapoole oodatava immutability lõppemise aja. Loome esimesel päeval faili, mis koosneb plokist a ja selle metadatatest. Kui immutability on seadistatud kolme päeva peale, on loogiline eeldada, et neljandal päeval andmed vabastatakse ja kustutatakse. Teisel päeval lisame uue file2, mis koosneb plokist b samade seadistustega. Plokk a tuleb endiselt kustutada neljandal päeval. Kuid kolmandal päeval juhtub õudus — luuakse fail File3, mis koosneb uuest plokist d ja viidatud vanale plokile a. See tähendab, et ploki a immutability lipp peab olema määratud uue tähtajaga, mis lükatakse kuuele päevale. Ja siin tekib probleem — reaalses varukoopias tekib selliseid plokke tohutult palju. Ja et pikendada nende immutability perioodi, tuleb iga kord teha tohutult palju päringuid. Ja tegelikult on see peaaegu lõpmatu igapäevane protsess, kuna suure tõenäosusega leiame iga kopeerimise käigus suuri pakke dedupeeritud plokke. Mis see tähendab, kui palju päringuid objekti salvestuspakkujatelt? Õige! Suur arve kuu lõpus.

Ja et mitte näidata oma väärtuslike kliente rahaliselt ebamugavatesse olukordadesse, töötati välja block generation mehhanism. See on lisaperiood, mille lisame välja pakutud immutability perioodile. Alljärgnevas 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 ajal.

Jätkame sama olukorra vaatamist, kuid nüüd block generation'iga. Loome esimesel päeval file1 blokist a ja metandmetest. Kogume kokku genereerimise perioodi ja immutability — see tähendab, et faili kustutamine on võimalik alles kuuendal päeval. Kui teisel päeval loome File2, mis koosneb blokist b ja lingist bloki a juurde, siis eeldatav kustutamise kuupäev ei muutu. See jääb kuuendaks päevaks, nagu enne. Sellega püüame vähendada päringute arvu. Ainus olukord, kus tähtaeg võib nihkuda, on see, kui genereerimise periood on lõppenud. See tähendab, et kui kolmandal päeval uus File3 sisaldab linki bloki a juurde, lisatakse generation 2, kuna Gen1 on juba lõppenud. Ja eeldatav bloki a kustutamise kuupäev nihkub kaheksandaks päevaks. See võimaldab meil dramaatiliselt vähendada päringute arvu deduplication'i poolt seotud plokkide eluaja pikendamiseks, mis säästab klientidele palju raha.

Tehnoloogia on kättesaadav S3 ja S3-ühilduva riistvara kasutajatele, mille tootjad garanteerivad, et nende rakendus ei erine Amazoni omast. Seega on õigustatud küsimus, miks Azure't ei toetata — neil on sarnane funktsioon, kuid see töötab konteinerite tasemel, mitte eraldi objektide tasemel. Muide, Amazoni enda objektide lokaalne säilitamine on saadaval kahes režiimis: compliance ja governance. Teises režiimis jääb võimalus, et kõige suurem admin, kes on adminide üle, ja root, kes on rootide üle, vaatamata objekti lokaalsele säilitamisele, ikkagi kustutab andmeid. Compliance režiimi puhul on kõik haamerdatud igaveseks ning varukoopiad ei ole kellelgi kustutatavad. Isegi Amazoni administraatoritel (nagu nad oma ametlikes avaldustes kinnitavad). Me toetame just seda režiimi.