Capacity Tier (ці як мы завём яго ў сябе ўсярэдзіне віма - капцір) з'явіўся яшчэ ў часы 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, а потым аб зменах у дзясятай версіі.

І хай прабачаць мне прыхільнікі чыстай мовы, але занадта шмат тэрмінаў немагчыма перавесці.
Так што тут будзе процьма англіцызмаў.
І шмат гіфак.
І карцінак.

• Без найменшых шкадаванняў. Аўтар артыкула.

як было

Ну што ж, пачынаем з разбору operational restore window і sealed backup (ці як яны называюцца ў дакументацыі Inactive Backup Chain). Без іх разумення далейшае растлумачыць не атрымаецца.

Як мы бачым на малюнку, у нас ёсць нейкі бекапны ланцужок з блокамі дадзеных, якая размешчана на Performance tier SOBR рэпазітара, да якога падлучаны Capacity Tier. Наша акно аперацыйнага бекапа роўна тром дням.

Адпаведна, створаны ў панядзелак .vbk запячатвае папярэдні ланцужок, акно якога ўсталявана на тры дні. І, значыць, спакойна можна пачынаць адвозіць у капасіці цір усё што старэй гэтых трох дзён.

Але што менавіта мелася на ўвазе пад sealed ланцужком і што магло адпраўляцца ў капасіці цір у update 4?

Для Forward Incremental прыкметай запячатвання ланцужкі з'яўляецца стварэнне новага фула бекапа. І не важна, як гэты фульнік атрымліваецца: лічацца і synthetic full, і active full бекапы.

У выпадку Reverse гэта ўсё файлы, якія не трапляюць у аперацыйнае акно.

У выпадку Forward increment з ролбекамі гэта ўсё ролбекі і .vbk, калі на перфоманс экстэнце ёсць яшчэ адзін .vbk

Цяпер разгледзім варыянт працы з Backup Copy ланцужкамі. Тут адвозілася толькі якое трапляе пад GFS рэтэншн. Таму што ўсё, што захоўваецца ў больш свежых backup copy ланцужках можа быць тым ці іншым спосабам зменена.

Цяпер зазірнем пад капот. Там адбываецца працэс, званы дэгідрацыяй - пакіданне пустышак бекапных файлаў на экстэнце і перацягванне блокаў з гэтых файлаў на капасіці цір. Для аптымізацыі гэтага працэсу выкарыстоўваецца так званы індэкс дэгідрацыі, які дазваляе не капіяваць блокі, якія ўжо былі скапіяваныя ў капасіці цір.

Разгледзім, як гэта выглядае на прыкладзе: выкажам здагадку, што ў нас ёсць .vbk, які выйшаў з аперацыйнага акна і які належыць запячатаным ланцужку. Значыць, мы маем поўнае права перанесці яго ў капасіці цір. У момант пераезду ствараецца файл метададзеных у капасіці працяжнік і блокі пераноснага файла. У файле метададзеных на ўзроўні спасылак апісваецца, з якіх блокаў складаецца наш файл. У выпадку на малюнку наш першы файл складаецца з блокаў a, b, c і ў метададзеных размешчаны спасылкі на гэтыя блокі. Калі ў нас з'яўляецца другі .vbk файл, гатовы да пераезду і які складаецца з блокаў a, b і d, мы, аналізуючы азначнік дэгідрацыі, разумеем, што пераносіць трэба толькі блок d. А яго файл метададзеных будзе змяшчаць спасылкі на два папярэднія блокі і адзін новы.

Адпаведна, працэс зваротнага запаўнення гэтых пустышак дадзенымі называецца регидрацией. Тут выкарыстоўваецца ўжо свой індэкс регидрации, які абапіраецца на самы стары .vbk файл на лакальным перфоманс экстэнце. Гэта значыць калі карыстач жадае вярнуць файл з капасіці ціра, мы спачатку ствараем азначнік блокаў самага старога поўнага бекапа і пераносім з капасіці ціра толькі адсутнічаюць блокі. У выпадку, прадстаўленым на малюнку, каб регидрировать FullBackup1.vbk паводле азначніка регидрации нам бракуе толькі блока З, які мы і забіраем з капасіці ціра. Калі ў якасці капасіці ціра выступае хмарны абжект стородж, гэта дазваляе эканоміць каласальныя грошы.

