Kapacitná vrstva (alebo ako ju nazývame vo Vim - captir) sa objavila už v časoch Veeam Backup and Replication 9.5 Update 4 pod názvom Archive Tier. Ide o to, aby bolo možné presunúť zálohy, ktoré vypadli z takzvaného okna na obnovenie prevádzky, do úložiska objektov. To pomohlo vyčistiť miesto na disku pre používateľov, ktorí ho mali málo. A táto možnosť sa volala Move Mode.

Na vykonanie tejto jednoduchej (ako sa zdá) akcie stačilo splniť dve podmienky: všetky body z presunutej zálohy sa musia nachádzať mimo hraníc vyššie spomínaného okna na obnovenie prevádzky, ktoré je nastavené explicitne v UI. A po druhé: reťazec musí byť v takzvanej „zapečatenej forme“ (zapečatený reťazec záloh alebo neaktívny reťazec zálohovania). To znamená, že v priebehu času nenastanú v tomto reťazci žiadne zmeny.

No vo VBR v10 bol koncept doplnený o nové funkcie - objavila sa Copy Mode, Sealed Mode a vec s ťažko vysloviteľným názvom Immutability.

Toto sú fascinujúce veci, o ktorých dnes budeme hovoriť. Najprv o tom, ako to fungovalo vo VBR9.5u4, a potom o zmenách v desiatej verzii.

A majstri čistého jazyka nech mi odpustia, ale je tam príliš veľa výrazov, ktoré sa nedajú preložiť.
Takže tu bude veľa anglicizmov.
A veľa gifov.
A obrázky.

• Bez najmenšej ľútosti. Autor článku.

Ako to bolo

Začnime analýzou okna prevádzkovej obnovy a uzavretej zálohy (alebo ako sa nazývajú v dokumentácii Inactive Backup Chain). Bez ich pochopenia nebude možné ďalšie vysvetlenie.

Ako vidíme na obrázku, máme akýsi záložný reťazec s dátovými blokmi, ktorý sa nachádza na Performance tier SOBR úložiska, ku ktorému je Capacity Tier pripojený. Naša prevádzková záloha je tri dni.

V súlade s tým .vbk vytvorený v pondelok zapečatí predchádzajúci reťazec, ktorého okno je nastavené na tri dni. A to znamená, že na strelnicu môžete pokojne začať prevážať všetko staršie ako tieto tri dni.

Čo sa však presne myslelo pod zapečatenou reťazou a čo sa dalo poslať na kapacitnú strelnicu v aktualizácii 4?

Pre Forward Incremental je znakom uzavretia reťazca vytvorenie novej úplnej zálohy. A nezáleží na tom, ako sa táto úplná záloha získa: do úvahy sa berú syntetické plné aj aktívne plné zálohy.

V prípade Reverse sú to všetky súbory, ktoré nespadajú do operačného okna.

V prípade dopredného prírastku s vráteniami sú to všetky vrátenia a .vbk, ak existuje ďalší .vbk v rozsahu výkonu

Teraz zvážime možnosť práce s reťazami zálohovania. Prevážali sa sem iba predmety spadajúce pod retenciu GFS. Pretože všetko uložené v novších reťazcoch záložných kópií sa dá tak či onak zmeniť.

Teraz sa pozrime pod kapotu. Tam nastáva proces nazývaný dehydratácia – ponechanie prázdnych záložných súborov na rozsah a pretiahnutie blokov z týchto súborov na kapacitnú strelnicu. Na optimalizáciu tohto procesu sa používa takzvaný index dehydratácie, ktorý umožňuje vyhnúť sa kopírovaniu už skopírovaných blokov na kapacitnú strelnicu.

