Capacity Tier (или както го наричаме във Vim - captir) се появи още в дните на Veeam Backup and Replication 9.5 Update 4 под името Archive Tier. Идеята зад него е да направи възможно преместването на резервни копия, които са изпаднали от така наречения прозорец за оперативно възстановяване, в обектно хранилище. Това помогна да се освободи дисково пространство за онези потребители, които разполагаха с малко от него. И тази опция се наричаше Move Mode.

За да се извърши това просто (както изглежда) действие, беше достатъчно да се изпълнят две условия: всички точки от преместения архив трябва да са извън границите на гореспоменатия прозорец за оперативно възстановяване, който е зададен изрично в потребителския интерфейс. И второ: веригата трябва да бъде в така наречената „запечатана форма“ (sealed backup chain или Inactive Backup Chain). Тоест не настъпват промени в тази верига с течение на времето.

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

Това са удивителните неща, за които ще говорим днес. Първо за това как работи във VBR9.5u4, а след това за промените в десетата версия.

И нека ме прощават защитниците на чистия език, но има твърде много термини, които не могат да бъдат преведени.
Така че тук ще има много англицизми.
И много гифчета.
И снимки.

• Без ни най-малко съжаление. Автор на статията.

Както си беше

Е, нека започнем с анализиране на прозореца за оперативно възстановяване и запечатаното архивиране (или както се наричат ​​в документацията на веригата за неактивно архивиране). Без тяхното разбиране по-нататъшното обяснение няма да е възможно.

Както виждаме на снимката, имаме един вид резервна верига с блокове от данни, която се намира на нивото на производителност SOBR на хранилището, към което е свързано ниво на капацитет. Нашият оперативен резервен прозорец е три дни.

Съответно, .vbk, създаден в понеделник, запечатва предишната верига, чийто прозорец е зададен на три дни. А това означава, че можете спокойно да започнете да транспортирате всичко по-старо от тези три дни до стрелбището.

Но какво точно се има предвид под запечатана верига и какво може да бъде изпратено на стрелбището с капацитет в актуализация 4?

За Forward Incremental знак за запечатване на веригата е създаването на нов пълен архив. И няма значение как се получава това пълно архивиране: вземат се предвид както синтетичните пълни, така и активните пълни архиви.

В случая с Reverse това са всички файлове, които не попадат в работния прозорец.

В случай на нарастване напред с връщане назад, това са всички връщания назад и .vbk, ако има друг .vbk в степента на производителност

Сега нека разгледаме опцията за работа с вериги за архивиране на копия. Тук бяха транспортирани само артикули, попадащи под GFS задържане. Тъй като всичко, съхранено в по-нови вериги за архивиране, може да бъде променено по един или друг начин.

Сега нека погледнем под капака. Там възниква процес, наречен дехидратация - оставяне на празни архивни файлове на екстента и плъзгане на блокове от тези файлове към капацитетното стрелбище. За да се оптимизира този процес, се използва така нареченият индекс на дехидратация, който ви позволява да избегнете копирането на блокове, които вече са били копирани в диапазона за стрелба с капацитет.

Нека да видим как изглежда това с пример: Да кажем, че имаме .vbk, който е излязъл от прозореца на транзакцията и принадлежи към запечатана верига. Това означава, че имаме пълното право да го преместим в капацитета на стрелбището. По време на преместването се създава файл с метаданни в тире за капацитет и блокове на прехвърления файл. Файлът с метаданни на ниво връзка описва от какви блокове се състои нашият файл. В случая на снимката нашият първи файл се състои от блокове a, b, c и метаданните съдържат връзки към тези блокове. Когато имаме втори .vbk файл, готов за преместване и състоящ се от блокове a, b и d, ние, анализирайки индекса на дехидратация, разбираме, че само блок d трябва да бъде преместен. И неговият файл с метаданни ще съдържа връзки към два предишни блока и един нов.

Съответно, процесът на запълване на тези празни пространства обратно с данни се нарича рехидратация. Той вече използва свой собствен индекс на рехидратация, базиран на най-стария .vbk файл в локалния екстент на производителността. Тоест, ако потребителят иска да върне файл от капацитета на стрелбището, ние първо създаваме индекс на блоковете на най-стария пълен архив и прехвърляме само липсващите блокове от капацитета на стрелбището. В представения на снимката случай, за да рехидратираме FullBackup1.vbk според индекса на рехидратация, се нуждаем само от блок С, който вземаме от капацитетното стрелбище. Ако облачен обект за съхранение служи като капацитет за стрелбище, това ви позволява да спестите огромни суми пари.

Тук може да изглежда, че тази технология е идентична с използваната в WAN ускорителите, но само изглежда така. В ускорителите дедупликацията е глобална; тук локалната дедупликация се използва във всеки файл при конкретно отместване. Това се дължи на разликата в задачите, които се решават: тук трябва да копираме големи пълни архивни файлове и според нашите изследвания, дори ако минава дълъг период от време между тях, този алгоритъм за дедупликация дава най-добър резултат.

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

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

Това е всичко за уводната част. Той е доста подробен, но както бе споменато по-горе, без тези подробности няма да е възможно да се обясни как работят новите функции. Ето защо, без повече шум, нека преминем към първия.

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

До голяма степен се базира на съществуващи технологии, но носи съвсем различна логика на използване. 

Целта на този режим е да гарантира, че всички данни, намиращи се в локалния екстент, имат копие в тирето на капацитета.

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

