Ниво капацитета (или како га зовемо унутар Вим-а - цаптир) појавио се још у данима Вееам Бацкуп анд Реплицатион 9.5 Упдате 4 под именом Арцхиве Тиер. Идеја иза тога је да омогући премештање резервних копија које су испале из такозваног прозора оперативног враћања у складиште објеката. Ово је помогло да се ослободи простор на диску за оне кориснике који су га имали мало. А ова опција се звала Мове Моде.

Да бисте извршили ову једноставну (како се чини) радњу, било је довољно испунити два услова: све тачке из премештене резервне копије морају бити ван граница горе поменутог оперативног прозора за враћање, који је експлицитно подешен у корисничком интерфејсу. И друго: ланац мора бити у такозваном „запечаћеном облику“ (запечаћени резервни ланац или неактивни резервни ланац). Односно, у овом ланцу не долази до промена током времена.

Али у ВБР в10 концепт је допуњен новим функцијама – појавила се Цопи Моде, Сеалед Моде и ствар са тешко изговорљивим именом Иммутабилити.

Ово су фасцинантне ствари о којима ћемо данас причати. Прво о томе како је то функционисало у ВБР9.5у4, а затим о променама у десетој верзији.

И нека ми опросте шампиони чистог језика, али превише је појмова који се не могу превести.
Дакле, овде ће бити много англицизама.
И пуно гифова.
И слике.

• Без и најмањег жаљења. Аутор чланка.

Као што је био

Па, хајде да почнемо са анализом оперативног прозора за враћање и запечаћене резервне копије (или како се зову у документацији ланца неактивних резервних копија). Без њиховог разумевања, даље објашњење неће бити могуће.

Као што видимо на слици, имамо неку врсту резервног ланца са блоковима података, који се налази на нивоу перформанси СОБР спремишта на које је повезан ниво капацитета. Наш оперативни резервни период је три дана.

Сходно томе, .вбк креиран у понедељак затвара претходни ланац, чији је прозор постављен на три дана. А то значи да можете безбедно да почнете да транспортујете све старије од ова три дана на стрелиште.

Али шта се тачно подразумевало под запечаћеним ланцем и шта је могло да се пошаље на стрелиште капацитета у ажурирању 4?

За Инкрементално напред, знак заптивања ланца је стварање нове потпуне резервне копије. И није важно како се добија ова потпуна резервна копија: узимају се у обзир и синтетичке пуне и активне пуне резервне копије.

У случају Реверсе, то су све датотеке које не спадају у оперативни прозор.

У случају повећања унапред са враћањем, ово су све враћања и .вбк, ако постоји још један .вбк на опсегу перформанси

Сада размотримо опцију рада са ланцима резервних копија. Овде су транспортовани само предмети који потпадају под ГФС задржавање. Јер све што је ускладиштено у новијим ланцима резервних копија може се променити на овај или онај начин.

Сада погледајмо испод хаубе. Тамо се дешава процес који се зове дехидрација - остављајући празне резервне датотеке на екстенту и превлачећи блокове из ових датотека у опсег снимања капацитета. Да би се оптимизовао овај процес, користи се такозвани индекс дехидратације, који вам омогућава да избегнете копирање блокова који су већ копирани на стрелиште капацитета.

Да видимо како ово изгледа на примеру: Рецимо да имамо .вбк који је изашао из прозора трансакције и припада запечаћеном ланцу. То значи да имамо пуно право да га преместимо у капацитет стрелишта. У тренутку премештања, датотека са метаподацима се креира у цртици капацитета и блоковима пренете датотеке. Датотека метаподатака на нивоу везе описује од којих блокова се састоји наша датотека. У случају на слици, наш први фајл се састоји од блокова а, б, ц и метаподаци садрже везе до ових блокова. Када имамо други .вбк фајл, спреман за покрет и који се састоји од блокова а, б и д, ми, анализирајући индекс дехидрације, схватамо да је потребно пренети само блок д. А његова датотека са метаподацима ће садржати везе до два претходна блока и једног новог.

