Úroveň kapacity (nebo jak tomu říkáme uvnitř Vim - captir) se objevila již v dobách Veeam Backup and Replication 9.5 Update 4 pod názvem Archive Tier. Spočívá v tom, aby bylo možné přesunout zálohy, které vypadly z takzvaného okna provozní obnovy, do objektového úložiště. To pomohlo uvolnit místo na disku těm uživatelům, kteří ho měli málo. A tato možnost se jmenovala Move Mode.

K provedení této jednoduché (jak se zdá) akce stačilo splnit dvě podmínky: všechny body z přesunuté zálohy musí být mimo hranice výše zmíněného okna provozní obnovy, které je nastaveno explicitně v uživatelském rozhraní. A za druhé: řetězec musí být v takzvané „uzavřené formě“ (zapečetěný řetězec záloh nebo Inactive Backup Chain). To znamená, že v průběhu času nedochází v tomto řetězci k žádným změnám.

Ve VBR v10 byl ale koncept doplněn o nové funkce - objevila se Copy Mode, Sealed Mode a věc s těžko vyslovitelným názvem Immutability.

To jsou fascinující věci, o kterých dnes budeme mluvit. Nejprve o tom, jak to fungovalo ve VBR9.5u4, a poté o změnách v desáté verzi.

A nechť mi zastánci čistého jazyka prominou, ale je tam příliš mnoho výrazů, které nelze přeložit.
Takže tady bude tuna anglicismů.
A spousta gifů.
A obrázky.

• Bez sebemenší lítosti. Autor článku.

Tak jak to bylo

Začněme analýzou okna provozní obnovy a uzavřené zálohy (nebo jak se tomu říká v dokumentaci Inactive Backup Chain). Bez jejich pochopení nebude možné další vysvětlení.

Jak vidíme na obrázku, máme jakýsi záložní řetězec s datovými bloky, který je umístěn na Performance tier SOBR úložiště, ke kterému je Capacity Tier připojen. Naše provozní doba zálohy je tři dny.

V souladu s tím .vbk vytvořený v pondělí zapečetí předchozí řetězec, jehož okno je nastaveno na tři dny. A to znamená, že na střelnici můžete klidně začít vozit vše starší než tyto tři dny.

Co přesně se ale myslelo zapečetěným řetězem a co bylo možné poslat na kapacitní střelnici v aktualizaci 4?

Pro Forward Incremental je známkou uzavření řetězce vytvoření nové plné zálohy. A nezáleží na tom, jak se tato plná záloha získá: jsou brány v úvahu syntetické plné i aktivní plné zálohy.

V případě Reverse se jedná o všechny soubory, které nespadají do provozního okna.

V případě přírůstku vpřed s vrácením zpět se jedná o všechna vrácení zpět a .vbk, pokud existuje další .vbk v rozsahu výkonu

Nyní se podívejme na možnost práce s řetězci Backup Copy. Sem byly přepravovány pouze předměty spadající pod retenci GFS. Protože vše uložené v novějších řetězcích záložních kopií lze tak či onak změnit.

Nyní se podíváme pod pokličku. Tam dochází k procesu zvanému dehydratace – ponechání prázdných záložních souborů na rozsahu a přetažení bloků z těchto souborů na kapacitní střelnici. Pro optimalizaci tohoto procesu se používá tzv. index dehydratace, který umožňuje vyhnout se kopírování již zkopírovaných bloků na kapacitní střelnici.

Podívejme se, jak to vypadá na příkladu: Řekněme, že máme soubor .vbk, který vyšel z okna transakce a patří do uzavřeného řetězce. To znamená, že máme plné právo jej přesunout na kapacitní střelnici. V okamžiku přesunu se v pomlčce kapacity a blocích přeneseného souboru vytvoří soubor metadat. Soubor metadat na úrovni odkazu popisuje, z jakých bloků se náš soubor skládá. V případě na obrázku se náš první soubor skládá z bloků a, b, c a metadata obsahují odkazy na tyto bloky. Když máme druhý soubor .vbk připravený k přesunu a sestávající z bloků a, b a d, při analýze indexu dehydratace pochopíme, že je třeba přenést pouze blok d. A jeho soubor metadat bude obsahovat odkazy na dva předchozí bloky a jeden nový.