Тут можа здацца, што гэтая тэхналогія ідэнтычная выкарыстоўванай у WAN Accelerators, але гэта толькі здаецца. У акселератарах дэдуплікацыя глабальная, тутака ж выкарыстоўваецца лакальная ў рамках кожнага файла па вызначаным афсеце. Гэта адбываецца з-за рознасці развязальных задач: тут нам трэба капіяваць вялікія файлы фул бекапаў, і па нашых даследаваннях, нават калі паміж імі праходзіць вялікі перыяд часу, такі алгарытм дэдуплікацыі дае лепшы вынік.

Але больш індэксаў богу індэксаў! Ёсць яшчэ і індэкс для аднаўлення даных! Калі мы запускаем аднаўленне машыны, размешчанай у капасіці працяжнік, то будзем чытаць толькі ўнікальныя блокі дадзеных, якіх няма ў перфоманс працяжнік.

Як стала

На гэтым з уступнай часткай усё. Яна даволі падрабязная, але, як гаварылася вышэй, без гэтых падрабязнасьцяў не атрымаецца растлумачыць, як працуюць новыя функцыі. Таму без лішніх прадмоваў пераходзім да першай.

Рэжым капіявання

У многім заснаваны на існуючых тэхналогіях, аднак нясе ў сабе зусім іншую логіку выкарыстання. 

Мэта гэтага рэжыму - гарантаваць, што ўсе дадзеныя, размешчаныя на лакальным экстэнце, маюць копію ў капасити працяжнік.

Калі параўнаць у лоб Move і Copy рэжымы, то атрымаецца так:

• Перамяшчаць можна толькі запячатаны ланцужок. У выпадку копі рэжыму адвозіцца абсалютна ўсё, незалежна ад таго, што адбываецца ў бекапны джобе.
• Перасоўванне спрацоўвае, калі файлы выходзяць за межы акна аперацыйнага бекапа, а капіяванне спрацоўвае адразу, як толькі з'яўляецца бекапны файл.
• Адсочванне новых дадзеных для капіявання адбываецца ўвесь час, а для перасоўвання спрацоўвала раз у 4 гадзіны.

У разглядзе новага рэжыму прапаную ісці ад простых прыкладаў да складаных.

У самым банальным выпадку ў нас проста з'яўляюцца новыя файлы з інкрыментамі, і мы проста капіюем іх у капасіці цір. Безадносна таго, які рэжым выкарыстоўваецца ў бекапной джобе, безадносна таго, належыць ён да запячатанай часткі ланцужка ці не, безадносна таго, ці скончылася наша аперацыйнае акно. Проста ўзялі і скапіявалі.

Працэс, які стаіць за гэтым - гэта па-ранейшаму дэгідрацыя ў тым выглядзе, як было апісана вышэй. У копі рэжыме яна таксама сочыць, каб мы не капіравалі блокі, якія ўжо ёсць на нашым вартаўніку. Адзінае адрозненне - гэта калі ў мув рэжыме мы замянялі рэальныя файлы файламі пустышкамі, то тут мы іх ніяк не чапаем і пакідаем усё як ёсць. У астатнім гэта роўна такі ж індэкс дэгідрацыі, які старанна імкнецца эканоміць вашыя грошы і час.

Узнікае пытанне - калі паглядзець у UI, то там ёсць магчымасць абраць абедзве опцыі адначасова. Як будзе працаваць такі сумешчаны рэжым?

Давайце разбірацца.

