V předchozí článku Informovali jsme vás o nových funkcích v lednové aktualizaci Update 4 pro Veeam Backup & Replication 9.5 (VBR), kde jsme záměrně nezmínili zálohy na magnetické pásky. Příběh v této oblasti si zaslouží samostatný článek, protože nových funkcí bylo skutečně hodně.

– Kluci z QA, napíšete článek?
– Proč ne!

Magnetické pásky ve 21. století

Uložení dat na magnetických páskách (kazetách, „páscích“, jak je nazýváme v R&D) není omezeno na dávno minulý počítač ZX-Spectrum, jehož jedna hra se mohla načítat do operační paměti 48 kb z magnetofonové kazety několik minut. Během čtvrt století se rychlost a kapacita kazet zvýšily o 6-7 řádů. Tohle srovnání není úplně správné, a podle Mooreova zákona standard LTO nedokáže držet krok. Nicméně moderní technologie umožňují zapsat na kilometr dlouhou pásku jedné kazety 12 terabajtů dat (až 30 terabajtů v kompresním režimu), což znamená, že 160dolarové úložiště předčí konkurenci v nákladech na dlouhodobé uložení velkého objemu dat, i když započteme investice do zařízení na zápis/čtení. Data na takových kazetách jsou bezpečně uchovávána 15-30 let.

Podívám se na to z jiného úhlu. V poslední době ransomware dosáhl nového levelu. Může čekat na svůj okamžik v infrastruktuře velké společnosti týdny a měsíce, a s příchodem nové zranitelnosti zero-day – zničit (ne bez pomoci lidí, když jde o velké peníze) nejen všechna data, ale i všechny zálohy, k nimž je možné se dostat. Tady čerstvý příklad, kdy musela společnost zaplatit vyděračům. Takzvané air gap, tedy fyzicky izolované zálohy od infrastruktury se staly v podstatě jediným spolehlivým záchranou před takovými situacemi. Magnetická páska zde – jedno z nadčasových řešení.

Ale jedno specifikace a technologické železo a baryt-feritové novinky od předních výrobců (IBM, HPE, Oracle, Dell) nestačí k spolehlivé ochraně dat, je zapotřebí dobrý software. U nás v Veeam je celý tým, který se zabývá zálohami na páskách, zhruba 10 lidí denně analyzuje, plánuje, zkoumá, vyvíjí a testuje. Výsledky této práce jste mohli vidět v předchozích článcích (jedna, dva). Co se tedy stalo za poslední rok?

Glosář

Stojí před námi volba mezi svobodou vyjadřování v mateřském jazyce a formalismy, které komplikují čtení. Preferuji první, proto se předem omlouvám, pokud někomu žargonové výrazy ze seznamu níže budou drásat oči. Zde se krátce připomenu, co který termín znamená.

Koryfejům VBR tuto část lze přeskočitJob – job – úkol zálohování. Vlastně celý VBR je postaven na jobech. Kromě zálohování a replikace může jít také o kopírování na magnetickou pásku (backup to tape job, tape job). Rád bych poznamenal, že obnova ze zálohy (restore) je také job, ale v tomto článku se pod tímto slovem bude rozumět právě záloha.

Storage – storage – historicky ustálený název. Jsou to soubory v repozitáře (repository – úložiště), obsahující zálohy – úplné a inkrementální. V jednom storage může být jak jedna, tak i více virtuálních strojů.

Řetězec – chain – sekvence vzájemně spojených storages. Pro obnovení dat z n-tého inkrementálního storage jsou potřeba všechny předchozí od (n-1)-tého po 1. a kompletní storage, na které se odkazuje první inkrementální.

Source, target – source, target. Source – výchozí entita, se kterou job pracuje. V případě záloh/replik je to obvykle virtuální stroj v hypervizoru. V případě tape job je source samotný backup job (nebo soubory v případě file to tape job). Target pro backup job je repository, kde se zálohy uchovávají. Pro tape job je to však media pool.

