Нивото на капацитет (или како што го нарекуваме внатре Vim - captir) се појави уште во деновите на Veeam Backup и Replication 9.5 Update 4 под името Archive Tier. Идејата зад него е да се овозможи преместување на резервните копии што паднале од таканаречениот прозорец за оперативно обновување во складирање на објекти. Ова помогна да се расчисти просторот на дискот за оние корисници кои имаа малку од него. И оваа опција беше наречена Move Mode.

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

Но, во VBR v10, концептот беше дополнет со нови функции - Copy Mode, Sealed Mode и се појави нешто со тешко изговорливо име Immutability.

Ова се фасцинантните работи за кои ќе зборуваме денес. Прво, за тоа како функционираше во VBR9.5u4, а потоа и за промените во десеттата верзија.

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

• Без трошка жалење. Автор на статијата.

Како што беше

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

Како што гледаме на сликата, имаме еден вид резервен синџир со податочни блокови, кој се наоѓа на Performance tier SOBR на складиштето на кое е поврзан Capacity Tier. Нашиот оперативен резервен прозорец е три дена.

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

Но, што точно се подразбираше под запечатен синџир и што може да се испрати до стрелиштето со капацитет во ажурирањето 4?

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

Во случај на Reverse, сите овие се датотеки што не спаѓаат во оперативниот прозорец.

Во случај на зголемување нанапред со враќање назад, сите овие се враќања и .vbk, доколку има друго .vbk на степенот на изведба

Сега да ја разгледаме опцијата за работа со синџири за резервна копија. Овде се транспортираа само предмети кои спаѓаат под задржување на GFS. Бидејќи сè што е зачувано во поновите синџири за резервни копии може да се промени на еден или друг начин.

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

Ајде да видиме како изгледа ова со пример: Да речеме дека имаме .vbk што излезе од прозорецот на трансакцијата и припаѓа на запечатен синџир. Тоа значи дека го имаме целосното право да го преместиме на стрелиштето со капацитет. Во моментот на преместување, датотеката со метаподатоци се креира во цртичката на капацитетот и блоковите на пренесената датотека. Датотеката со метаподатоци на ниво на врска опишува од кои блокови се состои нашата датотека. Во случајот на сликата, нашата прва датотека се состои од блокови a, b, c и метаподатоците содржат врски до овие блокови. Кога имаме втора датотека .vbk, подготвена за движење и која се состои од блокови a, b и d, ние, анализирајќи го индексот на дехидрација, разбираме дека треба да се пренесе само блокот d. И нејзината датотека со метаподатоци ќе содржи врски до два претходни блока и еден нов.

Според тоа, процесот на пополнување на овие празни места назад со податоци се нарекува рехидратација. Веќе користи сопствен индекс за рехидратација, базиран на најстарата .vbk-датотека на локалниот степен на изведба. Односно, ако корисникот сака да врати датотека од стрелиштето со капацитет, прво креираме индекс на блоковите од најстарата целосна резервна копија и ги пренесуваме само блоковите што недостасуваат од галеријата за снимање со капацитет. Во случајот прикажан на сликата, за да се рехидрира FullBackup1.vbk според индексот на рехидратација, потребен ни е само блок C, кој го земаме од стрелиштето со капацитет. Ако објектот за складирање облак служи како опсег за стрелање со капацитет, тоа ви овозможува да заштедите огромни суми пари.

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

Но, повеќе индекси за богот на индексите! Има и индекс за обновување на податоци! Кога ќе почнеме да обновуваме машина сместена во цртичката за капацитет, ќе читаме само уникатни блокови на податоци што не се во цртичката за изведба.

Како се случи тоа?

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

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

Во голема мера се заснова на постојните технологии, но носи сосема поинаква логика на употреба. 

Целта на овој режим е да се осигура дека сите податоци лоцирани на локално ниво имаат копија во цртичката на капацитетот.

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

• Само запечатениот синџир може да се помести. Во случај на режим на копирање, апсолутно сè се пренесува, без оглед на тоа што се случува во резервната работа.
• Преместувањето се активира кога датотеките ги надминуваат границите на оперативниот прозорец за резервна копија, а копирањето се активира веднаш штом ќе се појави резервната датотека.
• Следењето на новите податоци за копирање се случува постојано, а за преместување се активираше еднаш на секои 4 часа.

Разгледувајќи го новиот режим, предлагам да преминеме од едноставни примери на сложени.

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

Процесот зад ова е сè уште дехидрација како што е опишано погоре. Во режимот за копирање, исто така, се грижи да не ги копираме блоковите што се веќе на нашето складирање. Единствената разлика е во тоа што ако во режим на филм ги заменивме вистинските датотеки со лажни датотеки, тука не ги допираме на кој било начин и оставаме сè како што е. Инаку, тоа е токму истиот индекс на дехидрација, кој внимателно се труди да ви заштеди пари и време.