Сходно томе, процес попуњавања ових празних простора подацима се назива рехидрација. Већ користи сопствени индекс рехидратације, заснован на најстаријој .вбк датотеци на локалном опсегу перформанси. То јест, ако корисник жели да врати датотеку са стрелишта капацитета, прво креирамо индекс блокова најстарије пуне резервне копије и преносимо само блокове који недостају из галерије капацитета. У случају приказаном на слици, да бисмо рехидрирали ФуллБацкуп1.вбк према индексу рехидратације, потребан нам је само блок Ц, који узимамо са стрелишта капацитета. Ако објекат у облаку за складиштење служи као стрелиште капацитета, то вам омогућава да уштедите огромне количине новца.

Овде се може чинити да је ова технологија идентична оној која се користи у ВАН акцелераторима, али тако се само чини. У акцелераторима, дедупликација је глобална; овде се локална дедупликација користи унутар сваке датотеке на одређеном помаку. Ово се дешава због разлике у задацима који се решавају: овде треба да копирамо велике датотеке пуне резервне копије, а према нашем истраживању, чак и ако између њих прође дуг временски период, овај алгоритам дедупликације даје најбољи резултат.

Али више индекса за бога индекса! Постоји и индекс за опоравак података! Када почнемо да обнављамо машину која се налази у табли капацитета, читаћемо само јединствене блокове података који се не налазе у табли перформанси.

Како је постало

То је све за уводни део. Прилично је детаљан, али као што је горе поменуто, без ових детаља неће бити могуће објаснити како функционишу нове функције. Стога, без даљег одлагања, пређимо на прву.

Режим копирања

У великој мери се заснива на постојећим технологијама, али носи потпуно другачију логику коришћења. 

Сврха овог режима је да обезбеди да сви подаци који се налазе на локалном опсегу имају копију у цртици капацитета.

Ако директно упоредите режиме премештања и копирања, то ће изгледати овако:

• Само запечаћени ланац може да се помера. У случају режима копирања, преноси се апсолутно све, без обзира на то шта се дешава у задатку резервне копије.
• Премештање се покреће када датотеке пређу границе оперативног прозора резервне копије, а копирање се покреће чим се датотека резервне копије појави.
• Праћење нових података за копирање се дешава стално, а за премештање се покреће једном на свака 4 сата.

У разматрању новог режима, предлажем да пређемо са једноставних примера на сложене.

У најчешћем случају, једноставно имамо нове датотеке са инкрементима и једноставно их копирамо у стрелиште капацитета. Без обзира на то који режим се користи у бацкуп послу, без обзира да ли припада запечаћеном делу ланца или не, без обзира да ли нам је истекао оперативни прозор. Само су га узели и копирали.

Процес иза овога је и даље дехидрација као што је горе описано. У режиму копирања, такође осигурава да не копирамо блокове који се већ налазе у нашем складишту. Једина разлика је у томе што ако смо у режиму филма заменили праве датотеке лажним фајловима, овде их ни на који начин не дирамо и остављамо све како јесте. Иначе, то је потпуно исти индекс дехидрације, који пажљиво покушава да уштеди ваш новац и време.

Поставља се питање - ако погледате кориснички интерфејс, постоји могућност да изаберете обе опције истовремено. Како ће функционисати такав комбиновани режим?

Хајде да схватимо.

Почетак је стандардан: датотека резервне копије се креира и одмах копира. Креира се инкремент на њега и такође се копира. То се дешава до тренутка када схватимо да су датотеке напустиле наш оперативни прозор и појавио се запечаћени ланац. У овом тренутку вршимо операцију дехидрације и замењујемо ове датотеке лажним датотекама. Наравно, више ништа не копирамо на стрелиште капацитета.

Сва ова фасцинантна логика је одговорна за само једно поље за потврду у интерфејсу: Копирајте резервне копије у складиште објеката чим се направе.

Зашто нам је потребан овај режим копирања?

Још је боље преформулисати питање на овај начин: од којих ризика смо заштићени уз његову помоћ? Који проблем нам помаже да решимо?