Media pool – media pool – skupina informačních nosičů, v našem případě – kazet. Logický kontejner, který uživatel vytvoří a který obsahuje kazety jedné nebo několika knihoven. Tape job tedy vždy má media pool jako target, což znamená, že data se nepíší na konkrétní kazetu a ne na jakoukoli kazetu v knihovně, ale na určitou sadu. Media pool má nastavení doby uchovávání dat, po jejímž uplynutí může být kazeta přepsána. Uživatel může vytvářet běžné (standard) a GFS pooly. Každý z těchto typů může být nyní také WORM a ne-WORM, o tom níže.

Media set – media set – soubor kazet v mediálním poolu, na které se nepřetržitě zapisují zálohy/soubory. Pro GFS pooly mají mediální sety také vazbu na interval (například roční – yearly), kazety se rotují pouze uvnitř svého intervalu.

Drive, měnič – prvky tape knihovny. Drive čte a převíjí kazetu, měnič – to je robot, který přesouvá kazety mezi sloty pro ukládání, sloty pro vyjmutí a drive. Existují také standalone drives (standalone – samostatný), roli měniče zde plní člověk. Pro drive je nezbytně nutné mít správně nainstalovaný ovladač výrobce na Windows stroji, ke kterému je knihovna připojena; s měničem však můžeme pracovat i bez ovladačů, prostřednictvím native SCSI.

Tenant to tape. Ochranný provider – chránění klienti

Karty na stůl. Největší funkce naší aktualizace, určená pro cloudových poskytovatelů, kteří ve své infrastruktuře používají VBR. Vývoj byl zahájen už před dvěma lety. Brzy jsme si uvědomili, že se s tak vážným úkolem do nejbližšího vydání nestihneme vypořádat, vzali jsme si malou pauzu a nakonec jsme funkci vydali v 9.5 Update 4.

Pokud to shrneme, nyní mají provideri možnost kopírovat zálohy svých klientů na kazety pomocí tape job v GFS poolu. To dává providerům – a to jsou velmi cenní lidé pro náš obchod a naši komerční oddělení – dvě možnosti:

• chránit své klienty (tenants, tenant – nájemce) před ztrátou dat v důsledku náhodného smazání nebo infrastrukturních problémů („povodně v serverovně“);
• poskytnout tenantům další službu pro obnovení dat ze staré zálohy, která byla již dávno odstraněna z cloudového úložiště podle zásad uchovávání dat, ale na kazetách stále zůstal.

Z marketingového hlediska je funkčnost velmi "chuťově zajímavá", z naší strany – neméně složitá na realizaci.

Vývoj

Hlavním vzniklým problémem je šifrování dat. Většina cloudových záloh je zašifrovaná, statistiky ukazují, že ⅔ z celkového množství. Pro nás bylo toto číslo překvapením, předpokládali jsme, že se šifruje téměř všechno, ale ne – mnoho klientů se zdá být bezvýhradně přesvědčeno o svých providerech.

Paradigma je jednoduchá: poskytovatel by neměl být schopen dekódovat data svých tenantů. Současně bude na straně poskytovatele v rámci nové funkce nutné otevírat úložiště s zálohami. Je to potřeba k přesunu bloků dat, například pro vytvoření virtuální úplné zálohy. Hlavní je, že to musí být prováděno nezávisle na tenantovi, když jsou potřebné klíče během vykonávání úlohy nepředávány na stranu poskytovatele.

Řešení tohoto problému, které bylo mimochodem zapojeno i do jiné důležité funkce nového dodatku – Kapacitní úroveň – spočívá v přidání dalšího šifrovacího klíče. Archivační klíč (Archive key) je uchováván v databázi poskytovatele v zašifrované podobě. Pomocí této rafinované schémy lze na straně poskytovatele otevřít úložiště, přesouvat a přešifrovávat bloky dat mezi úložišti (každé má svůj klíč), ale nelze dekódovat samotná data.

Rafinovaná schéma (pracovní varianta)

Přidám, že všichni inženýři v R&D velmi milují šifrování v našem produktu, ale nikdo neví ve všech detailech, jak to funguje. (Tady byla také vtipná poznámka „a proč vůbec funguje“, ale ta byla redaktory vynechána.)

Testování

Na funkci bylo zaznamenáno stovky chyb. Nejproblematičtější oblasti – šifrování, uživatelské rozhraní, problémy při obnově.