V souladu s tím se proces vyplnění těchto prázdných míst zpět daty nazývá rehydratace. Již používá svůj vlastní rehydratační index založený na nejstarším souboru .vbk na místním rozsahu výkonu. To znamená, že pokud chce uživatel vrátit soubor z kapacitní střelnice, vytvoříme nejprve index bloků nejstarší plné zálohy a z kapacitní střelnice přeneseme pouze chybějící bloky. V případě znázorněném na obrázku nám k rehydrataci FullBackup1.vbk podle rehydratačního indexu stačí blok C, který odebereme z kapacitní střelnice. Pokud úložný cloudový objekt slouží jako kapacitní střelnice, umožňuje to ušetřit obrovské množství peněz.

Zde se může zdát, že tato technologie je totožná s tou, která se používá ve WAN Acceleratorech, ale jen se to tak zdá. V akcelerátorech je deduplikace globální, zde se lokální deduplikace používá v rámci každého souboru s určitým posunem. To je způsobeno rozdílem v řešených úlohách: zde potřebujeme zkopírovat velké soubory plné zálohy a podle našeho výzkumu, i když mezi nimi uplyne dlouhá doba, tento deduplikační algoritmus dává nejlepší výsledek.

Ale více indexů pro boha indexů! Nechybí ani index pro obnovu dat! Když začneme s obnovou stroje umístěného v pomlčce kapacity, budeme číst pouze jedinečné datové bloky, které nejsou v pomlčce výkonu.

Jak se to stalo

To je k úvodní části vše. Je poměrně podrobný, ale jak již bylo zmíněno výše, bez těchto detailů nebude možné vysvětlit, jak nové funkce fungují. Proto bez dalších okolků přejděme k prvnímu.

Režim kopírování

Z velké části vychází ze stávajících technologií, ale nese zcela jinou logiku použití. 

Účelem tohoto režimu je zajistit, aby všechna data umístěná v místním rozsahu měla kopii v pomlčce kapacity.

Pokud přímo porovnáte režimy Přesunout a Kopírovat, bude to vypadat takto:

• Posouvat lze pouze utěsněný řetěz. V případě režimu kopírování se přenese naprosto vše, bez ohledu na to, co se děje v úloze zálohování.
• Přesouvání se spustí, když soubory překročí hranice okna provozní zálohy, a kopírování se spustí, jakmile se soubor zálohy objeví.
• Sledování nových dat pro kopírování probíhá neustále a pro přesun bylo spouštěno jednou za 4 hodiny.

Při zvažování nového režimu navrhuji přejít od jednoduchých příkladů ke složitým.

V nejběžnějším případě máme prostě nové soubory s přírůstky a ty jednoduše zkopírujeme na kapacitní střelnici. Bez ohledu na to, jaký režim je v úloze zálohování použit, bez ohledu na to, zda patří do zapečetěné části řetězce nebo ne, bez ohledu na to, zda naše provozní okno vypršelo. Prostě to vzali a zkopírovali.

Proces za tím je stále dehydratace, jak je popsáno výše. V režimu kopírování také zajišťuje, že nekopírujeme bloky, které jsou již na našem úložišti. Jediný rozdíl je v tom, že pokud jsme v režimu filmu nahradili skutečné soubory fiktivními soubory, zde se jich žádným způsobem nedotýkáme a necháme vše tak, jak je. Jinak je to úplně stejný index dehydratace, který se pečlivě snaží šetřit vaše peníze a čas.

Nabízí se otázka - pokud se podíváte na uživatelské rozhraní, je zde možnost vybrat obě možnosti současně. Jak bude takový kombinovaný režim fungovat?

Zjistíme to.

Začátek je standardní: okamžitě se vytvoří a zkopíruje záložní soubor. Do něj se vytvoří přírůstek a také se zkopíruje. To se děje až do okamžiku, kdy si uvědomíme, že soubory opustily naše provozní okno a objevil se zapečetěný řetěz. V tomto okamžiku provedeme dehydratační operaci a nahradíme tyto soubory fiktivními soubory. Na kapacitní střelnici samozřejmě znovu nic nekopírujeme.

Celá tato fascinující logika je zodpovědná za jediné zaškrtávací políčko v rozhraní: Kopírovat zálohy do úložiště objektů, jakmile jsou vytvořeny.

Proč potřebujeme tento režim kopírování?

Ještě lepší je přeformulovat otázku takto: před jakými riziky jsme s jeho pomocí chráněni? Jaký problém nám pomáhá vyřešit?