Одговор је очигледан: наравно, ово је опоравак података. Ако имамо комплетну копију локалних података у складишту објеката, онда без обзира шта се дешава са нашим производом, увек можемо да вратимо податке из датотека које се налазе у условном Амазону.

Па хајде да прођемо кроз могуће сценарије, од најједноставнијих до сложенијих.

Најједноставнија несрећа која нам може пасти на главу је недоступност једне од датотека у ланцу резервних копија.

Тужнија прича је да се покварио један од екстената нашег СОБР репозиторија.

Постаје још горе када је читаво складиште СОБР-а постало недоступно, али стрелиште капацитета ради.
И све је заиста лоше - ово је када резервни сервер умре и ваша прва жеља је да покушате да побегнете до канадске границе за десет минута.

Сада погледајмо сваку ситуацију посебно.

Када изгубимо једну (па чак и неколико) резервних датотека, све што треба да урадимо је да покренемо процес поновног скенирања спремишта, а изгубљена датотека ће бити замењена лажном датотеком. А користећи процес рехидрације (о коме је било речи на почетку чланка), корисник ће моћи да преузме податке са стрелишта капацитета у локално складиште.

Сада је ситуација компликованија. Претпоставимо да се наш СОБР састоји од два екстента који раде у режиму перформанси, што значи да су наши .вбк и .виб распоређени преко њих у прилично неуједначеном слоју. И у неком тренутку, један од екстента постаје недоступан, а корисник хитно треба да врати машину, чији део података лежи управо на овом екстенту.

Корисник покреће чаробњак за опоравак, бира тачку до које жели да се врати, а чаробњак, радећи, долази до сазнања да нема све податке потребне за опоравак локално и зато га треба преузети са снимања капацитета галерија. Истовремено, блокови који остају на локалном складишту неће бити преузети из облака. Слава индексу рестаурације (да, поменуто је и на почетку чланка).

Подтип овог случаја је да је читаво СОБР спремиште постало недоступно. У овом случају, немамо шта да копирамо из локалног складишта, а сви блокови се преузимају из облака.

А најинтересантнија ситуација је да је резервни сервер умро. Овде постоје две опције: администратор је сјајан и направио је резервне копије конфигурације, а администратор је и сам зли Пинокио ​​и није направио резервне копије конфигурације.

У првом случају, биће му довољно да једноставно негде постави чисту инсталацију ВБР-а и врати његову базу података из резервне копије стандардним средствима. На крају овог процеса, све ће се вратити у нормалу. Или ће бити обновљен према једном од горе наведених сценарија.

Али ако је администратор или његов сопствени непријатељ, или је резервна копија конфигурације такође претрпела епски неуспех, онда га ни овде нећемо препустити на милост и немилост судбини. За овај случај, увели смо нову процедуру под називом Импорт Објецт Стораге. Омогућава вам да прескочите процес ручног поновног креирања СОБР спремишта и причвршћивања опсега снимања капацитета уз накнадно поновно скенирање, и једноставно додате објекат за складиштење Вим интерфејсу и покренете процедуру Импорт Стораге Репоситори. Једина ствар која може да стане на пут између вас и ваших резервних копија је захтев за уношење лозинке ако су ваше резервне копије шифроване.

Ово је вероватно све о режиму копирања и прелазимо на њега

Сеалед Моде

Главна идеја је да се нове резервне копије не могу појавити на изабраном СОБР опсегу спремишта. Пре в10, имали смо само режим одржавања, када је сваки рад са спремиштем био потпуно забрањен. Нека врста хардцоре режима за искључивање складишта, где је доступно само дугме Евацуате, које преноси резервне копије у другој мери једнократно.

А запечаћени режим је нека врста „меке“ опције: забрањујемо креирање нових резервних копија и постепено бришемо старе према изабраном задржавању, али у том процесу не губимо могућност враћања из сачуваних тачака. Веома корисна ствар када или имамо део хардвера при крају свог века и треба да га заменимо, или га једноставно треба да ослободимо за нешто важније, али нема где да га узмемо и све померимо одједном. Или се не може избрисати.