Z hlediska testování představovala obtížnost velká variabilita, „kombinatorika“ druhů a typů tenantních úloh a repozitářů – mám na mysli jak zdroj, tak cíl při obraně záloh do infrastruktury. Vše se to navléká na logiku v rámci modelu GFS (včetně nového – paralelismus a každodenní mediální sety, o tom níže), a celkově na nezvyklou pro typy cloudovou specifikaci. Nezapomeňte bohatě okořenit šifrováním. Pokud bychom pokračovali v metaforě, pořádně jsme se najedli tohoto jídla – ale ochutnali jsme to ze všech stran.

Fragment testovacího plánu

V důsledku

Podrobné popisy lze nalézt v uživatelské příručce (prozatím v angličtině): záloha, obnova. Zastavím se na hlavních momentech.

Záloha

Poskytovatel přidává tenanty do typové úlohy s GFS poola jako cílem. Při přítomnosti cloudové licence je ve druhém kroku wizardu dostupná možnost TenantiLze přidat všechny tenanty najednou nebo jednotlivě, a také si vybrat pouze určitou kvótu (ale ne subkvótu) jednotlivého tenanta. Není možné míchat tenantské zálohy a obvyklé lokální zálohy v jedné práci.

Ostatní nastavení jsou téměř úplně identická jako u běžné úlohy v GFS pool.

Obnova dat je možná jak na straně poskytovatele, tak na straně samotného tenanta.

Obnova na straně poskytovatele

Probíhá prostřednictvím nového průvodce. Zde je možné se dostat až k jednotlivé úloze, obnovuje se celá řetězová záloha, která se nacházela ve skladu v určitém dni.

Existují tři varianty obnovy:

1. Do výchozí lokace. V tomto případě je originální záloha, pokud existuje, odstraněna; úlohy tenanta se automaticky přenastavují na obnovený řetězec. Předpokládá se, že taková obnova bude pro zákazníka zcela nepozorovatelná, pouze na krátkou dobu bude odpojen od cloudového skladu.
2. Do nové kvóty/úložiště. Poskytovatel může například vytvořit pro tento účel samostatný dočasný účet, který následně odstraní. Záloha se v infrastruktuře tenanta objeví po synchronizaci s databází poskytovatele.
3. Jednoduše na disk Linux nebo Windows serveru, registrovaného v infrastruktuře poskytovatele. Tuto řetězovou zálohu je možné poté zapsat na USB a zaslat tenantovi.

Obnova na straně tenanta

Tato volba předpokládá, že má klient vlastní tape infrastrukturu a velký objem dat pro obnovu. Kartu s nahranými zálohami může poskytovatel fyzicky zaslat klientovi přepravní službou, klient ji katalogizuje na svém vybavení, dešifruje kazety a zálohy a pracuje s nimi, jako by je sám zapsal na pásku. Toto je takový tip, jak nestahovat terabajty po WAN.

Rozsáhlá vylepšení GFS poolu

GFS-media pooly se objevily ve VBR před dvěma lety, ve verzi 9.5. V novém aktualizaci, jak s ohledem na vznik funkce tenant to tape, tak na žádost uživatelů, jsme tuto funkcionalitu výrazně vylepšili.

Denní mediální sety

Objevil se nový denní (daily) mediální sada. Nyní lze v GFS poolu uchovávat zálohy za každý den, a nejen celkové, ale i inkrementální. Ty zabírají podstatně méně místa, což bylo provedeno za účelem úspory pásky. Předpokládá se, že tyto kazety jsou neustále rotovány v knihovně a nejsou odesílány na vzdálené úložiště. Přitom pro restauraci z inkrementálního bodu budou potřeba kazety jedné z vyšších mediálních sad (týdenní, měsíční, čtvrtletní nebo roční). Aktivovat denní mediální sadu bez aktivace týdenní není možné, aby bylo v drtivé většině případů třeba pro obnovu z inkrementální kopie použít právě týdenní kazety. Ty jsou buď vždy v knihovně, nebo uchovávány na méně vzdáleném skladu.