• Само запечатаната верига може да бъде преместена. В случай на режим на копиране се прехвърля абсолютно всичко, независимо какво се случва в заданието за архивиране.
• Преместването се задейства, когато файловете надхвърлят границите на прозореца за оперативно архивиране, а копирането се задейства веднага щом се появи архивният файл.
• Мониторингът на нови данни за копиране се извършва постоянно, а за преместване се задейства веднъж на всеки 4 часа.

При разглеждането на новия режим предлагам да преминем от прости примери към сложни.

В най-честия случай просто имаме нови файлове с инкременти и просто ги копираме в капацитетното стрелбище. Независимо какъв режим се използва в заданието за архивиране, независимо дали принадлежи към запечатаната част от веригата или не, независимо дали нашият работен прозорец е изтекъл. Те просто го взеха и го копираха.

Процесът зад това все още е дехидратация, както е описано по-горе. В режим на копиране той също така гарантира, че не копираме блокове, които вече са в нашето хранилище. Единствената разлика е, че ако в режим на филм сме заменили реални файлове с фиктивни файлове, тук не ги докосваме по никакъв начин и оставяме всичко както е. В противен случай това е точно същият индекс на дехидратация, който внимателно се опитва да спести вашите пари и време.

Възниква въпросът - ако погледнете потребителския интерфейс, има възможност да изберете и двете опции едновременно. Как ще работи такъв комбиниран режим?

Нека го разберем.

Началото е стандартно: създава се резервен файл и се копира веднага. Създава се увеличение към него и също се копира. Това се случва до момента, в който разберем, че файловете са напуснали нашия операционен прозорец и се е появила запечатана верига. В този момент извършваме операция по дехидратация и заменяме тези файлове с фиктивни файлове. Разбира се, ние не копираме нищо отново в капацитета на стрелбището.

Цялата тази завладяваща логика е отговорна само за едно квадратче за отметка в интерфейса: Копиране на резервни копия в обектно хранилище веднага щом бъдат създадени.

Защо се нуждаем от този режим на копиране?

Още по-добре е да перифразираме въпроса така: от какви рискове се предпазваме с негова помощ? Какъв проблем ни помага да решим?

Отговорът е очевиден: разбира се, това е възстановяване на данни. Ако имаме пълно копие на локални данни в хранилището на обекта, тогава без значение какво се случва с нашия продукт, винаги можем да възстановим данни от файлове, намиращи се в условния Amazon.

Така че нека преминем през възможните сценарии, от най-простите до по-сложните.

Най-простото нещастие, което може да падне върху главите ни, е недостъпността на един от файловете във веригата за архивиране.

По-тъжната история е, че един от екстентите на нашето SOBR хранилище се повреди.

Още по-лошо става, когато цялото хранилище на 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 със същите настройки. Блокът все още трябва да бъде премахнат на четвъртия ден. Но на третия ден се случва нещо ужасно - създава се файл File3, състоящ се от нов блок d и връзка към стария блок a. Това означава, че за блок и неговия флаг за неизменност трябва да се нулира на нова дата, която се измества на шестия ден. И тук възниква проблем - в реалните резервни копия има огромен брой такива блокове. И за да удължите периода на тяхната неизменност, трябва да правите огромен брой заявки всеки път. И всъщност това ще бъде почти безкраен ежедневен процес, тъй като с голяма степен на вероятност ще открием солидни купчини дедупликирани блокове с всяко копие. Какво означава голям брой заявки от доставчици на обектно съхранение? вярно! Огромна сметка в края на месеца.

И за да не изложите неочаквано любимите си клиенти за значителни пари, беше изобретен механизмът за генериране на блокове. Това е допълнителен период, който добавяме към зададения период на неизменност. В примера по-долу този период е два дни. Но това е само пример. В действителност те използват собствена формула, която дава приблизително десет допълнителни дни по време на месечно заключване.

Нека продължим да разглеждаме същата ситуация, но с генериране на блокове. През първия ден създаваме file1 от блок a и метаданни. Добавяме периода на генериране и неизменността - това означава, че възможността за изтриване на файла ще бъде на шестия ден. Ако на втория ден създадем File2, състоящ се от блок b и връзка към блок a, тогава нищо не се случва с очакваната дата на изтриване. Тя се изправи, както и на шестия ден. И по този начин се опитваме да спестим пари от броя на заявките. Единствената ситуация, когато срокът може да бъде изместен, е ако периодът на генериране е изтекъл. Тоест, ако на третия ден новият File3 съдържа връзка за блокиране на a, тогава поколение 2 ще бъде добавено, тъй като Gen1 вече е изтекъл. А очакваната дата за изтриване на блок а ще се измести на осмия ден. Това ни позволява драстично да намалим броя на заявките за удължаване на живота на дедупликираните блокове, което спестява на клиентите много пари.

Самата технология е достъпна за потребителите на S3 и S3-съвместим хардуер, чиито производители гарантират, че внедряването им не се различава от това на Amazon. Оттук и отговорът на легитимния въпрос защо Azure не се поддържа - те имат подобна функция, но тя работи на ниво контейнери, а не на отделни обекти. Между другото, самата Amazon има заключване на обекти в два режима: съответствие и управление. Във втория случай остава възможността най-големият администратор над администраторите и root над корените, въпреки заключването на обекта, все пак да изтрие данните. В случай на съответствие всичко е здраво заковано и никой не може да изтрие архивите. Дори администраторите на Amazon (според техните официални изявления). Това е режимът, който поддържаме.

И както обикновено, някои полезни връзки:

• Около Генериране на блокове във всеки детайл.
• Цялата информация за Veeam Backup & Replication 10 в най-добрия си вид
• О Ниво на капацитет подробно

Източник: www.habr.com