Capacity Tier (eða eins og við köllum það inni í Vim - captir) birtist aftur á dögum Veeam Backup and Replication 9.5 Update 4 undir nafninu Archive Tier. Hugmyndin á bakvið það er að gera það mögulegt að færa öryggisafrit sem hafa dottið út um svokallaðan rekstrarendurheimtglugga yfir í hlutageymslu. Þetta hjálpaði til við að hreinsa upp pláss fyrir þá notendur sem áttu lítið af því. Og þessi valkostur var kallaður Move Mode.

Til að framkvæma þessa einföldu (eins og það virðist) aðgerð var nóg að uppfylla tvö skilyrði: allir punktar úr fluttu öryggisafritinu verða að vera utan marka ofangreinds rekstrarendurheimtarglugga, sem er sérstaklega stilltur í notendaviðmótinu. Og í öðru lagi: keðjan verður að vera í svokölluðu „lokuðu formi“ (lokuð varakeðja eða óvirk varakeðja). Það er, engar breytingar eiga sér stað í þessari keðju með tímanum.

En í VBR v10 var hugmyndinni bætt við með nýjum aðgerðum - Copy Mode, Sealed Mode og hlutur með það sem erfitt er að bera fram nafnið Immutability birtist.

Þetta eru heillandi hlutir sem við munum tala um í dag. Fyrst um hvernig það virkaði í VBR9.5u4 og síðan um breytingar á tíundu útgáfunni.

Og megi meistarar hreinnar tungu fyrirgefa mér, en það eru of mörg hugtök sem ekki er hægt að þýða.
Svo það verður tonn af angliismum hér.
Og fullt af gifs.
Og myndir.

• Án minnstu eftirsjár. Höfundur greinarinnar.

Eins og það var

Jæja, við skulum byrja á því að greina rekstrarendurheimtargluggann og innsiglað öryggisafrit (eða eins og það er kallað í Inactive Backup Chain skjölunum). Án skilnings þeirra verður frekari skýring ekki möguleg.

Eins og við sjáum á myndinni erum við með eins konar afritunarkeðju með gagnablokkum, sem er staðsett á Performance tier SOBR geymslunnar sem Capacity Tier er tengdur við. Afritunartími okkar er þrír dagar.

Í samræmi við það innsiglar .vbk-ið sem búið var til á mánudaginn fyrri keðju, en gluggi hennar er stilltur á þrjá daga. Og það þýðir að þú getur örugglega byrjað að flytja allt eldra en þessa þrjá daga á skotsvæðið.

En hvað var nákvæmlega átt við með innsiglaðri keðju og hvað var hægt að senda á skotsvæðið í uppfærslu 4?

Fyrir Forward Incremental er merki um að innsigla keðjuna að búa til nýtt fullt öryggisafrit. Og það skiptir ekki máli hvernig þetta fulla öryggisafrit er fengið: bæði tilbúið fullt og virkt fullt afrit er tekið til greina.

Þegar um Reverse er að ræða eru þetta allar skrár sem falla ekki inn í rekstrargluggann.

Ef um er að ræða aukningu áfram með afturköllun, þá eru þetta allt afturköllun og .vbk, ef það er annað .vbk á frammistöðumarki

Nú skulum við íhuga möguleikann á að vinna með öryggisafritunarkeðjur. Aðeins hlutir sem falla undir GFS varðveislu voru fluttir hingað. Vegna þess að allt sem er geymt í nýrri öryggisafritunarkeðjum er hægt að breyta á einn eða annan hátt.

Nú skulum við líta undir hettuna. Þar á sér stað ferli sem kallast ofþornun - skilur eftir tómar varaskrár á umfangi og dregur kubba úr þessum skrám yfir á afkastagetu skotsvæðisins. Til að hámarka þetta ferli er notaður svokallaður afvötnunarstuðull, sem gerir þér kleift að forðast að afrita kubba sem þegar hafa verið afritaðar á afkastagetu skotsvæðisins.