Odpověď je zřejmá: samozřejmě jde o obnovu dat. Pokud máme úplnou kopii místních dat na úložišti objektů, pak bez ohledu na to, co se stane s naším produktem, vždy můžeme obnovit data ze souborů umístěných v podmíněném Amazonu.

Pojďme si tedy projít možné scénáře, od nejjednodušších po složitější.

Nejjednodušší neštěstí, které může padnout na naši hlavu, je nedostupnost jednoho ze souborů v řetězci záloh.

Smutnějším příběhem je, že se zlomil jeden z rozsahů našeho úložiště SOBR.

Ještě horší je, když se celé úložiště SOBR stalo nepřístupným, ale kapacitní střelnice funguje.
A všechno je opravdu špatné - v tu chvíli zálohovací server zemře a vaším prvním přáním je pokusit se za deset minut doběhnout ke kanadské hranici.

Nyní se podívejme na každou situaci zvlášť.

Když jsme ztratili jeden (a dokonce několik) záložních souborů, pak vše, co musíme udělat, je spustit proces opětovného skenování úložiště a ztracený soubor bude nahrazen fiktivním souborem. A pomocí procesu rehydratace (o kterém byla řeč na začátku článku) si uživatel bude moci stáhnout data z kapacitní střelnice do místního úložiště.

Nyní je situace složitější. Předpokládejme, že náš SOBR se skládá ze dvou oblastí běžících v režimu Performance, což znamená, že naše .vbk a .vib jsou na nich rozmístěny v dost nerovnoměrné vrstvě. A v určitém okamžiku se jeden z rozsahů stane nedostupným a uživatel naléhavě potřebuje obnovit stroj, jehož část dat leží právě na tomto rozsahu.

Uživatel spustí průvodce obnovou, vybere bod, do kterého chce provést obnovu, a průvodce při práci zjistí, že nemá všechna data potřebná pro obnovu lokálně, a proto je třeba je stáhnout z natáčení kapacity galerie. Bloky, které zůstanou na místním úložišti, se zároveň nebudou stahovat z cloudu. Sláva indexu obnovení (ano, bylo to také zmíněno na začátku článku).

Podtypem tohoto případu je, že se celé úložiště SOBR stalo nepřístupným. V tomto případě nemáme co kopírovat z místního úložiště a všechny bloky se stahují z cloudu.

A nejzajímavější situace je, že záložní server zemřel. Zde jsou dvě možnosti: admin je skvělý a zálohoval konfiguraci a admin je sám zlý Pinocchio a zálohy konfigurace neprováděl.

V prvním případě mu bude stačit jednoduše někam nasadit čistou instalaci VBR a obnovit jeho databázi ze zálohy standardními prostředky. Na konci tohoto procesu se vše vrátí do normálu. Nebo bude obnoven podle jednoho z výše uvedených scénářů.

Pokud je ale admin buď svým vlastním nepřítelem, nebo se epickým selháním dočkala i záloha konfigurace, tak ani zde jej nenecháme napospas osudu. Pro tento případ jsme zavedli novou proceduru nazvanou Import Object Storage. Umožňuje přeskočit proces ručního znovuvytvoření úložiště SOBR a připojení kapacitní střelnice k němu s následným opětovným skenováním a jednoduše přidat objekt úložiště do rozhraní Vim a spustit proceduru Import Storage Repository. Jediná věc, která může stát v cestě mezi vámi a vašimi zálohami, je požadavek na zadání hesla, pokud byly vaše zálohy šifrované.

To je pravděpodobně vše o režimu kopírování a přejdeme k němu

Uzavřený režim

Hlavní myšlenkou je, že nové zálohy se nemohou objevit na vybraném rozsahu SOBR úložiště. Před v10 jsme měli pouze Maintenance Mode, kdy byla jakákoliv práce s repozitářem zcela zakázána. Jakýsi hardcore režim pro vypnutí úložiště, kde je k dispozici pouze tlačítko Evakuovat, které jednorázově přenese zálohy do jiného rozsahu.

A zapečetěný režim je jakousi „měkkou“ možností: zakážeme vytváření nových záloh a postupně mažeme staré podle zvoleného uchování, ale přitom neztrácíme možnost obnovy z uložených bodů. Velmi užitečná věc, když se nám buď blíží konec životnosti nějakého hardwaru a potřebujeme jej vyměnit, nebo jej jen potřebujeme uvolnit pro něco důležitějšího, ale není kam vzít a vše najednou přesunout. Nebo to nejde smazat.