Pozrime sa, ako to vyzerá na príklade: Povedzme, že máme .vbk, ktorý vyšiel z okna transakcie a patrí do zapečateného reťazca. To znamená, že máme plné právo ho presunúť na kapacitnú strelnicu. V čase presunu sa vytvorí súbor metadát v pomlčke kapacity a blokoch prenášaného súboru. Súbor metadát na úrovni odkazu popisuje, z ktorých blokov pozostáva náš súbor. V prípade na obrázku sa náš prvý súbor skladá z blokov a, b, c a metadáta obsahujú odkazy na tieto bloky. Keď máme druhý súbor .vbk pripravený na presun a pozostávajúci z blokov a, b a d, pri analýze indexu dehydratácie pochopíme, že je potrebné preniesť iba blok d. A jeho súbor metadát bude obsahovať odkazy na dva predchádzajúce bloky a jeden nový.

V súlade s tým sa proces vypĺňania týchto prázdnych miest späť údajmi nazýva rehydratácia. Už používa svoj vlastný rehydratačný index založený na najstaršom súbore .vbk o lokálnom rozsahu výkonu. To znamená, že ak chce používateľ vrátiť súbor z kapacitnej strelnice, najprv vytvoríme index blokov najstaršej plnej zálohy a prenesieme len chýbajúce bloky z kapacitnej strelnice. V prípade prezentovanom na obrázku nám na rehydratáciu FullBackup1.vbk podľa rehydratačného indexu stačí blok C, ktorý odoberáme z kapacitnej strelnice. Ak úložný cloudový objekt slúži ako kapacitná strelnica, umožňuje vám to ušetriť obrovské množstvo peňazí.

Tu sa môže zdať, že táto technológia je totožná s tou, ktorá sa používa vo WAN akcelerátoroch, ale len sa to tak zdá. V urýchľovačoch je deduplikácia globálna, tu sa lokálna deduplikácia používa v rámci každého súboru s určitým posunom. Stáva sa to kvôli rozdielu v riešených úlohách: tu potrebujeme skopírovať veľké úplné záložné súbory a podľa nášho výskumu, aj keď medzi nimi uplynie dlhé časové obdobie, tento deduplikačný algoritmus dáva najlepší výsledok.

Ale viac indexov pre boha indexov! Nechýba ani index na obnovu dát! Keď začneme s obnovou stroja umiestneného v pomlčke kapacity, budeme čítať iba jedinečné dátové bloky, ktoré nie sú v pomlčke výkonu.

Ako sa to stalo?

To je na úvodnú časť všetko. Je pomerne podrobný, no ako už bolo spomenuté vyššie, bez týchto detailov nebude možné vysvetliť, ako nové funkcie fungujú. Preto bez ďalších okolkov prejdime k prvému.

Režim kopírovania

Z veľkej časti vychádza z existujúcich technológií, no nesie úplne inú logiku použitia. 

Účelom tohto režimu je zabezpečiť, aby všetky údaje nachádzajúce sa v lokálnom rozsahu mali kópiu v pomlčke kapacity.

Ak priamo porovnáte režimy Premiestniť a Kopírovať, bude to vyzerať takto:

• Pohybovať sa dá len zapečatenou reťazou. V prípade režimu kopírovania sa prenesie úplne všetko, bez ohľadu na to, čo sa stane v úlohe zálohovania.
• Presun sa spustí, keď súbory prekročia hranice okna prevádzkovej zálohy, a kopírovanie sa spustí hneď, ako sa objaví súbor zálohy.
• Monitorovanie nových údajov na kopírovanie prebieha neustále a na presun sa spúšťalo raz za 4 hodiny.

Pri zvažovaní nového režimu navrhujem prejsť od jednoduchých príkladov k zložitým.

V najbežnejšom prípade máme jednoducho nové súbory s prírastkami a tie jednoducho skopírujeme na kapacitnú strelnicu. Bez ohľadu na to, aký režim sa používa v úlohe zálohovania, bez ohľadu na to, či patrí do zapečatenej časti reťazca alebo nie, bez ohľadu na to, či uplynulo naše prevádzkové okno. Len to zobrali a skopírovali.