Се поставува прашањето - ако го погледнете UI, постои можност да ги изберете двете опции истовремено. Како ќе функционира таков комбиниран режим?

Ајде да сфатиме.

Почетокот е стандарден: резервната датотека се креира и се копира веднаш. На него се создава прираст и исто така се копира. Ова се случува до моментот кога ќе сфатиме дека датотеките го напуштиле нашиот оперативен прозорец и се појавил запечатен синџир. Во овој момент вршиме операција за дехидрација и ги заменуваме овие датотеки со лажни датотеки. Се разбира, ништо не копираме повторно на капацитетот за стрелиште.

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

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

Уште подобро е да се преформулира прашањето вака: од какви ризици сме заштитени со негова помош? Кој проблем ни помага да го решиме?

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

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

Наједноставната несреќа што може да ни падне на глава е непристапноста на една од датотеките во синџирот за резервни копии.

Потажна е приказната што пукна една од областите на нашето складиште на СОБР.

Станува уште полошо кога целото складиште на SOBR стана недостапно, но опсегот за стрелање со капацитет работи.
И сè е навистина лошо - ова е кога резервниот сервер умира и вашата прва желба е да се обидете да трчате до канадската граница за десет минути.

Сега да ја разгледаме секоја ситуација одделно.

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

Сега ситуацијата е покомплицирана. Да претпоставиме дека нашиот SOBR се состои од два степена што работат во режим на изведба, што значи дека нашите .vbk и .vib се распоредени над нив во прилично нерамномерен слој. И во одреден момент во времето, една од рамнините станува недостапна, а корисникот итно треба да ја обнови машината, чиј дел од податоците лежат токму на овој обем.

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

Подтип на овој случај е дека целото складиште на SOBR стана недостапно. Во овој случај, немаме што да копираме од локалното складирање, а сите блокови се преземаат од облакот.

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

Во првиот случај, ќе му биде доволно едноставно да распореди чиста инсталација на VBR некаде и да ја врати нејзината база на податоци од резервна копија користејќи стандардни средства. На крајот од овој процес, сè ќе се врати во нормала. Или ќе биде обновен според едно од горенаведените сценарија.

Но, ако администраторот е или свој непријател, или резервната копија на конфигурацијата исто така претрпе епски неуспех, тогаш дури и овде нема да го оставиме на милост и немилост. За овој случај воведовме нова процедура наречена Складирање на увозни објекти. Ви овозможува да го прескокнете процесот на рачно повторно креирање на складиштето SOBR и прикачување на стрелиште со капацитет на него со последователно повторно скенирање, и едноставно да додадете објект за складирање на интерфејсот на Vim и да ја извршите процедурата за складирање на увоз на складиште. Единственото нешто што може да застане на патот помеѓу вас и вашите резервни копии е барањето да внесете лозинка доколку вашите резервни копии се шифрирани.

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

Запечатен режим

Главната идеја е дека новите резервни копии не можат да се појават на избраниот SOBR опсег на складиштето. Пред v10, имавме само режим на одржување, кога било каква работа со складиштето беше целосно забранета. Еден вид хардкор режим за исклучување на складиштето, каде што е достапно само копчето Evacuate, кое еднократно ги транспортира резервните копии до друг степен.

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

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

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

Како пример, земете го SOBR кој се состои од два степена. Да претпоставиме дека во првите четири дена креиравме резервни копии во режимот Forward Forever Incremental, а потоа го запечатуваме обемот. Ако нашето задржување е четири, тогаш кога целиот синџир лоциран на запечатениот обем ги надминува своите граници, се брише со чиста совест.

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

Работите се поедноставни со Reverse Incremental. Во него, најстарите точки не зависат од ништо и можат безбедно да се избришат. Затоа, штом се создаде нов .vbk на нова мера, старите .vrbs ќе се бришат еден по еден.

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

Работите се покомплицирани со капацитетот на стрелиштето.

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

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

Интересен пример со Forever forward incremental. Инсталираме задржување на три точки и почнуваме да правиме резервни копии од понеделник, кои редовно се копираат во облакот. По запечатувањето на складиштето, продолжуваат да се креираат резервни копии, одржувајќи три точки, но податоците зачувани во цртичката на капацитетот остануваат зависни и не можат да се избришат. Затоа, чекаме до четврток, кога нашиот .vbk оди подалеку од задржувањето и дури тогаш мирно го бришеме целиот зачуван синџир.

