Капацитетен тир (или както го наричаме вътре във Veeam — каптир) се появи още по времето на Veeam Backup and Replication 9.5 Update 4 под името Archive Tier. Заложената в него идея е да се позволи преместването на резервни копия, които са излезли от така нареченото operational restore window, на обектни хранилища. Това помагаше за освобождаване на дисково пространство за потребителите с ограничени ресурси. Тази опция се нарича Move Mode.

За да се извърши това не толкова сложно (както изглежда) действие, е необходимо да се спазят две условия: всички точки от преместваното резервно копие трябва да са извън предходно упоменатото operational restore window, което е зададено в явен вид в UI. И второ: веригата трябва да бъде в така наречения «запечатан вид» (sealed backup chain или Inactive Backup Chain). Тоест, с течение на времето в тази верига не настъпват промени.

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

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

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

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

Както беше

И така, започваме с разглеждане на operational restore window и sealed backup (или както ги наричат в документацията Inactive Backup Chain). Без разбирането на тези понятия по-нататъшното обяснение няма да е възможно.

Както виждаме на картинката, имаме определена резервна верига с блокове данни, която е разположена на Performance tier SOBR репозитория, към който е свързан Capacity Tier. Нашето operational backup window е равно на три дни.

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

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

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

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

В случай на Forward increment с роллбеки, това включва всички роллбеки и .vbk, ако на перфоманс екстентата има още един .vbk.

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

Нека погледнем под капака. Там протича процес, наречен дегидрация — оставяне на празни backup файлове на екстента и преместване на блокове от тези файлове в капасити тиор. За оптимизиране на този процес се използва така нареченият индекс на дегидрация, който позволява да не копираме блокове, които вече са били копирани в капасити тиора.

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

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

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

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

Как стана

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

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

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

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

Ако сравним директно режимите Move и Copy, ще получим:

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

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

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

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

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

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

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

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

А защо ни е този режим на Копиране?

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

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

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

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

По-печалната история е, че един от екстентите на нашия SOBR репозиторий е повреден.

Още по-лошо става, когато целият SOBR репозиторий стане недостъпен, но капасити тир работи.
И съвсем всичко е зле — това е, когато резервният сървър умре и първото ти желание е да опиташ да избягаш до канадската граница за десет минути.

А сега нека разгледаме всяка ситуация поотделно.

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

Сега ситуацията е по-сложна. Да предположим, че нашият SOBR се състои от два екстента, работещи в режим Performance, което означава, че нашите .vbk и .vib са разпределени по тях с доста неравномерен слой. И в определен момент един от екстентите става недостъпен, а на потребителя му е необходимо спешно да възстанови машина, част от данните на която се намират именно на този екстент.

Потребителят стартира помощника за възстановяване, избира точката, до която иска да възстанови, и помощникът осъзнава по време на работа, че няма всички необходими данни за възстановяване локално, и следователно трябва да ги изтегли от капацити тира. При това блоковете, които остават в локалното хранилище, няма да се изтеглят от облака. Слава на restore индекса (да, за него също беше споменато в началото на статията).

Подслучай на този случай — целият репозиторий на SOBR става недостъпен. В такъв случай нямаме какво да копираме от локалните хранилища и всички блокове се изтеглят от облака.

И най-интересната ситуация — резервният сървър е умрял. Тук има два варианта: администраторът е свършил работа и е правил конфигурационни резерви, или администраторът сам е злобен Буратино и не е правил конфигурационен резерв.

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

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

С това относно Copy Mode, вероятно, приключваме и преминаваме към

Sealed Mode

Основната идея е, че на избрания екстент на SOBR хранилището не могат да се появяват нови резервни копия. До версия 10 имахме само Maintenance Mode, при който всякаква работа с хранилището беше напълно забранена. Това е хардкорен режим на извеждане на хранилището от работа, при който единствено бутонът Evacuate е на разположение, премествал резервните копия на друг екстент.

А Sealed mode е своеобразна "мека" версия: забраняваме създаването на нови резервни копия и постепенно изтриваме стари съгласно избрания период на задържане, но в процеса не губим възможността да възстановяваме от съхранените точки. Много полезно, когато или изтича срокът на живот на оборудването и трябва да бъде заменено, или просто трябва да се освободи за нещо по-важно, а нямаме място за просто преместване на всичко на веднъж. Или просто не може да бъде изтрито.

