Capacity Tier (või nagu me seda Vimi sees kutsume - captir) ilmus Veeam Backup and Replication 9.5 värskenduse 4 päevil nime all Archive Tier. Idee selle taga on võimaldada nn operatsiooni taastamise aknast välja kukkunud varukoopiaid objektide salvestusruumi teisaldada. See aitas vabastada kettaruumi nende kasutajate jaoks, kellel seda vähe oli. Ja seda valikut kutsuti liikumisrežiimiks.

Selle lihtsa (nagu näib) toimingu tegemiseks piisas kahe tingimuse täitmisest: kõik teisaldatud varukoopia punktid peavad olema väljaspool ülalmainitud töö taastamise akna piire, mis on kasutajaliideses selgesõnaliselt määratud. Ja teiseks: kett peab olema niinimetatud "suletud kujul" (suletud varukett või mitteaktiivne varukett). See tähendab, et selles ahelas aja jooksul muutusi ei toimu.

Kuid VBR v10-s täiendati kontseptsiooni uute funktsioonidega - ilmusid paljundusrežiim, pitseeritud režiim ja raskesti hääldatava nimega Immutability asi.

Need on põnevad asjad, millest me täna räägime. Kõigepealt sellest, kuidas see VBR9.5u4-s töötas, ja seejärel kümnenda versiooni muudatustest.

Ja andku mulle puhta keele eestvõitlejad andeks, aga liiga palju on termineid, mida ei saa tõlkida.
Nii et siin on palju anglitsisme.
Ja palju gifisid.
Ja pilte.

• Ilma vähimagi kahetsuseta. Artikli autor.

Nagu see oli

Alustuseks analüüsime operatsiooni taastamise akent ja suletud varukoopiat (või nagu neid nimetatakse passiivse varundusahela dokumentatsioonis). Ilma nende mõistmiseta pole edasised selgitused võimalikud.

Nagu pildil näeme, on meil omamoodi andmeplokkidega varukett, mis asub selle hoidla jõudlustasemel SOBR, millega mahutasand on ühendatud. Meie operatiivne varuaken on kolm päeva.

Vastavalt sellele sulgeb esmaspäeval loodud .vbk eelmise ahela, mille aknaks on seatud kolm päeva. Ja see tähendab, et võite julgelt alustada lasketiiru transportimisega kõike, mis on vanem kui need kolm päeva.

Mida aga täpsemalt pitseeritud keti all silmas peeti ja mida sai värskenduses 4 saata suutlikkuse lasketiiru?

Forward Incrementali puhul on keti sulgemise märk uue täieliku varukoopia loomine. Ja pole vahet, kuidas see täielik varukoopia saadakse: arvesse võetakse nii sünteetilisi täis- kui ka aktiivseid täielikke varukoopiaid.

Reverse puhul on need kõik failid, mis operatsiooniaknasse ei satu.

Tagasipööramisega edasikasvu korral on need kõik tagasipööramised ja .vbk, kui jõudluse ulatuse kohta on veel üks .vbk

Nüüd kaalume varukoopia kettidega töötamise võimalust. Siia veeti ainult GFS-i säilitamise alla kuuluvaid esemeid. Sest kõike, mis on salvestatud uuemates varukoopiakettides, saab ühel või teisel viisil muuta.

Nüüd vaatame kapoti alla. Seal toimub protsess nimega dehüdratsioon – tühjade varukoopiafailide jätmine ulatusse ja nendest failidest plokkide lohistamine mahutavuse lasketiiru. Selle protsessi optimeerimiseks kasutatakse nn dehüdratsiooniindeksit, mis võimaldab vältida juba kopeeritud plokkide kopeerimist mahutavuse lasketiiru.