Пачатак стандартны: ствараецца файл бэкапа і адразу капіюецца. Да яго ствараецца інкрымент і таксама капіюецца. Так адбываецца да моманту, калі мы разумеем, што файлы выйшлі з нашага аперацыйнага акна і з'явіўся запячатаны ланцужок. У гэты момант мы выконваем аперацыю дэгідрацыі і замяшчаем гэтыя файлы пустышкамі. Само сабой, паўторна на капасіці цір нічога не капіюем.

За ўсю гэту займальную логіку адказвае ўсяго толькі адна галачка ў інтэрфейсе: .

А навошта нам гэты Copy рэжым?

Нават лепш перафразаваць пытанне так - ад якіх рызык мы абараняемся з яго дапамогай? Якую праблему ён дапамагае нам вырашаць?

Адказ відавочны: вядома ж, гэта аднаўленне дадзеных. Калі ў нас на абжект стораджы ёсць поўная копія лакальных дадзеных, тое ўсё роўна, што здарыцца з нашым продам, мы заўсёды можам аднавіць дадзеныя з файлаў, размешчаных ва ўмоўным амазоне.

Таму давайце пройдземся па магчымых сцэнарах, ад найболей простага да больш складаных.

Самая простая пошасць, якая можа зваліцца на нашы галовы - гэта недаступнасць аднаго з файлаў у бекапным ланцужку.

Больш сумная гісторыя - у нас зламаўся адзін з экстэнтаў нашага SOBR рэпазітара.

Яшчэ горш становіцца, калі ўвесь SOBR рэпазітар стаў недаступны, але працуе капасіці цір.
І зусім усё дрэнна - гэта калі памірае бекапны сервер і тваё першае жаданне - паспрабаваць дабегчы да канадскай мяжы за дзесяць хвілін.

А зараз давайце разбяром кожную сітуацыю асобна.

Калі мы страцілі адзін (ды хай з ім, нават некалькі) бекапных файлаў, то нам дастаткова будзе запусціць працэс рэскана рэпазітара, і страчаны файл будзе заменены файлам-пустышкай. А з дапамогай працэсу регидрации (пра які было ў пачатку артыкула) карыстач зможа спампаваць дадзеныя з капасіці ціра ў лакальнае сховішча.

Цяпер сітуацыя больш складаная. Выкажам здагадку, што наш SOBR складаецца з двух экстэнтаў, якія працуюць у Performance рэжыме, а значыць, нашы .vbk і .vib размазаны па іх даволі нераўнамерным пластом. І ў нейкі момант часу адзін з экстэнтаў становіцца недаступным, а карыстачу трэба тэрмінова аднавіць машыну, частка дадзеных якой ляжыць менавіта на гэтым экстэнце.

Карыстальнік запускае візард аднаўлення, выбірае кропку, на якую жадае аднавіць, а візард падчас прац прыходзіць да ўсведамлення, што ўсіх неабходных для ўзнаўлення дадзеных лакальна ў яго няма і таму іх трэба запампаваць з капасіці ціра. Пры гэтым блокі, якія засталіся на лакальным сховішчы, спампоўвацца з аблокі не будуць. Слава restore азначніку (так, пра яго таксама было ў пачатку артыкула).

Падвід гэтага выпадку - стаў недаступны ўвесь SOBR рэпазітар. У такім выпадку нам няма чаго капіяваць з лакальных сховішчаў, і ўсе блокі спампоўваюцца з аблокі.

І самая цікавая сітуацыя - памёр бекапны сервер. Тут ёсць два варыянты: адмін малайчына і рабіў канфігурацыйныя бекапы, і адмін сам сабе злосны Бураціна і не рабіў канфігурацыйны бекап.

У першым выпадку яму будзе дастаткова проста дзесьці разгарнуць чыстую інсталяцыю VBR і аднавіць яго базу з бекапа штатнымі сродкамі. У завяршэнні гэтага працэсу ўсё вернецца на кругі свая. Ці ж будзе адноўлена па адным са сцэнарыяў вышэй.