Съответно, принципът на работа е доста прост: необходимо е да забраните всички записи (поява на нови данни), оставяйки четене (възстановявания) и изтриване (задържане).

И двата режима могат да се използват одновременно, само трябва да се има предвид, че при Maintenance приоритетът е по-висок.

Като пример, нека разгледаме SOBR, състоящ се от два екстента. Да предположим, че през първите четири дни сме създавали резервни копия в режим Forward Forever Incremental, а после запечатваме екстента. Това води до иницииране на създаването на нов активен пълен на втория достъпен екстент. Ако нашият период на запазване е четири, когато веригата, разположена на запечатания екстент, излезе извън неговите граници, тя спокойно се изтрива.

Има ситуации, при които премахването се случва по-рано. Например, когато става въпрос за Forward incremental с периодични фулове. Ако през първите два дни сме създавали фул бекъпи, а в четвъртък решаваме да запечатаме репозитория, то в петък, когато се създаде нова фулка, файлът за понеделник ще бъде премахнат, тъй като към тази точка няма зависимости. И самата точка не зависи от никого. След това чакаме да бъдат създадени четири точки на наличния екстент и премахваме останалите три, които не могат да бъдат премахнати независимо една от друга.

По-лесно е с Reverse Incremental. В него най-старите точки не зависят от нищо и могат спокойно да бъдат премахнати. Следователно, веднага щом бъде създаден нов .vbk на новия екстент, старите .vrb ще се премахват по един.

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

По-сложни са нещата с капасити тиара.

Нека първо разгледаме copy mode. Да предположим, че през четири дни активно сме създавали бекъпи, а след това капасити тиара е била запечатана. Нищо не премахваме, а спокойно изчакваме ретеншъна, след което премахваме данните от капасити тиара.

Около същото се случва и в move mode - изчакваме ретенш, премахваме старото в локалното хранилище, премахваме съ хранящото се в обжект стораджа.

Интересен пример е Forever forward incremental. Настройваме ретенш на три точки и започваме да правим бекъпи от понеделник, които редовно се копират в облака. След запечатването на хранилището, бекъпите продължават да се създават, задържайки три точки, но данните, съхранявани в капасити тиара остават зависими и не могат да бъдат премахнати. Затова изчакваме четвъртък, когато нашият .vbk излиза извън рамките на ретеншъна, и едва тогава спокойно премахваме цялата съхранена верига.

И малка забележка: всички примери тук са показани с една машина. Ако имате няколко в бекъпа, то ретеншът при тях ще бъде различен в зависимост от това дали е направен Active Full или не.

На това, принципно, и всичко. Така че преминаваме към най-хардкорната функция -

Immutability

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

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

Immutability не взаимодейства по никакъв начин с общия период на задържане. Например, той не добавя допълнителни точки или нещо подобно. Просто през четирите дни човек не може да изтрие файловете на резервните копия. Ако в понеделник направите резервно копие, то файлът може да бъде изтрит само в петък.

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

И сега настъпи отличен момент да обясним нашата технология за генериране на блокове. Или block generation. За целта ще разгледаме ситуация, която доведе до нейното съществуване.

Нека вземем времева линия от шест дни и на долната част да отбележим времето на очакваното изтичане на immutability. На първия ден създаваме файл, състоящ се от блок а и неговите метаданни. Ако immutability е зададен на три дни, логично е да предположим, че на четвъртия ден данните ще бъдат отключени и изтрити. На втория ден добавяме нов file2, състоящ се от блок b с идентични настройки. Блок а все още трябва да бъде изтрит на четвъртия ден. Но на третия ден се случва нещо ужасно — създава се файл File3, състоящ се от нов блок d и връзка към стария блок а. Това означава, че за блок а неговият флаг за immutability трябва да бъде пренастроен на нов срок, който се прехвърля на шестия ден. И тук възниква проблем — във реалните бекъпи на такива блокове възникват огромни количества. А за да се удължи техният период на immutability, трябва всеки път да се правят огромно количество заявки. И всъщност, това ще бъде почти безкраен ежедневен процес, тъй като с голяма вероятност при всяко копиране ще намираме огромни пачки дубликати на блокове. А какво означава да имаме голямо количество заявки към доставчиците на обектни хранилища? Точно така! Огромна сметка в края на месеца.

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

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

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