Vaatame näite abil, kuidas see välja näeb: Oletame, et meil on .vbk, mis väljus tehinguaknast ja kuulub suletud ahelasse. See tähendab, et meil on täielik õigus viia see suutlikkuse lasketiiru. Teisaldamise ajal luuakse ülekantud faili mahutavuse kriipsu ja plokkidesse metaandmete fail. Lingitaseme metaandmete fail kirjeldab, millistest plokkidest meie fail koosneb. Pildil kujutatud juhul koosneb meie esimene fail plokkidest a, b, c ja metaandmed sisaldavad linke nendele plokkidele. Kui meil on teine ​​.vbk-fail, mis on teisaldamiseks valmis ja koosneb plokkidest a, b ja d, saame dehüdratsiooniindeksit analüüsides aru, et üle kanda tuleb ainult plokk d. Ja selle metaandmete fail sisaldab linke kahele eelmisele ja ühele uuele plokile.

Sellest tulenevalt nimetatakse nende tühjade kohtade andmetega täitmise protsessi rehüdratsiooniks. See kasutab juba oma rehüdratsiooniindeksit, mis põhineb kohaliku jõudluse ulatuse vanimal .vbk-failil. See tähendab, et kui kasutaja soovib tagastada faili mahutavuse lasketiirus, loome esmalt vanima täieliku varukoopia plokkide indeksi ja edastame mahutavuse laskegaleriist ainult puuduvad plokid. Pildil kujutatud juhul on FullBackup1.vbk rehüdratatsiooniks rehüdratsiooniindeksi järgi vaja vaid plokki C, mille võtame suutlikkuse lasketiirust. Kui salvestuspilveobjekt toimib lasketiirina, võimaldab see säästa tohutult raha.

Siin võib tunduda, et see tehnoloogia on identne WAN-kiirendites kasutatavaga, kuid see ainult näib nii. Kiirendites on deduplikatsioon globaalne; siin kasutatakse igas failis kohalikku deduplikatsiooni kindla nihkega. See juhtub lahendatavate ülesannete erinevuse tõttu: siin tuleb kopeerida suured täielikud varukoopiafailid ja meie uurimistöö kohaselt annab see deduplikatsioonialgoritm parima tulemuse isegi siis, kui nende vahel kulub pikk aeg.

Aga rohkem indekseid indeksite jumalale! Andmete taastamiseks on ka indeks! Kui alustame võimsuskriipsus asuva masina taastamist, loeme ainult unikaalseid andmeplokke, mida jõudluskriipsus pole.

Kuidas see juhtus?

Sissejuhatava osa jaoks on see kõik. See on üsna üksikasjalik, kuid nagu eespool mainitud, pole ilma nende üksikasjadeta võimalik selgitada, kuidas uued funktsioonid töötavad. Seetõttu liigume ilma pikema jututa edasi esimese juurde.

Kopeerimisrežiim

See põhineb suuresti olemasolevatel tehnoloogiatel, kuid kannab hoopis teistsugust kasutusloogikat. 

Selle režiimi eesmärk on tagada, et kõikidel kohalikul ulatusel asuvatel andmetel oleks mahutavuse kriipsus koopia.

Kui võrrelda režiime Teisaldamine ja Kopeerimine, näeb see välja järgmine:

• Ainult suletud ketti saab liigutada. Kopeerimisrežiimi puhul kantakse üle absoluutselt kõik, sõltumata varundustöös toimuvast.
• Teisaldamine käivitub, kui failid väljuvad operatiivse varundusakna piiridest, ja kopeerimine käivitub kohe, kui varukoopiafail ilmub.
• Uute andmete jälgimine kopeerimiseks toimub pidevalt ja teisaldamiseks käivitati see kord 4 tunni jooksul.

Uue režiimi kaalumisel teen ettepaneku liikuda lihtsatelt näidetelt keerukate näidete poole.

Kõige tavalisemal juhul on meil lihtsalt uued failid koos juurdekasvuga ja kopeerime need lihtsalt mahutavuse lasketiiru. Olenemata sellest, millist režiimi varutöös kasutatakse, olenemata sellest, kas see kuulub keti suletud osasse või mitte, olenemata sellest, kas meie tööaken on aegunud. Nad lihtsalt võtsid selle ja kopeerisid selle.