Logika fungování tape jobu v GFS mediálním poolu není zcela jednoduchá, techničtí spisovatelé to potvrdí. Pokud to shrneme stručně, bez podrobností, do týdenních a vyšších mediálních sad se kopírují pouze celkové zálohy (včetně virtuálních celkových záloh), po jedné za každý datum, zatímco do denních se kopírují všechny zálohy umístěné v repozitáři za aktuální den, protože backup job může být spuštěn častěji než jednou za den.

Paralelismus, čas spuštění a čekání v GFS poolech

Nyní je možné paralelní zápis několika řetězců nebo jobů na několika discích knihovny i v GFS mediálních poolech (dříve pouze v běžných). Aktivuje se v kroku Options mediálního poolu.

Důležité upřesnění: stejný soubor je vždy zapisován v jednom vlákně, takže v případě několika velkých virtuálních strojů se doporučuje aktivovat nastavení per-VM na repozitáři, aby záloha obsahovala několik řetězců.

Kromě toho je nyní možné vybrat čas spuštění samotné GFS joby. Mnoho uživatelů nemělo rádo spuštění o půlnoci a následné čekání téměř celý den, než bude source job dokončena. Nyní lze tento čas například nastavit na pozdní večer, kdy už je co kopírovat na pásku. Navíc na základě žádosti uživatelů jsme do pokročilých nastavení přidali možnost, kterou bylo možné dříve aktivovat pouze pomocí registru. Stačí vybrat Zpracovat nejnovější obnovovací bod místo čekání – a na kazetu se kopíruje to, co je v repozitáři v okamžiku spuštění tape jobu (například včerejší stav), žádné čekání není.

Vylepšená práce s více knihovnami

Bude se hovořit o situaci, kdy bylo do jednoho mediálního poolu přidáno více než jedna knihovna. Tuto situaci jsme zvládali i dříve, ale čas od času se objevovali klienti se stížnostmi na poněkud nepředvídatelné chování.

Bylo

Například se spustil tape job, zabral dvě jednotky v první knihovně, ale nastavení paralelismus umožňuje použít současně 4 jednotky. Měla by se tato job přepnout na druhou knihovnu mediálního poolu a využít ji také, nebo by to byla plýtvání prostředky?

Další případ. Byla zvolena možnost přepnout se podle podmínky „žádné dostupné kazety“, v první knihovně je pouze jedna kazeta, ale na ni se potenciálně vejdou všechna data. Nicméně nastavení umožňují zapisovat současně na dvě kazety. Měla by se v tomto případě zapojit druhá knihovna?

Rozhodli jsme se uspořádat tuto oblast, čímž jsme umožnili jednoznačné nastavení chování.

Stalo se

Knihovny v mediálním poolu mají role – aktivní a pasivní. A samotný mediální pool má dva režimy: odolný vůči výpadkům, nebo failover (failover) a paralelní zápis (paralleling). Nyní lze podle požadavků mediální pool nakonfigurovat různými způsoby.

• Pokud máte několik rovnocenných knihoven a potřebujete rozdělit zápis mezi ně – zapněte režim paralelního zápisu, všechny knihovny musí mít přiřazené aktivní role. V tomto případě budou nové kazety a jednotky zapojeny ihned, jakmile se bude potřeba, bez ohledu na to, v jaké knihovně se nacházejí. Priorita stále existuje – nejdříve se budeme snažit najít prostředky v knihovně, která je výše na seznamu.
• Pokud máte jednu hlavní knihovnu a jedno starší nebo standalone zařízení jako zálohu, zapněte režim failover, dejte hlavní knihovnu nahoru na seznam a vyberte pasivní roli pro rezervní zařízení. Přepnutí na toto zařízení se uskuteční pouze tehdy, když to bude skutečně nezbytné, aby job vůbec nějakým způsobem fungoval. Tato situace bude považována za nestandardní a bude zaslán e-mail s upozorněním.

Existuje složitější situace, kterou zatím nepodporujeme – několik aktivních knihoven při přítomnosti pasivních. Zpětná vazba ukáže, zda je potřeba takových konfigurací a zda je nutné funkci v budoucnu "vylepšit". Standardní praxe.

Podpora WORM