Proces za tým je stále dehydratácia, ako je opísané vyššie. V režime kopírovania sa tiež stará o to, aby sme nekopírovali bloky, ktoré sú už na našom úložisku. Jediný rozdiel je v tom, že ak sme v režime filmu nahradili skutočné súbory fiktívnymi súbormi, tu sa ich žiadnym spôsobom nedotýkame a necháme všetko tak. Inak je to presne ten istý index dehydratácie, ktorý sa starostlivo snaží šetriť vaše peniaze a čas.

Vynára sa otázka - ak sa pozriete na používateľské rozhranie, je tu možnosť vybrať obe možnosti súčasne. Ako bude takýto kombinovaný režim fungovať?

Poďme pochopiť.

Začiatok je štandardný: okamžite sa vytvorí a skopíruje záložný súbor. Vytvorí sa k nemu prírastok a tiež sa skopíruje. Toto sa deje až do momentu, keď si uvedomíme, že súbory opustili naše prevádzkové okno a objavila sa zapečatená reťaz. V tomto bode vykonáme operáciu dehydratácie a nahradíme tieto súbory fiktívnymi súbormi. Na kapacitnú strelnicu samozrejme už nič nekopírujeme.

Celá táto fascinujúca logika je zodpovedná len za jedno začiarkavacie políčko v rozhraní: Kopírovať zálohy do úložiska objektov hneď po ich vytvorení.

Prečo potrebujeme tento režim kopírovania?

Ešte lepšie je preformulovať otázku takto: pred akými rizikami sme s jeho pomocou chránení? Aký problém nám pomáha vyriešiť?

Odpoveď je zrejmá: samozrejme, ide o obnovu dát. Ak máme úplnú kópiu lokálnych údajov na objektovom úložisku, potom bez ohľadu na to, čo sa stane s naším produktom, vždy môžeme obnoviť údaje zo súborov nachádzajúcich sa v podmienenom Amazone.

Poďme si teda prejsť možné scenáre, od najjednoduchších po zložitejšie.

Najjednoduchším nešťastím, ktoré môže padnúť na naše hlavy, je nedostupnosť jedného zo súborov v reťazci záloh.

Smutnejším príbehom je, že sa pokazil jeden z rozsahov nášho SOBR úložiska.

Ešte horšie je, keď sa celé úložisko SOBR stalo nedostupným, no kapacitná strelnica funguje.
A všetko je naozaj zlé - vtedy padne záložný server a vašou prvou túžbou je pokúsiť sa za desať minút dobehnúť ku kanadskej hranici.

Teraz sa pozrime na každú situáciu osobitne.

Keď sme stratili jeden (a dokonca niekoľko) záložných súborov, potom všetko, čo musíme urobiť, je spustiť proces opätovného skenovania úložiska a stratený súbor bude nahradený fiktívnym súborom. A pomocou procesu rehydratácie (o ktorom sme hovorili na začiatku článku) si používateľ bude môcť stiahnuť dáta z kapacitnej strelnice do lokálneho úložiska.

Теперь ситуация посложнее. Предположим, что наш SOBR состоит из двух экстентов, работающих в Performance режиме, а значит, наши .vbk и .vib размазаны по ним довольно неравномерным слоем. И в какой-то момент времени один из экстентов становится недоступным, а пользователю надо срочно восстановить машину, часть данных которой лежит именно на этом экстенте.

Používateľ spustí sprievodcu obnovou, vyberie bod, do ktorého chce obnoviť, a sprievodca pri práci príde na to, že nemá všetky dáta potrebné na obnovu lokálne, a preto je potrebné ich stiahnuť z nahrávania kapacity. galéria. Zároveň sa z cloudu nestiahnu bloky, ktoré zostanú na lokálnom úložisku. Sláva indexu obnovy (áno, bolo to spomenuté aj na začiatku článku).