Við skulum sjá hvernig þetta lítur út með dæmi: Segjum að við séum með .vbk sem kom út um viðskiptagluggann og tilheyrir lokaðri keðju. Þetta þýðir að við höfum fullan rétt á því að færa það á skotsvæðið með afkastagetu. Þegar flutningurinn er fluttur er lýsigagnaskrá búin til í getu striki og blokkum á yfirfærðu skránni. Lýsigagnaskráin á tenglastigi lýsir hvaða blokkum skráin okkar samanstendur af. Í tilvikinu á myndinni samanstendur fyrsta skráin okkar af kubbum a, b, c og lýsigögnin innihalda tengla á þessa kubba. Þegar við erum með aðra .vbk skrá, tilbúin til flutnings og sem samanstendur af kubbum a, b og d, skiljum við, við að greina afvötnunarvísitöluna, að aðeins þarf að flytja blokk d. Og lýsigagnaskrá hennar mun innihalda tengla á tvær fyrri blokkir og eina nýja.

Samkvæmt því er ferlið við að fylla þessi tómu rými aftur með gögnum kallað endurvökvun. Það notar nú þegar sína eigin vökvavísitölu, byggt á elstu .vbk skránni á staðbundinni frammistöðu. Það er að segja, ef notandinn vill skila skrá frá tökusvæðinu, búum við fyrst til vísitölu yfir kubbana af elsta fulla öryggisafritinu og flytjum aðeins þá kubba sem vantar úr myndatökusalnum. Í tilvikinu sem sýnt er á myndinni, til þess að endurvökva FullBackup1.vbk í samræmi við endurvökvunarvísitöluna, þurfum við aðeins blokk C, sem við tökum frá afkastagetu skotsvæðinu. Ef skýjahlutur í geymslu þjónar sem skotsvæði með afkastagetu gerir þetta þér kleift að spara gífurlegar upphæðir.

Hér kann að virðast að þessi tækni sé eins og notuð er í WAN hröðum, en það virðist bara vera svo. Í hröðlum er aftvíföldun alþjóðleg; hér er staðbundin aftvíföldun notuð innan hverrar skráar með ákveðnu móti. Þetta gerist vegna mismunar á verkefnunum sem verið er að leysa: hér þurfum við að afrita stórar fullar öryggisafritsskrár og samkvæmt rannsóknum okkar, jafnvel þótt langur tími líði á milli þeirra, gefur þetta aftvíföldunaralgrím bestu niðurstöðuna.

En fleiri vísitölur fyrir guð vísitölunnar! Það er líka vísitala fyrir endurheimt gagna! Þegar við byrjum að endurheimta vél sem staðsett er í afkastagetustikunni, munum við aðeins lesa einstaka gagnakubba sem eru ekki í frammistöðustrikinu.

Hvernig gerðist það?

Það er allt fyrir inngangshlutann. Það er nokkuð ítarlegt, en eins og nefnt er hér að ofan, án þessara upplýsinga er ekki hægt að útskýra hvernig nýju aðgerðirnar virka. Þess vegna skulum við halda áfram að því fyrsta, án frekari ummæla.

Afritunarstilling

Það er að miklu leyti byggt á núverandi tækni, en hefur allt aðra rökfræði í notkun. 

Tilgangur þessarar stillingar er að tryggja að öll gögn sem staðsett eru á staðnum séu með afrit í rúmtakstrikinu.

Ef þú berð saman hreyfingar og afrita stillingarnar beint, mun það líta svona út:

• Aðeins er hægt að færa innsigluðu keðjuna. Ef um er að ræða afritunarham er algerlega allt flutt, óháð því sem gerist í öryggisafritunarvinnunni.
• Flutningur fer af stað þegar skrárnar fara út fyrir mörk rekstrarafritunargluggans og afritun fer af stað um leið og afritaskráin birtist.
• Eftirlit með nýjum gögnum til afritunar á sér stað stöðugt og til að flytja það var komið af stað einu sinni á 4 klukkustunda fresti.

Þegar ég íhuga nýja stillinguna, legg ég til að fara frá einföldum dæmum yfir í flókin.

Í algengustu tilfellunum erum við einfaldlega með nýjar skrár með stigum og afritum þær einfaldlega á skotsvæðið. Óháð því hvaða háttur er notaður í öryggisafritinu, óháð því hvort hann tilheyrir lokuðum hluta keðjunnar eða ekki, óháð því hvort rekstrarglugginn okkar er útrunninn. Þeir tóku það bara og afrituðu það.