Але калі адмін ці сам сабе вораг, ці бекап канфігурацыі таксама напаткала былінная няўдача, то нават тут мы не кінем яго на волю лёсу. Для гэтага выпадку мы ўвялі новую працэдуру, якая завецца Import Object Storage. Яна дазваляе прапусціць працэс узнаўлення ўручную SOBR рэпазітара і прымацаванні да яго капасіці ціра з наступным рэсканам, а проста дадаць абжект старадж у інтэрфейс віма і запусціць Import Storage Repository працэдуру. Адзінае, што можа стаць на шляху паміж вамі і вашымі бекапамі - гэта просьба ўвесці пароль, калі вашыя бекапы былі зашыфраваныя.

На гэтым пра Copy Mode, мабыць, усё і мы пераходзім да

Sealed Mode

Асноўная задумка - на абраным экстэнце SOBR рэпазітара не могуць з'яўляцца новыя бекапы. Да v10 у нас быў толькі Maintenance Mode, калі цалкам забаранялася любая праца з рэпазітаром. Гэтакі хардкорны рэжым вываду сховішча з працы, дзе даступная толькі кнопка Evacuate, разава якая перавозіла бекапы на іншы экстэнт.

А Sealed mode - гэта своеасаблівы "мяккі" варыянт: мы забараняем ствараць новыя бекапы і паступова выдаляем старыя паводле абранага рэтэншну, але ў працэсе не губляем магчымасць аднаўляцца з якія захоўваюцца кропак. Вельмі карысная штука, калі ў нас ці падыходзіць да канца тэрмін жыцця жалязякі і яе трэба будзе замяніць, ці яе проста трэба вызваліць пад нешта важнейшае, а браць і разава ўсё пераносіць няма куды. Ці нельга выдаліць.