И мало одрекување: сите примери овде се прикажани со една машина. Ако имате неколку од нив во вашата резервна копија, тогаш нивното ретуширање ќе се разликува во зависност од тоа дали Active Full е направен или не.

Тоа е во основа сè што има во тоа. Значи, да преминеме на најтврдокорната карактеристика -

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

Како и со претходните точки, првото нешто е каков проблем решава оваа функција. Веднаш штом ќе ги поставиме нашите резервни копии некаде за складирање, постои силна желба да се гарантира нивната безбедност, односно физички да се забрани нивното бришење и каква било промена за време на одредено задржување. Вклучувајќи администратори, вклучително и под нивните root сметки. Ова ви овозможува да ги заштитите од случајно или намерно оштетување. Секој кој работи со AWS можеби наишол на слична карактеристика наречена Object Lock.

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

Непроменливоста не е во интеракција со општото задржување на кој било начин. На пример, не додава дополнителни поени или нешто слично. Едноставно, едно лице не може да избрише резервни датотеки во рок од четири дена. Ако направите резервна копија во понеделник, ќе можете да ја избришете нејзината датотека само во петок.

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

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

Да земеме временска скала од шест дена и подолу ќе го означиме времето на очекуваното истекување на непроменливоста. Првиот ден земаме и создаваме датотека која се состои од податочен блок a и неговите метаподатоци. Ако непроменливоста е поставена на три дена, логично е да се претпостави дека на четвртиот ден податоците ќе бидат отклучени и избришани. Вториот ден ќе додадеме нова датотека2, составена од блок b со истите поставки. Блокот a треба да се отстрани четвртиот ден. Но, третиот ден се случува нешто страшно - се креира датотека File3, која се состои од нов блок d и врска до стариот блок a. Ова значи дека за блок и неговата непроменливост, знамето мора да се ресетира на нов датум, кој е преместен на шестиот ден. И тука се појавува проблем - во вистински резервни копии има огромен број такви блокови. А за да го продолжите периодот на нивната непроменливост, секој пат треба да направите огромен број барања. И всушност, ова ќе биде речиси бесконечен дневен процес, бидејќи со висок степен на веројатност ќе најдеме големи купишта од дупликат блокови со секоја копија. Што значат голем број барања од даватели на складирање на објекти? Во право! Огромна сметка на крајот на месецот.

И за да не ги изложите вашите омилени клиенти за значителни пари, беше измислен механизмот за генерирање блокови. Ова е дополнителен период што го додаваме на поставениот период на непроменливост. Во примерот подолу, овој период е два дена. Но, ова е само пример. Во реалноста, тие користат своја формула, која дава приближно десет дополнителни дена за време на месечното заклучување.

Да продолжиме да ја разгледуваме истата ситуација, но со генерирање блокови. Првиот ден создаваме датотека 1 од блок а и метаподатоци. Го собираме периодот на генерирање и непроменливоста - тоа значи дека можноста за бришење на датотеката ќе биде на шестиот ден. Ако на вториот ден создадеме File2, кој се состои од блок b и врска до блок a, тогаш ништо не се случува со очекуваниот датум на бришење. Таа стоеше како што стоеше на шестиот ден. И на тој начин се обидуваме да заштедиме пари на бројот на барања. Единствената ситуација кога рокот може да се помести е ако периодот на генерирање е истечен. Односно, ако на третиот ден новата датотека 3 содржи врска за блокирање a, тогаш генерацијата 2 ќе биде додадена бидејќи Gen1 веќе е истечен. И очекуваниот датум за бришење на блок a ќе се префрли на осмиот ден. Ова ни овозможува драматично да го намалиме бројот на барања за продолжување на животниот век на дедупликираните блокови, што на клиентите им заштедува еден тон пари.

Самата технологија е достапна за корисниците на хардвер компатибилен со S3 и S3, чии производители гарантираат дека нивната имплементација не се разликува од онаа на Amazon. Оттука и одговорот на легитимното прашање зошто Azure не е поддржан - тие имаат слична карактеристика, но таа работи на ниво на контејнери, а не на поединечни објекти. Патем, самиот Амазон има заклучување на објекти во два режима: усогласеност и управување. Во вториот случај, останува можноста најголемиот админ над администраторите и коренот над корените, и покрај заклучувањето на објектот, сепак да ги брише податоците. Во случај на усогласеност, сè е цврсто заковано и никој не може да ги избрише резервните копии. Дури и администраторите на Амазон (според нивните официјални изјави). Ова е режимот што го поддржуваме.

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

• на Блок генерација во секој детал.
• Сите информации за Veeam Backup & Replication 10 во најдобар случај
• О Ниво на капацитет во детали

Извор: www.habr.com