Ferlið á bak við þetta er enn ofþornun eins og lýst er hér að ofan. Í afritunarham tryggir það líka að við afritum ekki blokkir sem eru þegar á geymslunni okkar. Eini munurinn er sá að ef við skiptum út raunverulegum skrám fyrir dummy skrár í kvikmyndaham, þá snertum við þær ekki á nokkurn hátt og látum allt vera eins og það er. Annars er það nákvæmlega sama ofþornunarvísitalan, sem reynir vandlega að spara peninga og tíma.

Spurningin vaknar - ef þú skoðar HÍ er tækifæri til að velja báða valkostina á sama tíma. Hvernig mun slíkur samsettur háttur virka?

Við skulum reikna það út.

Upphafið er staðlað: öryggisafrit er búið til og afritað strax. Aukahlutfall er búið til í það og einnig afritað. Þetta gerist þar til við gerum okkur grein fyrir því að skrárnar hafa farið út úr rekstrarglugganum okkar og lokuð keðja hefur birst. Á þessum tímapunkti gerum við þurrkunaraðgerð og skiptum þessum skrám út fyrir dummy skrár. Auðvitað afritum við ekki neitt aftur á afkastagetu skotsvæðinu.

Öll þessi heillandi rökfræði er ábyrg fyrir aðeins einum gátreit í viðmótinu: Afritaðu öryggisafrit í hlutgeymslu um leið og þau eru búin til.

Af hverju þurfum við þessa afritunarstillingu?

Það er jafnvel betra að umorða spurninguna á þennan hátt: hvaða áhættu erum við vernduð fyrir með hjálp hennar? Hvaða vandamál hjálpar það okkur að leysa?

Svarið er augljóst: auðvitað er þetta endurheimt gagna. Ef við höfum fullkomið afrit af staðbundnum gögnum á hlutgeymslunni, þá er sama hvað verður um vöruna okkar, við getum alltaf endurheimt gögn úr skrám sem eru staðsettar í skilyrtu Amazon.

Svo skulum við fara í gegnum mögulegar aðstæður, frá einföldustu til flóknari.

Einfaldasta ógæfan sem getur fallið á hausinn á okkur er óaðgengileg einni af skrám í öryggisafritunarkeðjunni.

Sorglegri saga er að eitt af umfangi SOBR geymslunnar okkar brotnaði.

Það versnar enn þegar allt SOBR geymslan er orðin óaðgengileg, en skotsvæðið virkar.
Og allt er mjög slæmt - þetta er þegar varaþjónninn deyr og fyrsta löngun þín er að reyna að hlaupa að kanadísku landamærunum eftir tíu mínútur.

Nú skulum við skoða hverja stöðu fyrir sig.

Þegar við höfum tapað einni (og jafnvel nokkrum) öryggisafritsskrám, þá þurfum við bara að hefja endurskönnun geymslunnar og týndu skránni verður skipt út fyrir dummy skrá. Og með því að nota endurvökvunarferlið (sem fjallað var um í upphafi greinarinnar) mun notandinn geta hlaðið niður gögnum frá skotsvæðinu í staðbundna geymslu.

Nú er staðan flóknari. Gerum ráð fyrir að SOBR okkar samanstandi af tveimur sviðum sem keyra í Performance mode, sem þýðir að .vbk og .vib okkar dreifast yfir þau í frekar ójöfnu lagi. Og á einhverjum tímapunkti verður eitt af umfangunum ófáanlegt og notandinn þarf brýn að endurheimta vélina, hluti af gögnunum sem liggja einmitt á þessu marki.

Notandinn ræsir endurheimtarhjálpina, velur punktinn sem hann vill endurheimta á og á meðan hann vinnur kemst hann að því að hann hefur ekki öll nauðsynleg gögn fyrir endurheimt á staðnum og þarf því að hlaða niður úr afkastagetutökunni gallerí. Á sama tíma verður blokkum sem eru eftir á staðbundinni geymslu ekki hlaðið niður úr skýinu. Dýrð sé endurheimtarvísitölunni (já, það var líka nefnt í upphafi greinarinnar).

Undirgerð þessa máls er að öll SOBR geymslan varð óaðgengileg. Í þessu tilviki höfum við ekkert að afrita úr staðbundinni geymslu og allar blokkir eru sóttar úr skýinu.