Сходно томе, принцип рада је прилично једноставан: потребно је забранити све операције писања (појављивање нових података), оставити читање (рестаурације) и брисање (задржавање).

Оба режима се могу користити истовремено, али имајте на уму да одржавање има већи приоритет.

Као пример, узмите СОБР који се састоји од два степена. Претпоставимо да смо прва четири дана правили резервне копије у Форвард Форевер Инцрементал моду, а затим запечатили екстент.То доводи до тога да иницирамо креирање новог активног фулл на другом доступном екстенту. Ако је наше задржавање четири, онда када цео ланац који се налази на запечаћеном опсегу пређе своје границе, брише се чисте савести.

Постоје ситуације када се брисање дешава раније. На пример, ово је инкрементално унапред са периодичним пуњењама. Ако смо правили пуне резервне копије прва два дана, а у четвртак одлучимо да запечатимо спремиште, онда ће у петак, када се направи нова резервна копија, датотека за понедељак бити избрисана јер до ове тачке нема зависности. А сама тачка не зависи ни од кога. Затим чекамо да се креирају четири тачке на доступном екстенту и избришемо преостале три, које се не могу брисати независно једна од друге.

Ствари су једноставније са Реверсе Инцрементал. У њему, најстарије тачке не зависе ни од чега и могу се безбедно избрисати. Стога, чим се нови .вбк креира на новом екстенту, стари .врбс ће се брисати један по један.

Узгред, зашто сваки пут правимо нови .вбк: ако га нисмо направили, већ наставили стари ланац инкремената, онда би се стари .вбк замрзнуо на бесконачно дуго време у било ком режиму, спречавајући његово брисање. Због тога је одлучено да чим се екстент затвори, направимо пуну резервну копију на слободном екстенту.

Ствари су компликованије са капацитетом гађања.

Прво, погледајмо режим копирања. Претпоставимо да смо четири дана активно правили резервне копије, а онда је капацитет стрелишта био запечаћен. Ништа не бришемо, већ понизно трпимо задржавање, након чега бришемо податке са стрелишта капацитета.

Приближно иста ствар се дешава у режиму кретања - чекамо ретуширање, избришемо стари у локалном складишту, а избришемо онај који је сачуван у складишту објеката.

Занимљив пример са Форевер инкременталним напредовањем. Инсталирамо ретенцију на три тачке и почињемо да правимо резервне копије у понедељак, које се редовно копирају у облак. Након затварања складишта, резервне копије настављају да се креирају, задржавајући три тачке, али подаци ускладиштени у табли капацитета остају зависни и не могу се избрисати. Стога чекамо до четвртка, када наш .вбк пређе даље од задржавања, па тек онда мирно избришемо цео сачувани ланац.

И мало одрицање одговорности: сви примери овде су приказани са једном машином. Ако их имате неколико у резервној копији, њихово ретуширање ће се разликовати у зависности од тога да ли је Ацтиве Фулл направљен или не.

То је у суштини све што је ту. Дакле, пређимо на најтврдокорнију функцију -

Непроменљивост

Као и код претходних тачака, прва ствар је који проблем решава ова функција. Чим своје резервне копије отпремимо негде за складиштење, постоји снажна жеља да гарантујемо њихову безбедност, односно да физички забранимо њихово брисање и било какву модификацију током датог задржавања. Укључујући администраторе, укључујући и њихове роот налоге. Ово вам омогућава да их заштитите од случајног или намерног оштећења. Свако ко ради са АВС-ом можда је наишао на сличну функцију под називом Објецт Лоцк.

Сада погледајмо режим уопштено, а затим се удубимо у детаље. У нашем примеру, непроменљивост ће бити омогућена за наше стрелиште капацитета са задржавањем од четири дана. А режим копирања је омогућен у резервној копији.

Непроменљивост ни на који начин не утиче на опште задржавање. На пример, не додаје додатне поене или нешто слично. Једноставно, особа не може да избрише резервне датотеке у року од четири дана. Ако направите резервну копију у понедељак, њен фајл ћете моћи да избришете тек у петак.