Princip fungování je tedy poměrně jednoduchý: je nutné zakázat všechny operace zápisu (vznik nových dat), ponechání čtení (obnovení) a odstranění (uchování).

Oba režimy lze používat současně, ale mějte na paměti, že údržba má vyšší prioritu.

Jako příklad uvažujme SOBR sestávající ze dvou oblastí. Předpokládejme, že jsme první čtyři dny vytvářeli zálohy v režimu Forward Forever Incremental a poté rozsah zapečetíme, což vede k tomu, že iniciujeme vytvoření nového aktivního fullu na druhém dostupném rozsahu. Pokud je naše retence čtyři, pak když celý řetězec umístěný na zapečetěném rozsahu překročí své meze, je s čistým svědomím smazán.

Jsou situace, kdy k vymazání dojde dříve. Toto je například přírůstkové vpřed s periodickým zaplněním. Pokud jsme první dva dny vytvořili plné zálohy a ve čtvrtek se rozhodneme úložiště zapečetit, pak v pátek, když se vytvoří nová záloha, bude soubor pro pondělí smazán, protože do tohoto bodu neexistují žádné závislosti. A samotný bod nezávisí na nikom. Poté počkáme, až se vytvoří čtyři body na dostupném rozsahu a smažeme zbývající tři, které nelze smazat nezávisle na sobě.

Věci jsou jednodušší s Reverse Incremental. V něm nejstarší body na ničem nezávisí a lze je bezpečně smazat. Jakmile se tedy vytvoří nový .vbk na novém rozsahu, staré .vrbs budou jeden po druhém odstraněny.

Mimochodem, proč pokaždé vytváříme nové .vbk: pokud bychom ho nevytvářeli, ale pokračovali ve starém řetězci přírůstků, pak by staré .vbk zamrzlo na nekonečně dlouhou dobu v jakémkoli režimu a zabránilo by se jeho smazání. Proto bylo rozhodnuto, že jakmile bude rozsah zapečetěn, vytvoříme na volném rozsahu plnou zálohu.

S kapacitní střelnicí je to složitější.

Nejprve se podíváme na režim kopírování. Předpokládejme, že jsme čtyři dny aktivně vytvářeli zálohy a poté byla kapacitní střelnice zapečetěna. Nic nemažeme, ale pokorně snášíme retenci, načež data z kapacitní střelnice smažeme.

Přibližně to samé se děje v režimu přesunu – počkáme na retuš, smažeme starou v místním úložišti a smažeme tu uloženou v úložišti objektů.

Zajímavý příklad s Forever forward incremental. Retenci nainstalujeme ve třech bodech a v pondělí začneme vytvářet zálohy, které se pravidelně kopírují do cloudu. Po zapečetění úložiště se zálohy nadále vytvářejí se zachováním tří bodů, ale data uložená v pomlčce kapacity zůstávají závislá a nelze je smazat. Počkáme proto do čtvrtka, kdy naše .vbk přejde za retenci, a teprve pak celý uložený řetězec klidně smažeme.

A malé upozornění: všechny příklady jsou zde zobrazeny s jedním strojem. Pokud jich máte v záloze několik, jejich retuš se bude lišit v závislosti na tom, zda byl proveden Active Full či nikoli.

To je v podstatě vše. Pojďme tedy k té nejtvrdší funkci –

Nezměnitelnost

Stejně jako u předchozích bodů je první věcí, jaký problém tato funkce řeší. Jakmile své zálohy někam nahrajeme do úložiště, existuje silná touha zaručit jejich bezpečnost, tedy fyzicky zakázat jejich mazání a jakékoli úpravy během daného uchování. Včetně správců, včetně jejich kořenových účtů. To vám umožní chránit je před náhodným nebo úmyslným poškozením. Každý, kdo pracuje s AWS, se mohl setkat s podobnou funkcí zvanou Object Lock.

Nyní se podíváme na režim obecně a pak se ponoříme do detailů. V našem příkladu bude Immutability povolena pro naši kapacitní střelnici se zachováním čtyř dnů. A v záloze je povolen režim kopírování.