Selle taga on endiselt dehüdratsioon, nagu eespool kirjeldatud. Kopeerimisrežiimis tagab see ka selle, et me ei kopeeriks plokke, mis on juba meie salvestusruumis. Ainus erinevus seisneb selles, et kui filmirežiimis asendasime pärisfailid näivfailidega, siis siin me neid kuidagi ei puuduta ja jätame kõik nii nagu on. Vastasel juhul on tegemist täpselt sama dehüdratsiooniindeksiga, mis püüab hoolikalt teie raha ja aega säästa.

Tekib küsimus – kui vaadata kasutajaliidest, siis on võimalus valida mõlemad valikud korraga. Kuidas selline kombineeritud režiim töötab?

Mõistame.

Algus on standardne: luuakse varukoopiafail ja kopeeritakse kohe. Sellele luuakse juurdekasv ja ka kopeeritakse. See juhtub hetkeni, mil mõistame, et failid on meie tööaknast lahkunud ja ilmunud on suletud kett. Sel hetkel teostame dehüdratsioonioperatsiooni ja asendame need failid näivfailidega. Muidugi ei kopeeri me midagi uuesti suutlikkuse lasketiiru.

Kogu see põnev loogika vastutab liideses vaid ühe märkeruudu eest: kopeerige varukoopiad objektide salvestusruumi niipea, kui need on loodud.

Miks me seda kopeerimisrežiimi vajame?

Veelgi parem on küsimus ümber sõnastada nii: milliste ohtude eest oleme selle abiga kaitstud? Millist probleemi see aitab meil lahendada?

Vastus on ilmne: loomulikult on see andmete taastamine. Kui meil on objektisalvestusel kohalike andmete täielik koopia, siis olenemata sellest, mis meie tootega juhtub, saame alati taastada andmeid tingimuslikus Amazonis asuvatest failidest.

Nii et vaatame läbi võimalikud stsenaariumid, alates kõige lihtsamast kuni keerukamani.

Lihtsaim õnnetus, mis meile pähe võib langeda, on ühe varuahela faili ligipääsmatus.

Kurvem lugu on see, et meie SOBR-i hoidla üks ulatus läks katki.

Asi läheb veelgi hullemaks, kui kogu SOBR-i hoidla on muutunud kättesaamatuks, kuid mahutav lasketiir töötab.
Ja kõik on tõesti halb - see on siis, kui varuserver sureb ja teie esimene soov on proovida kümne minutiga Kanada piirile joosta.

Vaatame nüüd iga olukorda eraldi.

Kui oleme kaotanud ühe (ja isegi mitu) varukoopiafaili, peame vaid alustama hoidla uuesti skannimise protsessi ja kadunud fail asendatakse näiva failiga. Ja kasutades rehüdratatsiooniprotsessi (mida arutati artikli alguses), saab kasutaja võimsusega lasketiirus andmeid alla laadida kohalikku salvestusruumi.

Nüüd on olukord keerulisem. Oletame, et meie SOBR koosneb kahest jõudlusrežiimis töötavast astmest, mis tähendab, et meie .vbk ja .vib on jaotatud nende peale üsna ebaühtlase kihina. Ja mingil ajahetkel muutub üks ulatustest kättesaamatuks ja kasutajal on kiiremas korras vaja taastada masin, mille andmetest osa just sellel ulatusel on.

Kasutaja käivitab taasteviisardi, valib punkti, kuhu ta soovib taastada, ja viisard jõuab töö ajal arusaamisele, et tal pole kõiki kohalikuks taastamiseks vajalikke andmeid ja seetõttu tuleb need võimsuse võttest alla laadida. galerii. Samal ajal ei laadita pilvest alla kohalikku salvestusruumi jäänud plokke. Au taastamisindeksile (jah, seda mainiti ka artikli alguses).