Og áhugaverðasta ástandið er að varaþjónninn dó. Það eru tveir valkostir hér: stjórnandinn er frábær og gerði öryggisafrit af stillingum og stjórnandinn er sjálfur illur Pinocchio og gerði ekki afrit af stillingum.

Í fyrra tilvikinu mun það vera nóg fyrir hann að einfaldlega setja upp hreina uppsetningu á VBR einhvers staðar og endurheimta gagnagrunn sinn úr öryggisafriti með stöðluðum aðferðum. Í lok þessa ferlis mun allt fara aftur í eðlilegt horf. Eða það verður endurheimt samkvæmt einni af atburðarásunum hér að ofan.

En ef stjórnandinn er annaðhvort hans eigin óvinur, eða öryggisafritið varð einnig fyrir epískri bilun, þá munum við jafnvel ekki láta hann í hendur örlaganna. Fyrir þetta tilvik höfum við kynnt nýtt verklag sem kallast Import Object Storage. Það gerir þér kleift að sleppa því að endurgera SOBR geymslu handvirkt og tengja skotsvæði við hana með síðari endurskönnun, og einfaldlega bæta geymsluhlut við Vim viðmótið og keyra innflutningsgeymsluferli. Það eina sem getur staðið í vegi milli þín og öryggisafritanna þinna er beiðni um að slá inn lykilorð ef afritin þín voru dulkóðuð.

Þetta snýst líklega allt um Copy Mode og við höldum áfram

Lokaður háttur

Meginhugmyndin er sú að ný afrit geta ekki birst á völdum SOBR umfangi geymslunnar. Fyrir v10 vorum við aðeins með viðhaldsstillingu, þegar öll vinna með geymsluna var algjörlega bönnuð. Eins konar harðkjarnahamur til að leggja niður geymslu, þar sem aðeins Evacuate hnappurinn er tiltækur, sem flytur afrit að öðru leyti einu sinni.

Og lokaður háttur er eins konar „mjúkur“ valkostur: við bönnum stofnun nýrra öryggisafrita og eyðum smám saman gömlum í samræmi við valinn varðveislu, en í því ferli missum við ekki getu til að endurheimta frá geymdum punktum. Mjög gagnlegur hlutur þegar við annað hvort erum með vélbúnað sem er að líða undir lok og þurfum að skipta um hann, eða við þurfum bara að losa hann fyrir eitthvað mikilvægara, en það er hvergi að taka það og færa allt í einu. Eða það er ekki hægt að eyða því.

Í samræmi við það er meginreglan um rekstur frekar einföld: það er nauðsynlegt að banna allar skrifaaðgerðir (útlit nýrra gagna), yfirgefa lestur (endurheimt) og eyða (geymsla).

Hægt er að nota báðar stillingar samtímis, en hafðu í huga að viðhald hefur meiri forgang.

Sem dæmi skaltu íhuga SOBR sem samanstendur af tveimur hlutum. Gerum ráð fyrir að fyrstu fjóra dagana höfum við búið til öryggisafrit í Forever Forever Incremental ham, og síðan innsiglum við umfangið. Þetta leiðir til þess að við byrjum að búa til nýjan virka fulla á öðru tiltæku marki. Ef varðveisla okkar er fjögur, þá er henni eytt með góðri samvisku þegar öll keðjan sem staðsett er á innsigluðu umfanginu fer út fyrir mörk sín.

Það eru aðstæður þegar eyðing á sér stað fyrr. Til dæmis er þetta Áfram stigvaxandi með reglubundnum fyllingum. Ef við bjuggum til fullt afrit fyrstu tvo dagana og á fimmtudaginn ákveðum við að innsigla geymsluna, þá á föstudaginn, þegar nýtt öryggisafrit er búið til, verður skránni fyrir mánudaginn eytt vegna þess að það eru engin ósjálfstæði að þessu leyti. Og atriðið sjálft er ekki háð neinum. Síðan bíðum við þar til fjórir punktar eru búnir til á tiltæku umfangi og eyðum hinum þremur út, sem ekki er hægt að eyða óháð hvor öðrum.

Hlutirnir eru einfaldari með Reverse Incremental. Í henni eru elstu punktarnir ekki háðir neinu og hægt er að eyða þeim á öruggan hátt. Þess vegna, um leið og nýtt .vbk er búið til á nýju umfangi, verður gömlu .vrbs eytt einu af öðru.