Адпаведна, прынцып працы даволі просты: трэба забараніць усе write аперацыі (з'яўленне новых дадзеных), пакінуўшы read(рэстары) і delete(рэтэншн).

Абодва рэжыму можна выкарыстоўваць адначасова, толькі трэба ўлічваць, што ў Maintenance прыярытэт вышэй.

У якасці прыкладу разгледзім SOBR, які складаецца з двух экстэнтаў. Выкажам здагадку, першыя чатыры дні ў нас ствараліся бекапы ў рэжыме Forward Forever Incremental, а потым мы запячатваем экстэнт. Гэта вядзе да таго, што мы ініцыюем стварэнне новага актыў фула на другім даступным экстэнце. Калі наш рэтэнш роўны чатыром, то калі ўвесь ланцужок, размешчаны на запячатаным экстэнце, выйдзе за яго межы, ён са спакойным сумленнем выдаляецца.

Ёсць сітуацыі, калі выдаленне адбываецца раней. Напрыклад, гэта Forward incremental з перыядычнымі фуламі. Калі першыя два дні ў нас ствараліся фул бекапы, а ў чацвер мы вырашаем запячатаць рэпазітар, то ў пятніцу, калі створыцца новы фульнік, то файл за панядзелак будзе выдалены т.я. да гэтай кропкі няма залежнасцяў. І сама кропка ні ад каго не залежыць. Пасля чаго мы чакаем калі будуць створаныя чатыры кропкі на даступным экстэнце і выдаляем пакінутыя тры, якія не могуць быць выдаленыя незалежна адзін ад аднаго.

Прасцей справы ідуць з Reverse Incremental. У ім самыя старыя кропкі ні ад чаго не залежаць і могуць быць спакойна выдалены. Таму, як толькі будзе створаны новы .vbk на новым экстэнце, старыя .vrb будуць па адным выдаляцца.

Дарэчы, чаму мы кожны раз ствараем новы .vbk: калі яго не ствараць, а працягваць стары ланцужок інкраментаў, то стары .vbk падвісаў бы на бясконца доўгі час у любым рэжыме, перашкаджаючы яго выдаленню. Таму было прынята рашэнне, што як толькі запячатваецца экстэнт, мы ствараем фул бекап на вольным экстэнце.

Складаней справы ідуць з капасіці цірам.

Спачатку разгледзім copy mode. Выкажам здагадку, што ў нас чатыры дні актыўна ствараліся бекапы, а потым капасіці цір быў запячатаны. Мы нічога не выдаляем, а пакорліва вытрымліваем рэтэншн, пасля чаго выдаляем дадзеныя з капасіці ціра.

Прыкладна тое ж самае адбываецца пры move mode – чакаем рэтэнш, выдаляем старое ў лакальным сховішчы, выдаляем якое захоўваецца ў абжект вартаўні.

Цікавы прыклад з Forever forward incremental. Усталёўваны рэтэнш у тры кропкі і пачынаем з панядзелка рабіць бекапы, якія спраўна капіююцца ў воблака. Пасля запячатвання сховішчы бекапы працягваюць стварацца, вытрымоўваючы тры кропкі, але якія захоўваюцца ў капасіці працяжнік дадзеныя застаюцца залежнымі і не могуць быць выдаленыя. Таму мы чакаем чацвярга, калі наш .vbk выходзіць за рамкі рэтэншн, і толькі тады спакойна выдаляем увесь захаваны ланцужок.

І невялікая агаворка: усе прыклады тут паказаны з адной машынай. Калі ў вас у бекапе іх некалькі, то рэтэнш у іх будзе адрознівацца ў залежнасці ад таго, быў зроблены Active Full ці не.

На гэтым, у прынцыпе, і ўсё. Так што пераходзім да самай хардкорнай фічы

Нязменнасць

Як і з папярэднімі пунктамі, перш за ўсё аб тым, якую праблему вырашае гэтая функцыя. Як толькі мы выгружаем кудысьці нашы бекапы на захоўванне, узнікае вострае жаданне гарантаваць іх захаванасць, гэта значыць фізічна забараніць іх выдаленне і любую мадыфікацыю на працягу зададзенага рэтэншэна. У тым ліку адмінамі, у тым ліку пад іх рутавымі ўлікамі. Гэта дазваляе абараніць іх ад выпадковага ці наўмыснага псуты. Хто працуе з AWS, мог сустракаць падобную функцыю пад назовам Object Lock.

Цяпер разгледзім рэжым у агульных словах, а потым паглыбімся ў дэталі. У нашым прыкладзе Immutability будзе ўключаны для нашага капасіці ціра з рэтэнш ў чатыры дні. А ў бекапе ўключаны рэжым Copy.

Immutability ніяк не ўзаемадзейнічае з агульным рэтэншнам. Напрыклад, ён не дадае дадатковых кропак ці нешта такое. Проста на працягу чатырох дзён чалавек не можа выдаліць файлы бекапаў. Калі ў панядзелак зрабіць бекап, то выдаліць ягоны файл атрымаецца толькі ў пятніцу.

Усе раней растлумачаныя канцэпты дэгідрацыі, індэксаў і метададзеных працягваюць працаваць сапраўды гэтак жа. Але з адной умовай - блок выстаўляецца не толькі для дадзеных, але і на метададзеныя. Гэта зроблена на выпадак, калі падступны зламыснік вырашыць сцерці нашу базу метададзеных і каб блокі з дадзенымі не ператварыліся ў бескарысную бінарную кашу.

І зараз надышоў выдатны момант для тлумачэння нашай тэхналогіі пакалення блокаў. Або block generation. Для гэтага разгледзім сітуацыю, якая прывяла да яе з'яўлення.

Возьмем часовую шкалу ў шэсць дзён і знізу будзем адзначаць час чаканага заканчэння immutability. Бярэм і ствараем у першы дзень файл, які складаецца з блока дадзеных а, і яго метададзеныя. Калі immutability усталяваны ў тры дні, лагічна выказаць здагадку, што на чацвёрты дзень дадзеныя будуць раскіданыя і выдаленыя. На другі дзень дадамо новы file2, які складаецца з блока b з тымі ж наладамі. Блок а ўсё яшчэ павінен быць выдалены на чацвёрты дзень. Але на трэці дзень здараецца страшнае - ствараецца файл File3, які складаецца з новага блока d і спасылкі на стары блок а. Гэта значыць, што для блока а яго immutability сцяг павінен быць перавыстаўлены на новы тэрмін, які зрушваецца на шосты дзень. І тут узнікае праблема - у рэальных бекапах такіх блокаў узнікае велізарная колькасць. А каб падоўжыць ім immutability перыяд, трэба кожны раз здзяйсняць велізарную колькасць запытаў. І фактычна гэта будзе каля-бясконцы штодзённы працэс, бо з вялікай дзеллю верагоднасці мы пры кожным капіяванні будзем знаходзіць здаравенныя пачкі дэдуплікаваных блокаў. А што значыць вялікая колькасць запытаў у правайдэраў абжект старэй? Правільна! Велізарны рахунак у канцы месяца.

І каб не выстаўляць на роўным месцы на самавітыя грошы сваіх каханых кліентаў, быў прыдуманы механізм block generation. Гэта дадатковы перыяд, які мы дадаем да выстаўленага перыяду immutability. У прыкладзе ніжэй такі перыяд складае два дні. Але гэта толькі для прыкладу. У рэальнасці тамака выкарыстоўваецца свая формула, якая дае прыкладна дзесяць дадатковых дзён пры месячным локу.

Працягнем разглядаць тую ж сітуацыю, але ўжо з block generation. Ствараем у першы дзень file1 з блока а і метададзеных. Складаны перыяд пакаленняў і immutability - значыць, магчымасць выдаліць файл будзе на шосты дзень. Калі на другі дзень мы створым File2, які складаецца з блока b і спасылкі на блок а, то з меркаванай датай выдалення нічога не адбываецца. Яна як стаяла на шосты дзень, так і стаіць. А мы тым самым спрабуем эканоміць грошы на колькасці запытаў. Адзіная сітуацыя, калі тэрмін можа быць ссунуты, гэта калі generation period скончыўся. Гэта значыць, калі на трэці дзень новы File3 будзе ўтрымоўваць спасылку на блок а, то будзе дададзены generation 2 бо Gen1 ужо скончыўся. А чаканая дата выдалення блока а перамесціцца на восьмы дзень. Гэта дазваляе нам драматычна знізіць колькасць запытаў на падаўжэнне часу жыцця дэдуплікаваных блокаў, што эканоміць вагон грошай кліентам.

Сама тэхналогія даступная карыстальнікам S3 і S3-сумяшчальнага жалеза, вытворцы якога гарантуюць, што іх рэалізацыя не адрозніваецца ад амазонаўскай. Адгэтуль адказ на законнае пытанне, чаму не падтрымліваецца Azure – у іх ёсць падобная фіча, але яна працуе на ўзроўні кантэйнераў, а не асобных аб'ектаў. Дарэчы, у самім амазоне абжэк лок ёсць у двух рэжымах: compliance і governance. У другім выпадку застаецца магчымасць, каб самы вялікі адмін над адмінамі і рут над рутамі, нягледзячы на ​​абжект лок, усё ж выдаліў дадзеныя. У выпадку compliance усё прыбіта цвікамі намёртва і бекапы не выдаліць нікому. Нават у адмінаў амазону (паводле іх афіцыйных заяваў). Мы падтрымліваем менавіта гэты рэжым.

І, традыцыйна, крыху карысных спасылак:

• Пра Block Generation ва ўсіх падрабязнасцях.
• Уся інфармацыя пра Veeam Backup & Replication 10 у лепшым выглядзе
• О Capacity Tier у дэталях

Крыніца: habr.com