Podtypom tohto prípadu je, že celé úložisko SOBR sa stalo nedostupným. V tomto prípade nemáme čo kopírovať z lokálneho úložiska a všetky bloky sa sťahujú z cloudu.

A najzaujímavejšia situácia je, že záložný server zomrel. Tu sú dve možnosti: správca je skvelý a zálohuje konfiguráciu a správca je zlý Pinocchio sám a zálohy konfigurácie nerobil.

V prvom prípade mu bude stačiť len niekde nasadiť čistú inštaláciu VBR a obnoviť jej databázu zo zálohy štandardnými prostriedkami. Na konci tohto procesu sa všetko vráti do normálu. Alebo sa obnoví podľa jedného z vyššie uvedených scenárov.

Ak je ale admin buď jeho vlastným nepriateľom, alebo epickým zlyhaním utrpela aj záloha konfigurácie, tak ani tu ho nenecháme napospas osudu. Pre tento prípad sme zaviedli nový postup s názvom Import Object Storage. Umožňuje vám preskočiť proces manuálneho opätovného vytvorenia úložiska SOBR a pripojenia kapacitnej strelnice k nemu s následným opätovným skenovaním a jednoducho pridať objekt úložiska do rozhrania Vim a spustiť procedúru Import Storage Repository. Jediná vec, ktorá môže stáť v ceste medzi vami a vašimi zálohami, je požiadavka na zadanie hesla, ak boli vaše zálohy šifrované.

Toto je pravdepodobne všetko o režime kopírovania a ideme ďalej

Uzavretý režim

Hlavnou myšlienkou je, že nové zálohy sa nemôžu objaviť na vybranom rozsahu SOBR úložiska. Pred v10 sme mali iba Maintenance Mode, kedy bola akákoľvek práca s úložiskom úplne zakázaná. Akýsi hardcore režim na vypnutie úložiska, kde je dostupné iba tlačidlo Evakuovať, ktoré jednorazovo prenesie zálohy do iného rozsahu.

A zapečatený režim je akousi „mäkkou“ možnosťou: zakážeme vytváranie nových záloh a postupne odstraňujeme staré podľa zvoleného uchovávania, ale v tomto procese nestrácame možnosť obnovy z uložených bodov. Veľmi užitočná vec, keď sa nám buď blíži koniec životnosti nejakého hardvéru a potrebujeme ho vymeniť, alebo ho len potrebujeme uvoľniť pre niečo dôležitejšie, no nie je kam vziať a všetko naraz presunúť. Alebo sa to nedá vymazať.

Princíp činnosti je teda pomerne jednoduchý: je potrebné zakázať všetky operácie zápisu (vzhľad nových údajov), ponechať čítanie (obnovenia) a vymazať (uchovávanie).

Oba režimy je možné používať súčasne, ale majte na pamäti, že údržba má vyššiu prioritu.

Ako príklad uvažujme SOBR pozostávajúci z dvoch rozsahov. Predpokladajme, že prvé štyri dni sme vytvárali zálohy v režime Forward Forever Incremental a potom rozsah zapečatíme, čo vedie k tomu, že spustíme vytvorenie nového aktívneho plného na druhom dostupnom rozsahu. Ak je naša retencia štyri, potom keď celý reťazec umiestnený na zapečatenom rozsahu prekročí svoje hranice, je s čistým svedomím vymazaný.

Existujú situácie, keď k vymazaniu dôjde skôr. Toto je napríklad Inkrementálne dopredu s pravidelným plnením. Ak sme prvé dva dni vytvorili úplné zálohy a vo štvrtok sa rozhodneme zapečatiť úložisko, tak v piatok, keď sa vytvorí nová záloha, sa súbor na pondelok vymaže, pretože v tomto bode neexistujú žiadne závislosti. A samotný bod nezávisí od nikoho. Potom počkáme, kým sa vytvoria štyri body na dostupnom rozsahu a vymažeme zvyšné tri, ktoré nie je možné vymazať nezávisle od seba.