Selle juhtumi alamtüüp on see, et kogu SOBR-i hoidla muutus kättesaamatuks. Sel juhul pole meil kohalikust salvestusruumist midagi kopeerida ja kõik plokid laaditakse alla pilvest.

Ja kõige huvitavam olukord on see, et varuserver suri. Siin on kaks võimalust: admin on suurepärane ja tegi seadistuste varukoopiaid ning administraator on ise kuri Pinocchio ja ei teinud seadistuste varukoopiaid.

Esimesel juhul piisab, kui ta lihtsalt juurutab VBR-i puhta installi kuskile ja taastab selle andmebaasi standardsete vahenditega varukoopiast. Selle protsessi lõpus taastub kõik normaalseks. Või taastatakse see ühe ülaltoodud stsenaariumi järgi.

Kuid kui administraator on kas enda vaenlane või konfiguratsioonivarundus sai samuti eepilise tõrke, siis isegi siin ei jäta me teda saatuse meelevalda. Sel juhul oleme kasutusele võtnud uue protseduuri nimega Import Object Storage. See võimaldab teil vahele jätta SOBR-i hoidla käsitsi taasloomise ja sellele mahutavuse lasketiiru lisamise koos järgneva uuesti skaneerimisega ning lihtsalt lisada Vimi liidesesse salvestusobjekti ja käivitada salvestusruumi importimise protseduuri. Ainus asi, mis teie ja teie varukoopiate vahel võib takistada, on parooli sisestamise taotlus, kui teie varukoopiad olid krüptitud.

Tõenäoliselt puudutab see kõik kopeerimisrežiimi ja liigume edasi

Suletud režiim

Põhiidee on see, et uued varukoopiad ei saa ilmuda hoidla valitud SOBR-i ulatuses. Enne versiooni 10 oli meil ainult hooldusrežiim, kui igasugune töö hoidlaga oli täielikult keelatud. Omamoodi raskekujuline režiim salvestusruumi sulgemiseks, kus on saadaval ainult nupp Evacuate, mis transpordib ühekordselt varukoopiaid muul määral.

Ja pitseeritud režiim on omamoodi “pehme” valik: keelame uute varukoopiate loomise ja kustutame järk-järgult vanad vastavalt valitud säilitamisele, kuid selle käigus ei kaota me salvestatud punktidest taastamise võimalust. Väga kasulik asi, kui meil on kas mõni riistvara oma eluiga lõppemas ja vaja välja vahetada või lihtsalt millegi olulisema jaoks vabastada, aga pole kuskilt võtta ja kõike korraga teisaldada. Või ei saa seda kustutada.

Sellest lähtuvalt on tööpõhimõte üsna lihtne: on vaja keelata kõik kirjutamistoimingud (uute andmete ilmumine), lugemisest lahkumine (taastamine) ja kustutamine (säilitamine).

Mõlemat režiimi saab kasutada samaaegselt, kuid pidage meeles, et hooldusel on kõrgem prioriteet.

Vaatleme näiteks kahest ulatusest koosnevat SOBR-i. Oletame, et esimesed neli päeva tegime varukoopiaid Forward Forever Incremental režiimis ja seejärel pitseerime ulatuse, mis viib selleni, et alustame uue aktiivse täieliku loomist teisel saadaoleval määral. Kui meie kinnipidamine on neli, siis kui kogu pitseeritud ulatusel asuv kett läheb üle oma piiride, kustutatakse see puhta südametunnistusega.

On olukordi, kus kustutamine toimub varem. Näiteks see on perioodiliste täisväärtustega inkrementaalne edasi. Kui tegime esimese kahe päeva jooksul täielikud varukoopiad ja neljapäeval otsustame hoidla pitseerida, siis reedel, kui luuakse uus varukoopia, kustutatakse esmaspäevane fail, kuna siinkohal pole mingeid sõltuvusi. Ja point ise ei sõltu kellestki. Seejärel ootame, kuni saadaolevale ulatusele luuakse neli punkti ja kustutame ülejäänud kolm, mida ei saa üksteisest sõltumatult kustutada.