Neměnnost nijak neinteraguje s obecnou retencí. Nepřidává například body navíc ani nic podobného. Je to tak, že člověk nemůže odstranit záložní soubory do čtyř dnů. Pokud provedete zálohu v pondělí, budete moci její soubor smazat pouze v pátek.

Všechny dříve vysvětlené koncepty dehydratace, indexy a metadata nadále fungují naprosto stejně. Ale s jednou podmínkou – blok je nastaven nejen na data, ale i na metadata. To se provádí v případě, že se mazaný útočník rozhodne vymazat naši databázi metadat a zabránit tomu, aby se datové bloky změnily na zbytečnou binární kaši.

Nyní je skvělý čas vysvětlit naši technologii generování bloků. Nebo generování bloků. Chcete-li to provést, zvažte situaci, která vedla k jeho vzhledu.

Vezměme časové měřítko šesti dnů a níže označíme čas předpokládaného uplynutí neměnnosti. První den vezmeme a vytvoříme soubor skládající se z datového bloku a a jeho metadat. Pokud je neměnnost nastavena na tři dny, je logické předpokládat, že čtvrtý den budou data odemčena a smazána. Druhý den přidáme nový soubor2, skládající se z bloku b se stejným nastavením. Blok a je třeba odstranit čtvrtý den. Třetí den se ale stane něco hrozného – vytvoří se soubor File3, který se skládá z nového bloku d a odkazu na starý blok a. To znamená, že pro blok a jeho příznak neměnnosti musí být resetován na nové datum, které je posunuto na šestý den. A zde nastává problém - ve skutečných zálohách je takových bloků obrovské množství. A abyste prodloužili dobu jejich neměnnosti, musíte pokaždé podat obrovské množství požadavků. A ve skutečnosti to bude téměř nekonečný každodenní proces, protože s velkou pravděpodobností najdeme u každé kopie pořádné hromady deduplikovaných bloků. Co znamená velký počet požadavků od poskytovatelů úložiště objektů? Že jo! Obrovský účet na konci měsíce.

A abyste své oblíbené klienty z ničeho nic nevystavovali za nemalé peníze, byl vynalezen mechanismus generování bloků. Jedná se o dodatečné období, které připočítáváme k nastavené době neměnnosti. V níže uvedeném příkladu je tato lhůta dva dny. Ale to je jen příklad. Ve skutečnosti používají svůj vlastní vzorec, který dává přibližně deset dní navíc během měsíčního uzamčení.

Pokračujme v uvažování o stejné situaci, ale s generováním bloků. První den vytvoříme soubor1 z bloku a a metadat. Sečteme generační období a neměnnost – to znamená, že možnost smazat soubor bude šestý den. Pokud druhý den vytvoříme Soubor2, který se skládá z bloku b a odkazu na blok a, pak se s očekávaným datem smazání nic nestane. Stála stejně jako šestý den. A tím se snažíme ušetřit peníze na počtu požadavků. Jedinou situací, kdy lze termín posunout, je, že vypršela generační lhůta. To znamená, že pokud třetí den nový Soubor3 obsahuje odkaz na blok a, bude přidána generace 2, protože Gen1 již vypršela. A očekávané datum smazání bloku a se posune na osmý den. To nám umožňuje dramaticky snížit počet požadavků na prodloužení životnosti deduplikovaných bloků, což klientům ušetří spoustu peněz.

Samotná technologie je dostupná uživatelům hardwaru kompatibilního s S3 a S3, jejichž výrobci zaručují, že se jejich implementace neliší od implementace Amazon. Proto odpověď na legitimní otázku, proč Azure není podporována – mají podobnou funkci, ale funguje to na úrovni kontejnerů, ne jednotlivých objektů. Mimochodem, samotný Amazon má objektový zámek ve dvou režimech: compliance a governance. Ve druhém případě zůstává možnost, že největší admin nad admin a root nad rootem, navzdory uzamčení objektu, data stále smaže. V případě souladu je vše pevně přibito a nikdo nemůže zálohy smazat. Dokonce i admini Amazonu (podle jejich oficiálních vyjádření). Toto je režim, který podporujeme.

A jako obvykle několik užitečných odkazů:

• O Generování bloku v každém detailu.
• Veškeré informace o Veeam Backup & Replication 10 v tom nejlepším
• О Úroveň kapacity podrobně

Zdroj: www.habr.com