S Reverse Incremental sú veci jednoduchšie. V ňom najstaršie body na ničom nezávisia a dajú sa bezpečne vymazať. Preto, akonáhle sa vytvorí nový .vbk v novom rozsahu, staré .vrbs sa jeden po druhom vymažú.

Mimochodom, prečo zakaždým vytvárame nové .vbk: ak by sme ho nevytvorili, ale pokračovali v starom reťazci prírastkov, potom by staré .vbk zamrzlo na nekonečne dlho v akomkoľvek režime a zabránilo by sa jeho vymazaniu. Preto bolo rozhodnuté, že hneď ako bude rozsah zapečatený, vytvoríme plnú zálohu na voľnom rozsahu.

S kapacitnou strelnicou sú veci zložitejšie.

Najprv sa pozrime na režim kopírovania. Predpokladajme, že štyri dni sme aktívne vytvárali zálohy a potom bola kapacitná strelnica zapečatená. Nič nemažeme, ale pokorne znášame retenciu, po ktorej vymažeme údaje z kapacitnej strelnice.

Približne to isté sa deje v režime presunu – počkáme na retuš, vymažeme starú v lokálnom úložisku a vymažeme tú uloženú v úložisku objektov.

Zaujímavý príklad s Forever forward incremental. Retenciu nainštalujeme v troch bodoch a v pondelok začneme vytvárať zálohy, ktoré sa pravidelne kopírujú do cloudu. Po zapečatení úložiska sa naďalej vytvárajú zálohy, pričom sa zachovávajú tri body, ale údaje uložené v pomlčke kapacity zostávajú závislé a nemožno ich vymazať. Preto počkáme do štvrtka, kedy náš .vbk prekročí hranicu retencie a až potom pokojne vymažeme celý uložený reťazec.

A malé odmietnutie zodpovednosti: všetky príklady sú zobrazené s jedným strojom. Ak ich máte v zálohe niekoľko, ich retuš sa bude líšiť v závislosti od toho, či bola vykonaná Active Full alebo nie.

To je v podstate všetko. Prejdime teda k najtvrdšej funkcii –

Nezmeniteľnosť

Rovnako ako pri predchádzajúcich bodoch, prvé je, aký problém táto funkcia rieši. Akonáhle svoje zálohy niekde nahráme na uloženie, existuje silná túžba zaručiť ich bezpečnosť, to znamená fyzicky zakázať ich mazanie a akúkoľvek úpravu počas daného uchovávania. Vrátane správcov vrátane ich koreňových účtov. To vám umožní chrániť ich pred náhodným alebo úmyselným poškodením. Každý, kto pracuje s AWS, sa mohol stretnúť s podobnou funkciou nazývanou Object Lock.

Teraz sa pozrime na režim všeobecne a potom sa ponoríme do detailov. V našom príklade bude Immutability povolená pre našu kapacitnú strelnicu so zachovaním štyroch dní. A v zálohe je povolený režim kopírovania.

Nemennosť nijako neinteraguje so všeobecnou retenciou. Nepridáva napríklad body navyše ani nič podobné. Je to tak, že osoba nemôže odstrániť záložné súbory do štyroch dní. Ak vytvoríte zálohu v pondelok, jej súbor budete môcť vymazať až v piatok.

Všetky predtým vysvetlené koncepty dehydratácie, indexy a metadáta naďalej fungujú úplne rovnako. Ale s jednou podmienkou – blok je nastavený nielen na dáta, ale aj na metadáta. To sa deje v prípade, že sa prefíkaný útočník rozhodne vymazať našu databázu metadát a zabrániť tomu, aby sa bloky údajov zmenili na zbytočnú binárnu kašu.

Teraz je skvelý čas vysvetliť našu technológiu generovania blokov. Alebo generovanie blokov. Ak to chcete urobiť, zvážte situáciu, ktorá viedla k jeho vzhľadu.