Við the vegur, hvers vegna búum við til nýjan .vbk í hvert skipti: ef við bjuggum það ekki til, heldur héldum áfram gömlu keðjunni af þrepum, þá myndi gamla .vbk frjósa í óendanlega langan tíma í hvaða ham sem er og koma í veg fyrir eyðingu þess. Þess vegna var ákveðið að um leið og umfangið er innsiglað, búum við til fullt afrit af ókeypis umfanginu.

Hlutirnir eru flóknari með afkastagetu skotsvæðisins.

Fyrst skulum við líta á afritunarstillingu. Gerum ráð fyrir að við værum virkir að búa til öryggisafrit í fjóra daga og síðan var skotsvæðið lokað. Við eyðum engu, en þolum auðmýkt varðveisluna, eftir það eyðum við gögnunum af skotsvæðinu.

Um það bil það sama gerist í flutningsham - við bíðum eftir lagfæringunni, eyðum því gamla í staðbundnu geymslunni og eyðum því sem er geymt í hlutgeymslunni.

Áhugavert dæmi með Forever forward incremental. Við setjum upp varðveislu á þremur stöðum og byrjum að taka öryggisafrit á mánudaginn, sem eru reglulega afrituð í skýið. Eftir að geymslunni hefur verið lokað er haldið áfram að búa til afrit og halda þremur punktum, en gögnin sem geymd eru í geymslustikunni eru áfram háð og ekki er hægt að eyða þeim. Þess vegna bíðum við þangað til á fimmtudaginn, þegar .vbk okkar fer út fyrir varðveislu, og aðeins þá eyðum við rólegu öllu vistuðu keðjunni.

Og lítill fyrirvari: öll dæmi hér eru sýnd með einni vél. Ef þú ert með nokkra af þeim í öryggisafritinu þínu, þá mun lagfæring þeirra vera mismunandi eftir því hvort Active Full var gert eða ekki.

Það er í rauninni allt sem þarf til. Svo skulum við halda áfram að harðkjarna eiginleikanum -

Óbreytileiki

Eins og með fyrri atriðin er það fyrsta hvaða vandamál þessi aðgerð leysir. Um leið og við hleðum upp öryggisafritum okkar einhvers staðar til geymslu, þá er mikill vilji til að tryggja öryggi þeirra, það er að banna líkamlega eyðingu þeirra og hvers kyns breytingum meðan á tiltekinni varðveislu stendur. Þar á meðal stjórnendur, þar á meðal undir rótarreikningum þeirra. Þetta gerir þér kleift að vernda þau gegn skemmdum af slysni eða af ásetningi. Allir sem vinna með AWS gætu hafa rekist á svipaðan eiginleika sem kallast Object Lock.

Nú skulum við líta á stillinguna almennt og kafa síðan ofan í smáatriðin. Í dæminu okkar verður óbreytanleiki virkur fyrir skotsvæði okkar með getu í fjóra daga. Og afritunarstillingin er virkjuð í öryggisafritinu.

Óbreytanleiki hefur ekki samskipti við almenna varðveislu á nokkurn hátt. Það bætir til dæmis ekki við aukastigum eða neitt slíkt. Það er bara að einstaklingur getur ekki eytt afritaskrám innan fjögurra daga. Ef þú tekur öryggisafrit á mánudaginn geturðu aðeins eytt skránni á föstudeginum.

Öll áður útskýrð hugtök um ofþornun, vísitölur og lýsigögn halda áfram að virka nákvæmlega eins. En með einu skilyrði - blokkin er ekki aðeins stillt fyrir gögn, heldur einnig fyrir lýsigögn. Þetta er gert ef slægur árásarmaður ákveður að eyða lýsigagnagagnagrunninum okkar og til að koma í veg fyrir að gagnablokkir breytist í gagnslaus tvöfaldur möl.

Nú er frábær tími til að útskýra blokkakynslóðartækni okkar. Eða blokk kynslóð. Til að gera þetta skaltu íhuga ástandið sem leiddi til útlits þess.