Сви претходно објашњени концепти дехидрације, индекси и метаподаци настављају да раде потпуно исто. Али са једним условом - блок је постављен не само за податке, већ и за метаподатке. Ово се ради у случају да лукави нападач одлучи да избрише нашу базу метаподатака и спречи да се блокови података претворе у бескорисну бинарну кашу.

Сада је сјајно време да објаснимо нашу технологију генерисања блокова. Или генерисање блокова. Да бисте то урадили, размотрите ситуацију која је довела до његовог појављивања.

Узмимо временску скалу од шест дана и испод ћемо означити време очекиваног истека непроменљивости. Првог дана узимамо и креирамо датотеку која се састоји од блока података а и његових метаподатака. Ако је непромењивост подешена на три дана, логично је претпоставити да ће четвртог дана подаци бити откључани и избрисани. Другог дана ћемо додати нову датотеку2, која се састоји од блока б са истим подешавањима. Блок а и даље треба уклонити четвртог дана. Али трећег дана се дешава нешто страшно - креира се датотека Филе3 која се састоји од новог блока д и везе до старог блока а. То значи да за блок и његову непромењивост заставица мора бити ресетована на нови датум, који се помера на шести дан. И овде се јавља проблем - у стварним резервним копијама постоји огроман број таквих блокова. А да бисте продужили њихов период непромењивости, сваки пут морате да направите огроман број захтева. И у ствари, ово ће бити скоро бесконачан свакодневни процес, јер ћемо са великом вероватноћом пронаћи огромне хрпе дедуплицираних блокова са сваком копијом. Шта значи велики број захтева од добављача складиштења објеката? Јел тако! Огроман рачун на крају месеца.

А да не бисте из ведра неба разоткрили своје омиљене клијенте за приличан новац, измишљен је механизам за генерисање блокова. Ово је додатни период који додајемо постављеном периоду непроменљивости. У примеру испод, овај период је два дана. Али ово је само пример. У стварности, они користе сопствену формулу, која даје отприлике десет додатних дана током месечног закључавања.

Хајде да наставимо да разматрамо исту ситуацију, али са генерисањем блокова. Првог дана креирамо филе1 од блока а и метаподатака. Сабирамо период генерисања и непромењивост - то значи да ће прилика за брисање датотеке бити шестог дана. Ако другог дана креирамо Филе2, који се састоји од блока б и везе до блока а, онда се ништа не дешава са очекиваним датумом брисања. Стајала је као и шестог дана. И на тај начин покушавамо да уштедимо на броју захтева. Једина ситуација када се рок може померити је ако је истекао период производње. То јест, ако трећег дана нови Филе3 садржи везу за блокирање а, онда ће генерација 2 бити додата пошто је Ген1 већ истекао. А очекивани датум за брисање блока а помериће се на осми дан. Ово нам омогућава да драматично смањимо број захтева за продужење животног века дедуплицираних блокова, што клијентима штеди тону новца.

Сама технологија је доступна корисницима хардвера компатибилног са С3 и С3, чији произвођачи гарантују да се њихова имплементација не разликује од Амазонове. Отуда и одговор на легитимно питање зашто Азуре није подржан – имају сличну функцију, али ради на нивоу контејнера, а не појединачних објеката. Иначе, сам Амазон има закључавање објеката у два начина: усклађеност и управљање. У другом случају, остаје могућност да највећи админ изнад администратора и роот изнад роот-а, упркос закључавању објекта, ипак брише податке. У случају усаглашености, све је чврсто приковано и нико не може да избрише резервне копије. Чак и администратори Амазона (према њиховим званичним изјавама). Ово је режим који подржавамо.

И, као и обично, неколико корисних линкова:

• О томе Блоцк Генератион у сваком детаљу.
• Све информације о Вееам Бацкуп & Реплицатион 10 у свом најбољем
• О Цапацити Тиер у детаље

Извор: ввв.хабр.цом