Zoberme si časovú škálu šiestich dní a nižšie označíme čas predpokladaného uplynutia nezmeniteľnosti. Prvý deň zoberieme a vytvoríme súbor pozostávajúci z dátového bloku a a jeho metadát. Ak je nemennosť nastavená na tri dni, je logické predpokladať, že na štvrtý deň budú dáta odomknuté a vymazané. Na druhý deň pridáme nový súbor2, pozostávajúci z bloku b s rovnakými nastaveniami. Blok a je potrebné odstrániť na štvrtý deň. Ale na tretí deň sa stane niečo hrozné - vytvorí sa súbor File3, ktorý pozostáva z nového bloku d a odkazu na starý blok a. To znamená, že pre blok a jeho príznak nezmeniteľnosti sa musí resetovať na nový dátum, ktorý sa posúva na šiesty deň. A tu vzniká problém - v skutočných zálohách je takýchto blokov obrovské množstvo. A aby ste predĺžili dobu ich nemennosti, musíte zakaždým podať obrovské množstvo žiadostí. A v skutočnosti to bude takmer nekonečný každodenný proces, pretože s vysokou pravdepodobnosťou nájdeme pri každej kópii poriadne stohy deduplikovaných blokov. Čo znamená veľký počet požiadaviek od poskytovateľov ukladania objektov? Správny! Obrovský účet na konci mesiaca.

A aby ste z ničoho nič neodhalili svojich obľúbených klientov za nemalé peniaze, bol vynájdený mechanizmus generovania blokov. Ide o dodatočné obdobie, ktoré pripočítavame k nastavenej dobe nezmeniteľnosti. V nižšie uvedenom príklade je toto obdobie dva dni. Ale toto je len príklad. V skutočnosti používajú svoj vlastný vzorec, ktorý dáva približne desať dní navyše počas mesačného blokovania.

Pokračujme v uvažovaní o rovnakej situácii, ale s generovaním blokov. Prvý deň vytvoríme súbor1 z bloku a a metadát. Sčítame generačné obdobie a nemennosť – to znamená, že možnosť vymazať súbor bude na šiesty deň. Ak na druhý deň vytvoríme súbor 2 pozostávajúci z bloku b a odkazu na blok a, potom sa s očakávaným dátumom vymazania nič nestane. Stála tak ako na šiesty deň. A tým sa snažíme ušetriť na množstve požiadaviek. Jedinou situáciou, kedy je možné termín posunúť, je, ak uplynula generačná lehota. To znamená, že ak na tretí deň nový súbor 3 obsahuje odkaz na blok a, potom sa pridá generácia 2, pretože platnosť Gen1 už vypršala. A predpokladaný dátum vymazania bloku a sa posunie na ôsmy deň. To nám umožňuje dramaticky znížiť počet požiadaviek na predĺženie životnosti deduplikovaných blokov, čo klientom ušetrí veľa peňazí.

Samotná technológia je dostupná pre používateľov hardvéru kompatibilného s S3 a S3, ktorých výrobcovia zaručujú, že ich implementácia sa nelíši od implementácie Amazonu. Preto odpoveď na legitímnu otázku, prečo Azure nie je podporovaný – majú podobnú funkciu, ale funguje to na úrovni kontajnerov, nie jednotlivých objektov. Mimochodom, samotný Amazon má objektový zámok v dvoch režimoch: súlad a riadenie. V druhom prípade zostáva možnosť, že najväčší admin nad adminom a root nad rootom, napriek uzamknutiu objektu, stále vymaže údaje. V prípade súladu je všetko pevne pribité a nikto nemôže vymazať zálohy. Dokonca aj admini Amazonu (podľa ich oficiálnych vyjadrení). Toto je režim, ktorý podporujeme.

A ako obvykle niekoľko užitočných odkazov:

• o Generovanie blokov v každom detaile.
• Všetky informácie o Veeam Backup & Replication 10 в лучшем виде
• О Úroveň kapacity podrobne

Zdroj: hab.com