Reverse Incrementaliga on asjad lihtsamad. Selles ei sõltu vanimad punktid millestki ja neid saab ohutult kustutada. Seega, niipea kui uus .vbk luuakse uuel määral, kustutatakse vanad .vrb-d ükshaaval.

Muide, miks me loome iga kord uue .vbk: kui me seda ei looks, vaid jätkaks vana juurdekasvuahelat, siis vana .vbk jääks lõpmatult pikaks ajaks suvalises režiimis, takistades selle kustutamist. Seetõttu otsustati, et niipea kui ulatus on suletud, loome tasuta ulatuse kohta täieliku varukoopia.

Võimsate lasketiiru puhul on asjad keerulisemad.

Kõigepealt vaatame kopeerimisrežiimi. Oletame, et tegime neli päeva aktiivselt varukoopiaid ja siis sai mahutav lasketiir kinni. Me ei kustuta midagi, vaid talume alandlikult säilitamist, misjärel kustutame andmed võimekuse lasketiirus.

Ligikaudu sama asi juhtub teisaldusrežiimis – ootame retušeerimist, kustutame kohalikust mälust vana ja kustutame objektihoidlasse salvestatu.

Huvitav näide Foreveri edasiliikumise kohta. Installime retentioni kolme punkti ja alustame esmaspäeval varukoopiate tegemist, mis kopeeritakse regulaarselt pilve. Pärast salvestusruumi sulgemist jätkatakse varukoopiate loomist, säilitades kolm punkti, kuid mahutavuse kriipsu salvestatud andmed jäävad sõltuvaks ja neid ei saa kustutada. Seetõttu ootame neljapäevani, mil meie .vbk ületab säilitamise piiri ja alles siis kustutame rahulikult kogu salvestatud ahela.

Ja väike lahtiütlus: kõik siin olevad näited on näidatud ühe masinaga. Kui teie varukoopias on neid mitu, erineb nende retušeerimine sõltuvalt sellest, kas Active Full tehti või mitte.

See on põhimõtteliselt kõik. Liigume edasi kõige raskema funktsiooni juurde -

Muutmatus

Nagu eelmiste punktide puhul, on esimene asi, millise probleemi see funktsioon lahendab. Niipea, kui me oma varukoopiad kuhugi salvestamiseks üles laadime, on suur soov tagada nende ohutus, st keelata füüsiliselt nende kustutamine ja mis tahes muutmine antud säilitamise ajal. Kaasa arvatud administraatorid, sealhulgas nende juurkontode all. See võimaldab teil kaitsta neid juhusliku või tahtliku kahjustamise eest. Igaüks, kes töötab AWS-iga, võib olla kohanud sarnast funktsiooni Object Lock.

Vaatame nüüd režiimi üldiselt ja seejärel süveneme üksikasjadesse. Meie näites lubatakse muutumatus meie lasketiirus neljapäevase säilitusajaga. Ja kopeerimisrežiim on varunduses lubatud.

Muutumatus ei mõjuta mingil viisil üldist kinnipidamist. Näiteks ei anna see lisapunkte ega muud taolist. See on lihtsalt see, et inimene ei saa varukoopiaid nelja päeva jooksul kustutada. Kui teete varukoopia esmaspäeval, saate selle faili kustutada alles reedel.

Kõik eelnevalt selgitatud dehüdratsiooni, indeksite ja metaandmete mõisted töötavad täpselt samamoodi. Kuid ühe tingimusega - plokk on seatud mitte ainult andmete, vaid ka metaandmete jaoks. Seda tehakse juhuks, kui kaval ründaja otsustab meie metaandmete andmebaasi kustutada ja takistada andmeplokkide muutumist kasutuks binaarseks pudruks.

Nüüd on suurepärane aeg selgitada meie plokkide genereerimise tehnoloogiat. Või plokkide genereerimine. Selleks kaaluge olukorda, mis viis selle ilmumiseni.