WORM – Write Once Read Many – kazety, které nelze smazat nebo přepsat na úrovni hardware, lze pouze přidávat data. Jejich povinné použití je regulováno pravidly některých organizací, například těch, které pracují v oblasti medicíny. Hlavní problém s těmito kazetami dříve spočíval v tom, že VBR při inventarizaci nebo katalogizaci zapisoval titul, který již nelze smazat, a tape joby selhaly s chybou při takovém pokusu.

Ve verzi 9.5 Update 4 byla implementována plná podpora těchto kazet. Byly přidány WORM média pooly, běžný a GFS, do kterých lze umístit pouze kazety tohoto typu.

Nové kazety mají modrou, "zmrazenou" ikonu. Z pohledu uživatele se práce s WORM kazetami neliší od práce s běžnými.

"Wormovost" kazet se zpravidla určuje podle sufixu čárového kódu. Pokud je však čárový kód běžný nebo nečitelný, informace poskytuje ovladač po prvním vložení kazety. Umístit WORM kazety do běžného média poolu a zapisovat na ně nebude možné. Zábavné je, že už se našli uživatelé, kteří nalepovali WORM čárové kódy na běžné kazety a byli překvapeni změnami ve své infrastruktuře po aktualizaci.

Čip kazety

Současně s implementací nepermanentních kazet jsme začali pracovat s čipem. Standardní atributy v čipu jsme dříve nepoužívali, nyní do některých z nich zapisujeme a čteme, ale nevnímáme je jako hlavní zdroj dat. Hlavním orientačním bodem je stále titul kazety. Tento přístup se ukázal jako správný: po měsíci od vydání vidíme, jak "zoo" hardware uživatelů přináší překvapení ohledně práce s čipem.

Zálohování NDMP svazků na pásku

Na závěr – o nejžádanější funkci z hlediska počtu zpětných vazeb tohoto Update. Stalo se dostupné zálohování NDMP svazků na kazety. Do infrastruktury VBR je nutné přidat NDMP server, po kterém bude možné v souborové tape-job vybrat objemy z tohoto hostitele. Ty se ukládají na pásky ve formě souborů se speciálním atributem, aby se odlišily od běžných při katalogizaci.

V první implementaci existují určité omezení: nejsou podporována rozšíření (extensions), navíc je možný pouze zálohování a obnova celého objemu, nikoli jednotlivých souborů. Zálohování probíhá přes dump (v případě NetApp – ufsdump), zde jsou své zvláštnosti: maximální počet inkrementálních bodů – 9, po kterých se vyžaduje úplná zálohovací kopie.

Na závěr

To byly pouze největší novinky v oblasti zálohování na magnetickou pásku ve VBR 9.5 Update 4. Další změny uvedu v seznamu:

• možnost zadání pořadí source-job a souborů v tape-jobs;
• přidána role Tape Operator (uživatel může dělat vše kromě obnovy z pásky – na to je zde Restore Operator);
• přidány plnohodnotné include/exclude masky v souborové tape-jobs (kromě NDMP);
• vylepšena obnova v souborové tape-jobs (složka se obnovuje s těmi soubory, které tam byly v okamžiku zálohování, a ne se všemi, které v ní kdy byly – velmi žádaná funkce, mimochodem);
• zvýšena rychlost obnovy velmi velkého počtu souborů z kazet;
• vylepšen algoritmus výběru další kazety pro zápis, zejména při stejných podmínkách zohledňujeme objem zapsaných/přečtených dat za celou její životnost, bereme nejnovější;
• zlepšena stabilita produktu.

Užitečné odkazy

Pro zpestření uvádím několik odkazů i na ruské zdroje:

• Odkaz na stažení bezplatné zkušební verze VBR 9.5 Update 4
• Článek na Habru „Užitečné tipy pro archivaci záloh Veeam na magnetickou pásku“
• Článek na Habru „7 užitečných tipů pro ochranu záložních kopií před ransomwarem“
• Sekce uživatelské příručky týkající se pásek (v anglickém jazyce)
• A vracíme se na předchozí místo průvodní videa „Jak to funguje“ (pravda, zatím v anglickém jazyce) – lze se podívat zde. O pásech se hovoří na slajdech 95 – 102.

Zdroj: habr.com