Tökum sex daga tímakvarða og hér fyrir neðan munum við merkja þann tíma sem væntanlegur rennur út óbreytanleika. Á fyrsta degi tökum við og búum til skrá sem samanstendur af gagnablokk a og lýsigögnum hans. Ef óbreytanleiki er stilltur á þrjá daga er rökrétt að gera ráð fyrir að á fjórða degi verði gögnunum opnað og þeim eytt. Á öðrum degi munum við bæta við nýrri skrá2, sem samanstendur af blokk b með sömu stillingum. Enn þarf að fjarlægja blokk a á fjórða degi. En á þriðja degi gerist eitthvað hræðilegt - File3 skrá er búin til, sem samanstendur af nýjum blokk d og tengli á gamla blokk a. Þetta þýðir að fyrir blokk og óbreytanleika fána hennar verður að endurstilla á nýja dagsetningu, sem er færð yfir á sjötta daginn. Og hér kemur upp vandamál - í raunverulegum afritum er mikill fjöldi slíkra blokka. Og til þess að lengja óbreytanleg tímabil þeirra þarftu að gera gríðarlegan fjölda beiðna í hvert skipti. Og í rauninni verður þetta næstum endalaust daglegt ferli, þar sem með miklum líkum munum við finna stífa stafla af tvíteknum kubbum með hverju eintaki. Hvað þýðir mikill fjöldi beiðna frá veitendum hlutageymslu? Rétt! Stór reikningur í lok mánaðarins.

Og til þess að afhjúpa ekki uppáhalds viðskiptavini þína fyrir umtalsverða peninga, var blokkaframleiðslukerfið fundið upp. Þetta er viðbótartímabil sem við bætum við uppsett óbreytanleg tímabil. Í dæminu hér að neðan er þetta tímabil tveir dagar. En þetta er bara dæmi. Í raun og veru nota þeir sína eigin formúlu, sem gefur um það bil tíu daga til viðbótar á mánaðarlegum læsingu.

Við skulum halda áfram að íhuga sömu aðstæður, en með blokkamyndun. Á fyrsta degi búum við til skrá1 úr blokk a og lýsigögnum. Við leggjum saman kynslóðartímabilið og óbreytanleikann - þetta þýðir að tækifæri til að eyða skránni verður á sjötta degi. Ef á öðrum degi búum við til File2, sem samanstendur af blokk b og hlekk til að loka a, þá gerist ekkert við væntanlegan eyðingardag. Hún stóð eins og hún gerði á sjötta degi. Og þannig erum við að reyna að spara peninga á fjölda beiðna. Eina staðan þegar hægt er að færa frestinn til er ef kynslóðatímabilið er útrunnið. Það er, ef á þriðja degi nýja File3 inniheldur tengil til að loka á a, þá mun kynslóð 2 bætast við þar sem Gen1 er þegar útrunnið. Og væntanleg dagsetning fyrir eyðingu blokk a mun færast yfir á áttunda daginn. Þetta gerir okkur kleift að draga verulega úr fjölda beiðna um að lengja líftíma aftvíliðaða blokka, sem sparar viðskiptavinum tonn af peningum.

Tæknin sjálf er í boði fyrir notendur S3 og S3 samhæfðs vélbúnaðar, þar sem framleiðendur tryggja að útfærsla þeirra sé ekki frábrugðin Amazon. Þess vegna er svarið við lögmætu spurningunni hvers vegna Azure er ekki stutt - þeir hafa svipaðan eiginleika, en það virkar á stigi gáma, ekki einstakra hluta. Við the vegur, Amazon sjálft er með hlutlæsingu í tveimur stillingum: samræmi og stjórnun. Í öðru tilvikinu er enn möguleiki á að besti stjórnandinn fyrir ofan stjórnendur og rót fyrir ofan rætur, þrátt fyrir hlutlæsinguna, eyði gögnunum samt. Ef um fylgni er að ræða, er allt þétt neglt og enginn getur eytt afritunum. Jafnvel Amazon stjórnendur (samkvæmt opinberum yfirlýsingum þeirra). Þetta er hátturinn sem við styðjum.

Og eins og venjulega, nokkrir gagnlegir tenglar:

• á Block Generation í hverju smáatriði.
• Allar upplýsingar um Veeam öryggisafrit og afritun 10 upp á sitt besta
• О Stærðarþrep í smáatriðum

Heimild: www.habr.com