Võtame kuuepäevase ajaskaala ja alla märgime muutumatuse eeldatava aegumise aja. Esimesel päeval võtame ja loome faili, mis koosneb andmeplokist a ja selle metaandmetest. Kui muutumatuks on määratud kolm päeva, on loogiline eeldada, et neljandal päeval andmed avatakse ja kustutatakse. Teisel päeval lisame uue faili2, mis koosneb samade seadistustega plokist b. Blokk a ikkagi tuleb eemaldada neljandal päeval. Kuid kolmandal päeval juhtub midagi kohutavat – luuakse File3 fail, mis koosneb uuest plokist d ja lingist vanale plokile a. See tähendab, et ploki ja selle muutumatuse lipp tuleb lähtestada uuele kuupäevale, mis nihutatakse kuuendale päevale. Ja siin tekib probleem - päris varukoopiates on selliseid plokke tohutult palju. Ja nende muutumatuse perioodi pikendamiseks peate iga kord esitama tohutult palju taotlusi. Ja tegelikult on see peaaegu lõputu igapäevane protsess, kuna suure tõenäosusega leiame iga koopiaga kopsakad virnad dubleeritud plokke. Mida tähendab objektide salvestusteenuste pakkujate suur hulk päringuid? Õige! Kuu lõpus suur arve.

Ja selleks, et mitte oma lemmikkliente märkimisväärse raha eest ilmselgelt paljastada, leiutati plokkide genereerimise mehhanism. See on lisaperiood, mille lisame määratud muutumatuse perioodile. Allolevas näites on see periood kaks päeva. Kuid see on vaid näide. Tegelikkuses kasutavad nad oma valemit, mis annab kuuluku ajal ligikaudu kümme lisapäeva.

Jätkame sama olukorra kaalumist, kuid plokkide genereerimisega. Esimesel päeval loome plokist a ja metaandmetest faili1. Liidame kokku genereerimisperioodi ja muutumatuse – see tähendab, et faili kustutamise võimalus on kuuendal päeval. Kui teisel päeval loome faili 2, mis koosneb plokist b ja lingist blokki a, siis eeldatava kustutamiskuupäevaga ei juhtu midagi. Ta seisis samamoodi nagu kuuendal päeval. Seega püüame taotluste arvu pealt raha kokku hoida. Ainus olukord, kus tähtaega saab nihutada, on genereerimisperioodi lõppemine. See tähendab, et kui kolmandal päeval sisaldab uus fail3 linki a blokeerimiseks, siis lisatakse põlvkond 2, kuna Gen1 on juba aegunud. Ja ploki a kustutamise eeldatav kuupäev nihkub kaheksandale päevale. See võimaldab meil järsult vähendada taotluste arvu deduplikeeritud plokkide eluea pikendamiseks, mis säästab klientidel tonni raha.

Tehnoloogia ise on saadaval S3 ja S3-ühilduva riistvara kasutajatele, mille tootjad garanteerivad, et nende teostus ei erine Amazoni omast. Siit ka vastus õigustatud küsimusele, miks Azure'i ei toetata – neil on sarnane funktsioon, kuid see töötab konteinerite, mitte üksikute objektide tasemel. Muide, Amazonil endal on objektilukk kahes režiimis: vastavus ja juhtimine. Teisel juhul jääb alles võimalus, et suurim administ kõrgemal olev admin ja juurte kohal olev juur, hoolimata objektilukust, kustutab andmed siiski. Vastavuse korral on kõik kõvasti kinni löödud ja keegi ei saa varukoopiaid kustutada. Isegi Amazoni administraatorid (vastavalt nende ametlikele avaldustele). See on režiim, mida me toetame.

Ja nagu tavaliselt, mõned kasulikud lingid:

• edasi Plokkide genereerimine igas detailis.
• Kogu teave selle kohta Veeam varundamine ja replikatsioon 10 oma parimal kujul
• О Mahutavusaste üksikasjalikult

Allikas: www.habr.com