Z V L Á Š T N Í N E P R O D E J N Á P Ř Í L O H A | D U B E N 2 0 1 5

Zálohování a obnova po havárii

2015

S I LV E R P A R T N E R S

Zalohovania obnova dat_2015_DEF.indd 9 4/23/15 11:43 AMBez názvu-5 obIBez názvu-5 obI 23.04.15 15:2123.04.15 15:21

ZÁLOHOVÁNÍ A OBNOVA DAT

II CO M P U T E RWO R L D 4 | 2015

Chytré strategie pro ochranu datObnova po havárii a nepřetržitý provoz (kontinuita podnikání) mohou být nejdůležitější odpovědnosti IT. Klíčem k úspěchu je vytvořit společnými silami chytré zásady a poté nasadit odpovídající technologie.

MATT PRIGGE

Data jsou jako kyslík. Bez nich začne většina moderních organizací rychle lapat po de-chu a v případě, že zůstanou příliš dlouho

bez dat svých zákazníků, transakcí či výrobních údajů, nastane jejich smrt.

Hrozby pro data číhají všude – od přírodních katastrof a epidemie malwaru až po obyčejné lidské chyby, jako je například neúmyslné sma-zání. IT oddělení však věnují překvapivě málo času vytvoření infrastruktury a zásad nezbytných pro ochranu dat, které firmy potřebují ke svému přežití.

A výsledek? Špatně plánované ad hoc meto-diky obnovy a zachování nepřetržitého provozu, jimž nikdo plně nerozumí a které často zastarají dříve, než dojde k jejich implementaci.

Úspěch v současném prostředí soustředěném kolem dat vyžaduje obnovené zaměření na ob-novu po haváriích (DR, Disaster Recovery) a po-stupy a zásady k zajištění nepřetržitého provozu (BC, Business Continuity).

Není to však jen problém IT. Ztráta dat ovliv-ňuje každou část každé organizace. Proto se musí jednotlivá zúčastněná strana – od vedení

společnosti až po provoz a údržbu – zahrnout do rozhodování týkajícího se vlastnictví dat.

Tento typ přístupu ke spolupráci ale není ani snadný, ani levný. Umožní však IT personálu i ostatním zástupcům firmy najít společně vhodný způsob a důvody, jak a proč investovat do DR a zachování nepřetržitého provozu. Ještě důležitější ale je, že v případě havárie bude každý vědět, co může čekat a jak má vhodným způsobem reagovat.

Co je DR a BC?Obnova po havárii a udržení nepřetržitého pro-vozu mohou mít různý význam pro různé lidi. Základní koncepty jsou však stejné: Nasazení správných zásad, postupů a vrstev technologií, které umožní organizacím i nadále fungovat v případě, že nastane havárie.

Může to sahat od něčeho tak jednoduchého, jako je snadná dostupnost záloh v případě se-lhání hardwaru, až po téměř okamžité převzetí funkce při selhání pomocí sekundárního dato-vého centra, když dojde ke zničení primárního centra v důsledku nějaké kataklyzmatické události.

Obecně řečeno je DR řada postupů a zásad, které při správné implementaci umožní vaší or-ganizaci obnovu, když dojde ke katastrofě posti-hující data. Jak dlouho trvá obnova a jak stará data budou k dispozici, jakmile dojde k obnově, závisí na hodnotách cíle času obnovy (RTO, Re-covery Time Objectives), respektive cíle bodu obnovy (RPO, Recovery Point Objectives).

Tyto hodnoty by měli všichni zástupci firmy, odpovědní za příslušné oblasti, jednoznačně ur-čit. Úkolem DR není poskytnout konzistentní čas zprovoznění, ale zajistit, že svoje data doká-žete obnovit v případě, že dojde k jejich ztrátě, nedostupnosti či ohrožení. Komplexní plán ob-novy po havárii bude také obsahovat vše po-třebné, abyste své prostředí postavili zpět na nohy včetně toho, jak a kde jsou uložené sady zá-loh, jak je lze získat, jaký hardware je potřebný pro přístup k nim, kde lze získat náhradní hard-ware, pokud jsou primární systémy nedostupné, zda bude zapotřebí instalační médium pro apli-kace atd.

Systémy pro zachování nepřetržitého provozu se zaměřují na zmírnění či neutralizaci dopadů havárie formou minimalizace přerušení fungo-vání firmy. Obvykle se přitom spoléhá na hard-ware s vysokou dostupností (HA, High Availabi-lity) – tedy na redundantní systémy provozované v reálném čase s reálnými daty, takže když jeden ze systémů selže, ostatní téměř okamžitě přebe-rou jeho zátěž s malým či žádným dopadem na podnikové procesy.

Událost HA (jako je například převzetí služeb clusterovým uzlem při selhání) může způsobit přerušení služby na dobu v řádu minut, zatímco obnova ze zálohy na nový hardware může trvat i několik hodin nebo dnů – zejména pokud není náhradní prostředek okamžitě k dispozici.

Nasazení HA systémů však neznamená, že by nemohla nastat havárie. Vždy budou existovat vektory selhání, jako jsou poškození dat, softwa-rové závady, přepětí v elektrorozvodné síti či bouřky, které mohou zdolat každý redundantní systém, zpustošit data, a tak vám zkazit den.

V souvislosti se systémy HA je nutné mít na paměti, že jen snižují pravděpodobnost výskytu havárie, ale nezajišťují proti ní imunitu.

BC propojuje cíle dostupnosti HA s cíli ob-novy DR. Pečlivě koncipovaný návrh BC vám tedy umožní obnovu z úplné havárie s jen ome-zenou dobou výpadku a s téměř nulovou ztrátou dat. Je to zdaleka nejčastěji používaný a také nejdražší způsob, ale mnoho podniků došlo k závěru, že data jsou pro jejich každodenní provoz natolik důležitá, že o významu BC nelze pochybovat.

Vytvoření zásadExistují čtyři hlavní etapy, jak vytvořit konzis-tentní zásady BC a DR ve firmě. Prvním úkolem

CW4-II-VI.indd IICW4-II-VI.indd II 23.04.15 13:4823.04.15 13:48

CO M P U T E RWO R L D.C Z III

▶

ZÁLOHOVÁNÍ A OBNOVA DAT

je definovat rozsah, který podrobně určí aplikace podléhající těmto zásadám. Ve druhém kroku je nutné definovat rizika, před nimiž se snažíte chránit svou infrastrukturu.

Třetím úkolem je pak definovat přesné poža-davky zásad, pokud jde o parametry RTO a RPO pro jednotlivé kategorie rizik, které jste dříve de-finovali. A teprve poté, co jste dokončili tyto kroky, můžete určit technologické stavební bloky, jež budete pro zajištění definovaných zá-sad potřebovat.

Během tohoto procesu je důležité zapojit zod-povědné firemní osoby do procesu rozhodování nehledě na to, jak netechnicky založení dotyční jednotlivci jsou. Ve skutečnosti čím méně tech-nicky orientované tyto osoby jsou, tím důleži-tější je, aby se procesu účastnily.

Nesprávné stanovení požadované maximální doby výpadku a minimální rychlosti obnovy totiž může mít zcela zničující důsledky spojené i s ukončením kariéry.

RozsahPři zvažování rozsahu plánu BC/DR je důležité posoudit nejprve důležité programy, se kterými pracují uživatelé. Když začnete z perspektivy aplikace a potom zjistíte vše, co potřebuje ke svému fungování, najdete veškerou související infrastrukturu a data.

Pokud naopak začnete od infrastruktury a směřujete k aplikaci, je snadné přehlédnout věci, které příslušný software potřebuje ke svému fungování. Například můžete vytvořit bezchybné zálohování aplikace a databázových clusterů, ale přesto zapomenout na sdílený disk obsahující klienta aplikace se všemi jeho obtížně nastavitelnými konfiguračními daty.

Přestože dává velký smysl oddělit méně důle-žité programy od těch, na kterých podnik silně závisí, je stále běžnější vidět, že zásady BC/DR pokrývají téměř veškerou základní infrastruk-turu IT.

Je to především důsledek popularity virtuali-zace serverů, konvergence sítí a centralizace prostředků primárních úložišť. V takových pro-středích mohou zásady BC/DR, které se snaží chránit důležité aplikace zajišťované malým sou-borem virtuálních strojů, dopadnout celkem snadno tak, že budou zahrnovat téměř všechny hlavní prostředky datového centra.

To sice není nutně špatná věc, ale může to vý-razně zvýšit náklady.

RizikaPo stanovení rozsahu pravidel je dalším krokem určit, jaká rizika se zásady pokusí řešit. Archi-tektury IT jsou zranitelné velkým množstvím si-tuací, počínaje selháním disku až po přírodní ka-tastrofy typu záplava.

Obvykle téměř všichni budou chtít plán pro běžná rizika, jako je selhání hardwaru, ale ně-které organizace se mohou rozhodnout, že nebu-dou chtít mít plány i pro méně pravděpodobné situace, jako je například pandemická epidemie.

Není neobvyklé vidět významné investice vy-nakládané ve snaze zmírnit následky katastrof, kterým by nemohl základní podnikový provoz (zejména lidské zdroje) v žádném případě odolat.

Znalost, vůči jakým rizikům jsou či naopak nejsou firemní data chráněná, je rozhodující pro důkladné plánování a implementaci. Bez ohledu na to, co se vaše organizace rozhodne udělat, je nejdůležitější, aby každý od úrovně ředitelů níže chápal výsledná rozhodnutí.

PožadavkyPoté, co jste stanovili rozsah a určili rizika, je čas určit pevná čísla, jak rychle se má podle zásad BC/DR uskutečnit obnova. Přinejmenším by to mělo zahrnovat cíle týkající se doby obnovy a bodů obnovy.

Vaše organizace se však může rozhodnout po-užít různé požadavky RTO/RPO pro rozličné typy potíží.

Například můžete vyžadovat RTO 30 minut a RPO 15 minut pro případy, kdy se mimořádně důležité databázové aplikace setkají se selháním hardwaru či softwaru, ale stejně tak může být vaše firma spokojená s delšími časy RTO/RPO v situaci, kdy dojde ke zničení celé budovy ohněm, a zaměstnanci se tak nebudou moci vrátit do práce.

Samozřejmě že bychom všichni chtěli mít čas obnovy blízký nule a stejně tak i nulové ztráty dat. Přestože je to v současné době s dostupnými technologiemi možné, může to být zároveň až příliš drahé.

Definování požadavků zásad je tedy balanco-váním mezi relativními náklady za zajištění velmi nízkých RTO/RPO a ztrátami vznikajícími přerušením podnikového provozu nebo ztrátou dat. Je nicméně důležité, aby se nejprve diskuto-valo o tom, co organizace skutečně potřebuje, aby zůstala životaschopná, a teprve potom, kolik stojí možnosti obnovy. Příliš často se stává, že vysoké ceny odradí IT personál, takže nenabíd-nou rychlejší řešení RTO/RPO, protože se bojí výsměchu.

Pokud konečná analýza rozpočtů nepodpoří dražší možnosti, může dojít ke kolektivnímu rozhodnutí snížit nároky, ale dojde k tomu na základě plného pochopení situace.

Jste připraveni i na selhání cloudu?JOHN GRADYNavzdory všemu humbuku kolem cloudu je jedna věc jistá: Není dokonalý. I v případě, že používáte nejserióznější cloudové služby a produkty, se prostě něco může čas od času pokazit, takže připravenost na selhání tohoto typu je velmi důležitá.

Nejprve je dobré si zkontrolovat smluvní podmínky u všech využívaných cloudových služeb. Někteří poskytovatelé cloudu například odvádějí v oblasti zálohování a obnovy dat velký kus práce, zatímco jiní se tím téměř nezabývají. Ukládá váš poskytovatel cloudu data do více datových center, aby eliminoval jedno místo selhání? Pokud ne, měli byste co nejdříve uvažovat o změně, abyste se vyhnuli potenciální katastrofě.

Zatímco více datových center a kvalitní služby zálohování a obnovy jsou užitečné, mohou vám také dávat falešný pocit bezpečí. Jinými slovy, je ještě mnohem více toho, co můžete (a co byste měli) udělat pro ochranu svých dat. Nenechávejte záležitosti pouze v rukou svého poskytovatele služeb. Zde je několik kroků, které můžete sami udělat, abyste omezili důsledky možných výpadků cloudu:

Vše si zálohujte. Pokud jde o radu týkající se zálohování dat, současná praxe dopo-ručuje používat cloudová řešení. Je to chytrý tah, ale rovnice platí i obráceně. Pokud ukládáte vše v cloudu, možná nebudete moci přistupovat k datům, když nastanou vý-padky nebo další závady.

Přestože se většina velkých poskytovatelů cloudu snaží rychle překonávat výpadky, nemusí to být příliš platné, když přístup k datům potřebujete hned. Kromě toho, když jsou všechna vaše data uložená jen v cloudu, riskujete, že je ztratíte navždy. Bohužel se to občas stává, takže nejlepším způsobem, jak se tomu vyhnout, je zálohovat alespoň kritická data na lokální server.

Navykněte si ukládat data na lokální server vždy, když je ukládáte do cloudu. Může to znít jako komplikace a také to tak může být. Existuje však mnoho aplikací, které to udě-lají automaticky za vás a jejich nastavení exportu dat je snadné spravovat. Může se to zdát jako zbytečné ukládat soubory na všechna místa, ale vyplatí se to, pokud to zajistí prevenci trvalé ztráty dat nebo to jen umožní přístup k datům, když to budete nejvíce potřebovat.

Šifrujte data, která ukládáte do cloudu. Možná že vaše společnost neukládá mnoho citlivých informací. Je však jisté, že některé interní informace by se neměly do-stat do špatných rukou. Cloud je velmi bezpečný, ale byly doby, kdy věci probíhaly špatně. V případě vysoce citlivých dat je důležité je před uložením do cloudu zakódovat. Není to nijak krkolomné: Můžete použít Boxcryptor nebo podobné programy, které rychle a efektivně zašifrují data, jež se rozhodnete uložit do cloudu. Jsou kompatibilní s většinou populárních cloudových služeb a navíc bývají i zdarma a snadno se používají.

Zálohujte si také streamovaná média. Pokud vaše firma využívá technologii strea-mování médií a služby, jako jsou YouTube nebo Spotify, měli byste smůlu, když by v těchto službách nastal problém. Skvělým pomocným řešením je ukládat si důležité audio - a videosoubory i další média u sebe na pevný disk a teprve poté použít server, aby tento obsah zpřístupnil více zařízením. Můžete streamovat cokoliv ze své sbírky do mobilních zařízení, dalších počítačů, chytrých televizí, set -top boxů atd. i v případě, že by nastaly problémy s vaším poskytovatelem streamovací služby.

Pojištění pro přerušení provozu firmy. Může si vaše společnost dovolit ztratit pří-stup k datům nebo přejít do režimu off-line na krátkou dobu? Pokud ne, možná byste mohli uvažovat o pojištění pro případ přerušení provozu firmy, které může pokrýt ně-které náklady vznikající v případě výpadků či ztráty dat. Toto pojištění se může vztaho-vat i na následné ztráty zisku.

CW4-II-VI.indd IIICW4-II-VI.indd III 23.04.15 13:4823.04.15 13:48

ZÁLOHOVÁNÍ A OBNOVA DAT

IV CO M P U T E RWO R L D 4 | 2015

Stavební blokyPoté, co získáte solidní představu o službách, které potřebujete chránit, o rizicích, před nimiž je chcete chránit, a o svých cílích obnovy, mů-žete začít hledat technologické stavební bloky potřebné k zajištění takových zásad. Vzhledem k ohromnému množství různých dostupných ře-šení skutečně neexistuje jen jediný správný způ-sob ochrany libovolné infrastruktury.

Trikem pro návrh dobrého řešení BC/DR je možnost považovat každou komponentu za vrstvu ochrany, každou s různými schopnostmi, které se vzájemně zkombinují a poskytnou kom-plexní řešení.

■ Softwarové stavební blokySrdcem každé strategie BC/DR je software. Obecně řečeno to zahrnuje minimálně jeden druh zálohovacího softwaru pro obnovu po havá-rii, ale je možné také využít zálohování či repli-kaci na aplikační úrovni nebo dokonce plně vy-bavený, hostitelsky založený replikační software pro dosažení cílů nepřetržitého provozu.

Zálohování založené na agentech – Tra-dičně nejčastější softwarová komponenta, kterou uvidíte, je zálohovací nástroj založený na agen-tovi. Tento systém obecně využívá jednu nebo více centralizovaných serverových instalací pro získávání zálohovaných dat od softwarových agentů nainstalovaných v rámci jednotlivých serverů, které chcete chránit, a zálohy pak ukládá na pásky, přímo připojené disky (DAS) nebo na jiný storage hardware.

Dojde -li ke katastrofě a ke ztrátě dat, lze data obnovit k času posledního backupu. To funguje

docela dobře pro situace, kdy chcete zajistit ochranu proti poškození dat nebo smazání a kde je přijatelná poměrně dlouhá doba RPO (obvykle 24 hodin nebo více).

Když však rizika zahrnují rozsáhlou ztrátu serveru s podstatným množstvím dat, nedokáže tradiční zálohování s využitím agentů pravděpo-dobně splnit náročnější požadavky RTO, protože obnovení serveru z holého stavu může vyžadovat značné množství času.

Nástroje zálohování založené na agentech však zatím neodepisujme. I přes svou ne úplně zajímavou pověst mohou moderní zálohovací agenti nabídnout pokročilé funkce, jako jsou na-příklad backup založený na bitových kopiích či deduplikace na straně klienta, což může zkrátit dobu obnovy a stejně tak zmenšit čas potřebný pro vytvoření souborů záloh.

Zálohy založené na bitových kopiích zachytí najednou obsah celého serveru – soubor po sou-boru a obnoví ho do stejného stavu. Vytvoření backupu a obnova jsou tak snadnější. Dedupli-kace na straně klienta vám také umožní snížit náklady na centralizované úložiště a distribuovat deduplikační zátěž, takže backup přes sítě WAN probíhá rychleji – musí se přenášet méně dat.

Tyto pokročilejší formy zálohování založe-ného na agentech jsou užitečné pro organizace, které potřebují zkrátit RTO/RPO, ale nepouží-vají virtualizaci, jež by backup usnadnila.

Virtualizované zálohování – Virtualizované infrastruktury mají k dispozici výrazně větší možnosti zálohování. Protože virtualizace zavádí abstraktní vrstvu mezi operační systém, základní server a hardwarové úložiště, je mnohem snad-

nější získat zálohy tvořené konzistentní bitovou kopií a obnovit tyto backupy na jiné hardwarové konfigurace v případě potřeby.

Ve skutečnosti se může virtualizační záloha založená na bitové kopii také využít k zajištění potřeb nepřetržitého provozu (navíc kromě ob-novy po havárii). Namísto ukládání záloh na vy-hrazená úložná média jako pásky či úložiště NAS se totiž backupy mohou ukládat živě do zá-lohovacího virtualizačního clusteru – do sku-piny virtualizovaných hostitelů umístěných v jiné lokalitě, kterou lze velmi rychle uvést do provozu.

I když je u tohoto přístupu poměrně obtížné dosáhnout RPO kratší než 30 minut, může to být mimořádně levný způsob, jak nabídnout agresivní hodnotu RTO, když není možné použít pokročilejší hardwarově založené přístupy, jako je například replikace SAN -to -SAN (viz níže).

Replikace založená na hostiteli – Podobně agresivní hodnoty RTO můžete dosáhnout i pro fyzické servery díky použití hostitelsky za-loženého softwaru, který replikuje data z fyzic-kých produkčních serverů na servery vyhrazené pro obnovu, které mohou být jak fyzické, tak i virtuální.

Toto řešení však vyžaduje nákladný poměr vy-cházející ze vztahu „jeden vůči jednomu“ mezi chráněným a zálohovacím strojovým parkem – vše budete muset mít, a tedy i platit, dvakrát. Tento druh softwaru také obvykle neumožňuje duální využití, což znamená, že stále potřebujete použít samostatný software pro obnovu po havá-rii k zajištění archivačních záloh.

Nicméně v situacích, kdy lze OS a aplikace virtualizovat, a přitom virtualizované nejsou, často lze využít hostitelský software k replikaci mnoha fyzických serverů na jednoho hostitele s podporou virtualizace, čímž se odstraní nut-nost duplikace fyzických prostředků.

Zálohování na aplikační úrovni – Některé typy aplikací mají vlastní nástroje pro zajištění nepřetržitého provozu a obnovy po haváriích. Můžete například nakonfigurovat databázový stroj, aby ukládal plné backupy a snapshoty transakčních protokolů každou noc do sekundár-ního úložného zařízení právě pro účely DR, a přitom průběžně replikoval transakční proto-koly na server v sekundárním datovém centru pro účely BC.

Přestože mohou tato řešení poskytnout levný způsob, jak zajistit velmi přísné RTO/RPO, jsou to zároveň spíše ojedinělá řešení, která se hodí jen pro aplikace, jež je plně podporují.

Pokud máte více než jednu kritickou databázi s vlastními procesy DR a BC, museli byste kaž-dou z nich spravovat odděleně, a to by zvyšovalo složitost řešení BC/DR a vytvářelo by to potenci-álně velký zdroj problémů.

Udržujte jednoduchost – Bez ohledu na to, jakou kombinaci softwaru si vyberete, se ale snažte o udržení maximální jednoduchosti. Přestože můžete dosáhnout skvělých výsledků opatrným vrstvením několika různých druhů zá-lohovacího softwaru a zdravým množstvím vlast-

CW4-II-VI.indd IVCW4-II-VI.indd IV 23.04.15 13:4823.04.15 13:48

CO M P U T E RWO R L D.C Z V

ZÁLOHOVÁNÍ A OBNOVA DAT

▶

HP RMC: Jednoduché zálohování vašeho virtuálního prostředíStále rostoucí objem dat klade velké nároky především na primární úložiště dat – z pohledu kapacity i celkové výkonnosti. Už je nestačí mít na primárním úložišti, je potřeba rozumně zálohovat.

RAFAEL NOAS

Vmultivendorovém pro-středí je klasické zálo-hování vhodné z hle-

diska funkcionality a posky-tuje vysokou flexibilitu, zvyšuje ale složitost ce-lého řešení, nároky na implementaci i správu a také náklady. Může tak postihnout celkovou výkonnost zálohovaných aplikací či samotnou IT infrastrukturu.

Alternativou s minimálním dopadem na aplikaci je používání kopírovacích funkcí dis-kového pole, jako je řešení HP 3PAR StorServ (3PAR) s funkcí virtual copy (VC). Vytváření vir-tual copies je rychlé, ale kvůli umístění na stej-ném úložišti s originálními daty může v případě nedostupnosti či havárie dojít k jejich ztrátě.

Ideální je kombinace obou metod v rámci uceleného řešení. Tím je nový software HP StoreOnce Recovery Manager Central

(RMC), který integruje funk-cionalitu HP 3PAR VC a HP StoreOnce Backup systému (StoreOnce).

První verze RMC 1.0 umožňuje chránit virtuální stroje a datastory v prostředí VMware vSphe re (VMware), a to právě pomocí 3PAR VC funkcionality. Tyto VC snapshoty je možné ponechat na daném 3PAR či je migrovat do StoreOnce systému, a tak je dlou-hodobě uchovat. RMC 1.0 chrání i jiná data ulo-žená na daném 3PAR.

RMC ve formě virtuální appliance komuni-kuje s VMwarem (především k zajištění konzis-tence snapshotů) i přímo se StoreOnce. Pomocí funkcionality HP StoreOnce Express Protect přesouvá data přímo ze 3PAR VC snapshotů do HP StoreOnce Catalyst Target přes Ethernet nebo Fibre Channel. Přenos dat je velmi efek-tivní; RMC může zvolit kopírování jen změně-

ných dat. Tím se výrazně sníží množství přene-sených dat po počáteční záloze. Funkcionalita HP StoreOnce Express Protect vytváří i tzv. synthetic -full zálohy – inkrementální a full zá-lohy se kombinují pomocí ukazatelů. Inkremen-tální back -up se tedy chová jako full back -up a minimalizuje čas obnovy.

RMC je navíc možné spravovat z webového rozhraní a v případě zálohování VMware virtuál-ních strojů i přímo z vSphere Web Client po-mocí dodávaného plug -inu. V budoucnu se také očekává rozšíření na další platformy.

Autor je technical consultant HP divize společnosti Avnet, VAD distributora enterprise produktů společnosti HP

Partnerský příspěvek

ních skriptů, může přinést rostoucí složitost vyšší pravděpodobnost selhání samotného zálo-hování, nebo hůře – data se mohou vystavit ještě většímu riziku.

■ Hardwarové stavební blokyNehledě na vámi použitý druh přístupu k back-upu bude hrát hardware zásadní roli. V rámci řešení obnovy po havárii je úkolem hardwaru ukládat zálohovaná data a poskytovat funkce uchovávání a archivace dat.

V aplikacích BC je role hardwaru mnohem různorodější – od virtualizačních hostitelů s vlastním úložištěm až po systémy NAS (Net-work Attached Storage) a synchronizované sítě SAN (Storage Area Networks) vzdálené stovky kilometrů. Veřejný cloud lze také využít a může hrát významnou roli jak pro DR, tak i pro BC.

Zálohování na pásku – Když většina lidí pře-mýšlí o DR zálohování, první věcí, co přijde na mysl, bývá obvykle backup na pásku.

Přestože se páskové záložní systémy často hodně pomlouvají, zůstávají relevantní díky svému sekvenčnímu výkonu čtení a zápisu, který může být dvakrát až třikrát vyšší než u disku, a stejně tak nabízejí dlouhou skladovatelnost a relativní odolnost.

Přestože se v posledních letech stalo záloho-vání na disky mnohem populárnější, spoléhají přístupy obnovy po havárii, které vyžadují zasí-

lání zálohovacích médií do archivu mimo loka-litu, stále obvykle na pásky.

Zálohování na disk – Zálohování na pásku má řadu významných omezení, primárně pro-tože jde o sekvenční médium. Čtení náhodných bloků z různých částí pásky může být velmi ča-sově náročné.

Backup, který významně využívá aktualizace nebo odkazy na data souboru předchozí zálohy, se mnohem více hodí pro on -line rotační disky. Avšak i tam, kde se disk využívá jako první zálo-hovací vrstva, se stále často pracuje i s archivací dat na pásku pro ukládání mimo lokalitu. Vzniká tak model označovaný jako disk -disk -páska.

Médium v podobě zálohovacího disku může mít řadu podob. V nejjednodušší aplikaci to může být backup server s velkou kapacitou disků. V situacích, kdy běží zálohovací software v rámci virtualizačního prostředí nebo pracuje v systému, který ukládá zálohy jinam, se často používá řešení NAS.

NAS a VTL – Ve velkých instalacích vyžadují-cích velkou propustnost a dlouhou dobu uchová-vání dat lze mnohem běžněji vidět vyhrazená, účelově vytvořená zálohovací zařízení NAS.

Tyto systémy se objevují ve dvou základních provedeních: jedno pracuje jako libovolně velký systém NAS a je dostupné prostřednictvím růz-ných protokolů pro sdílení souborů. Druhé má podobu virtuálních páskových knihoven (VTL),

které emulují páskové knihovny připojené roz-hraním iSCSI nebo Fibre Channel.

VTL mohou být užitečné v situacích, kde starší zálohovací software vyžaduje připojení skutečné páskové jednotky, ale použití pásek už není žádoucí. Použitím VTL lze zajistit možnost backupu na disk s deduplikací, a přitom stále vy-užívat funkce staršího zálohovacího softwaru.

Pro většinu organizací, které potřebují uklá-dat velké objemy dat na významně dlouhou dobu, však bude správnou volbou pravděpo-dobně zálohovací zařízení NAS. Hlavním důvo-dem je to, že téměř každý backupovací systém podnikové úrovně používá nějakou formu dedu-plikace pro eliminaci částí dat, které jsou přes-nou kopií jiných – například e -mailová zpráva zaslaná všem podnikovým zaměstnancům.

Deduplikace tak může výrazně snížit velikost potřebného místa na disku u každého zálohova-cího úkonu, což organizacím například umožní zvýšit počet historických záloh dat, které mohou udržovat.

Existuje široká řada deduplikačních pro-duktů, z nichž některé jsou účinnější než jiné, ale obecně využívají jeden ze dvou následujících přístupů: deduplikace po uložení (at rest) a de-duplikace při ukládání (in -line).

V prvním případě se data zazálohují do zaří-zení tak, jak jsou, a teprve po dokončení bac-kupu se vykoná příslušná deduplikace. Ve dru-

CW4-II-VI.indd VCW4-II-VI.indd V 23.04.15 13:4823.04.15 13:48

ZÁLOHOVÁNÍ A OBNOVA DAT

VI CO M P U T E RWO R L D 4 | 2015

hém případě se data deduplikují hned během za-pisování do zařízení.

Obvykle platí, že systém využívající dedupli-kaci po uložení zálohuje a obnovuje data rychlej-ším způsobem, protože nemusí data dedupliko-vat nebo rekonstruovat při jejich zpracování.

Protože však musí ukládat minimálně jednu zálohu v nededuplikovaném stavu, vyžaduje také větší úložný prostor ve srovnání se zařízeními využívajícími in -line deduplikaci.

Vhodnost volby druhu deduplikačního zaří-zení pro danou aplikaci závisí na způsobu po-užití. Pokud například chcete ukládat backupy virtualizovaného prostředí na NAS, možná bu-dete chtít použít deduplikaci po uložení (at rest) pro její rychlost čtení a zápisu. Některý software pro zálohování virtualizace dokáže obnovit vir-tuální stroje z dat umístěných na NAS a dosaho-vat u toho vynikajících hodnot RTO.

Při tomto typu okamžité obnovy může hosti-tel virtualizace připojit bitovou kopii zálohy přímo ze zařízení NAS, spustit virtuální stroj a poté udělat živou migraci na původní primární úložiště – v podstatě se tím eliminuje čas ob-vykle potřebný k obnově dat na primární úlo-žiště při tradičním zálohování.

V tomto smyslu lze to, co se běžně považuje za zdroj DR, využít pro zajištění určité úrovně funkcí BC – zejména pokud se zařízení NAS umístí ve vzdáleném datovém centru společně s vyhrazenou virtualizační kapacitou.

Replikace SAN – Většina přístupů BC spo-léhá na vyhrazený připravený uzel – tedy datové centrum ve vzdálené lokalitě, které obsahuje veškerou infrastrukturu potřebnou k zajištění provozu firmy v případě, že primární datové centrum přestane fungovat.

Takový uzel je téměř vždy spojený s nějakým typem replikace úložiště. Obvykle jde o sekun-dární SAN replikující data produkční sítě SAN.

Protože to ale v podstatě zdvojnásobí inves-tice vaší organizace do hardwaru úložiště a vyža-duje to i velkou šířku pásma s nízkou latencí pro propojení obou míst, může být tento druh repli-kace poměrně drahý. Je však široce uznávaný jako nejkomplexnější dostupný přístup pro za-chování nepřetržitého provozu.

Existují dva druhy replikace SAN -to -SAN: synchronní a asynchronní. V prvním případě se udržuje precizní synchronizace dat mezi pro-dukční a záložní strukturou SAN. Naopak při asynchronní variantě se vytvářejí snapshoty dat ve stanovených intervalech a v případě selhání primárního úložiště se můžete v rámci minima-lizace ztráty dat vrátit jen do stavu posledního snapshotu.

Na první pohled to vypadá, že je synchronní replikace lepší. Data v záložní struktuře SAN jsou vždy shodná se strukturou produkční SAN a doba obnovení je přesně nula. Jaký je tedy problém?

Pokud nastane poškození produkčních dat, dojde i k replikaci porušených dat. (To je důvod, proč je obnova po havárii nezbytnou součástí i nejrobustnějšího systému pro zachování nepře-

tržitého provozu – vždy chcete mít spolehlivou záložní sadu). U asynchronní replikace se mů-žete vrátit zpět na poslední snapshot dat, který předcházel události poškození.

Máte -li přísné požadavky na RTO, pravděpo-dobně budete potřebovat synchronní replikaci, abyste je splnili. Budete však také muset zajistit, aby vyhovovaly i prostředky DR, a byly tak v pří-padě potřeby k dispozici.

Některé platformy úložiště mohou umožnit nasazení hybridního přístupu – pořizování snapshotů produkč-ních dat SAN a jejich ukládání na straně SAN pro obnovu při sou-časném poskytování nulového času RPO a zároveň schopnosti vrátit se k předchozím sadám dat bez nutnosti obnovení ze záloh.

Cloudové DR a BC – V situa-cích, kdy je k dispozici velká šířka pásma pro přístup do internetu, může veřejný cloud také poskyt-nout použitelnou možnost pro cíle DR a BC.

V aplikacích DR může clou-dové zálohování nabídnout ná-hradu za pásková média nebo re-plikaci NAS, když je cílem poskyt-nout ochranu zálohy umístěním v jiné lokalitě. Správa zabezpečení zálohovaných dat umístěných do cloudu a zajištění, aby tato data byla rychle a snadno dostupná zpět v místě potřeby, ale může být poněkud problematické.

Veřejný cloud může také plnit roli zcela vyba-veného datového centra pro okamžitou obnovu. Použitím zálohovacího softwaru podle konkrét-ních aplikací a hostitelsky založených replikač-ních nástrojů lze chránit celé serverové infra-struktury pomocí úložišť a výpočetních pro-středků umístěných v cloudu.

To, zda se rozhodnete pro cloudové DR nebo BC, závisí na řadě faktorů, například typu IT zdrojů, které vaše organizace má, jestli ve firmě disponujete dovednostmi potřebnými k využí-vání zásadně odlišného charakteru cloudových služeb, jak velkou šířku pásma vaše data potře-bují a jaká regulační nařízení pro bezpečnost dat musíte dodržovat.

Testování a kompatibilitaBez ohledu na to, jaké řešení si vyberete pro ob-novu po havárii a pro zachování nepřetržitého provozu, je zcela nezbytné vytvořit a dodržovat konzistentní režim kompatibility a testování. Bez častého testování si totiž nikdy nemůžete být jistí, že lze zálohovaná data obnovit a že sekundární datové centrum v případě nouze sku-tečně naběhne.

V této oblasti mnoho organizací selhává. IT oddělení, ve kterých část personálu chybí a část je přepracovaná, mohou mít pocit, že na časté přezkušování DR a BC není dostatek času a prostředků.

Může to však být také způsobené špatně navr-ženými procesy nebo nedostatečnou automati-zací. Vynaložení dalšího úsilí na zefektivnění těchto procesů tak pomůže nejen při testování těchto řešení, ale také při jejich využití, když udeří skutečná katastrofa.

V ideálním případě organizace nasadí svá ře-šení DR a BC jako součást svého každodenního provozu, což jim umožní využít své investice a zároveň je pravidelně testovat.

Například můžete použít systém DR k tomu, aby důležitá databáze zaplnila nějakou plat-formu jen pro účely čtení a pro pravidelné gene-rování reportů. Pokud nastane problém s repor-tem, mohlo by to být příznakem, že váš systém DR nepracuje, jak by měl.

Nebo můžete běžně přesouvat pracovní zá-těže mezi produkčním datovým centrem a zálož-ním centrem. Rozložení zátěže mezi oběma ob-jekty v případě potřeby vyššího výkonu také de-monstruje, že metodika převzetí služeb při havá-rii funguje správně.

Zálohy mohou selhat bez varování. Pokud je netestujete, zjistíte to, až když už je příliš pozdě, a to je situace, kterou si nikdo nepřeje. Budete mít také vynikající příležitost vyhodnotit, zda se daří plnit sepsané požadavky RTO/RPO, a pří-padně usilovat o nápravu.

BC/DR je pro podniky nezbytnéProtože přežití firem stále více závisí na datech, nelze důležitost obnovy po havárii a zachování nepřetržitého provozu nijak zveličit. Pouze prostřed nictvím promyšleného a na vnitrofi-remní spolupráci založeného plánování, které zahrnuje všechny úrovně organizace (technické i netechnické), lze vytvořit komplexní strategii DR a BC, jež vhodně nastaví očekávání a do-statečně ochrání životně nezbytné firemní funkce. ■

CW4-II-VI.indd VICW4-II-VI.indd VI 23.04.15 13:4823.04.15 13:48

Nová sada Veeam Availability Suite v8

vee.am/v8cz

Bez názvu-5 VIIBez názvu-5 VII 23.04.15 14:5123.04.15 14:51

ZÁLOHOVÁNÍ A OBNOVA DAT

VIII CO M P U T E RWO R L D 4 | 2015

Rizika pohrom způsobených člověkem stoupajíIT služby mohou významně zhavarovat na základě jediné lidské chyby a zatím to nevypadá, že by se podařilo zajistit, aby lidé chyby nedělali.

PATRICK THIBODEAU

Existuje pramálo důkazů, že by zlepšování procesů, bezpečnostní školení či pokroky technologií nějak omezovaly lidské chyby

v IT provozu. Když nic jiného, tak roste riziko technologických katastrof navzdory veškerým snahám, které se v tomto odvětví udělají.

Narušení bezpečnosti a výpadky IT se dějí stále častěji a navíc se jejich dopad stále zhor-šuje: Roste totiž počet lidí, u nichž je riziko, že budou každým novým incidentem ovlivnění, protože stoupá vzájemná provázanost uživatelů.

Příčiny problémuJaký je společný bod selhání u téměř každého inci dentu? Lidská chyba. Lidé jsou nějakým způ-sobem zodpovědní za většinu IT katastrof. To vedlo (samozřejmě kromě dalších technologií) ke zvýšenému zájmu o nástroje umělé inteli-gence (AI) v naději, že se tím posílí zabezpečení a spolehlivost.

Nové technologie a metody však přinášejí další, zatím neexistující rizika. Stephen Haw-king nedávno jako fyzik a kosmolog pozname-nal: „Vývoj plné umělé inteligence by mohl zname-nat konec lidské rasy.“ A zničení lidstva, řízené umělou inteligencí, by samozřejmě bylo největší selhání IT vůbec.

Vzhledem k pokračujícím a zdánlivě nezasta-vitelným řetězům selhání zabezpečení informací to však může být riziko, které se vyplatí.

Důkazy jsou totiž neúprosné: Jen za posled-ních několik let došlo například ke gigantickému narušení systémů řetězce Home Depot, kdy unikly informace o 56 milionech platebních ka-ret, a z finanční instituce JPMorgan Chase bylo ukradeno 76 milionů jmen a adres. Firma Hold Security vloni odhadla, že gang ruských zločinců se jménem CyberVors ukradl více než 1,2 mili-ardy unikátních kombinací e -mailových adres a hesel ze 420 tisíc webů a serverů FTP.

A ještě jednou – ani nejsilnější bezpečnostní ochrany IT při ochraně dat nic nezmohou, když někdo udělá chybu: Ve své analýze „Security Services 2014 Cyber Security Intelligence Index“ analytici IBM zjistili, že lidská chyba je jednou z příčin ohrožení v 95 % zkoumaných případů.

Ohrožení doby provozuVýpadky IT sice nezpůsobují tak velký rozruch jako úniky dat, ale mohou být podobně ničivé. Datová centra mohou tvrdit, že nabízejí 99,999% dostupnost (tedy s prostojem za rok

omezeným na pouhých 5 minut a 26 sekund), hlavní poskytovatelé cloudových služeb pak pro-klamují dostupnost nejméně 99,99 % (to zna-mená, že výpadek nesmí přesáhnout 52 minut a 56 sekund za rok), ale výpadky se neustále objevují.

Celková rizika z těchto nefungujících služeb rostou proto, že se nyní mezi hrstku poskytova-telů cloudu koncentruje příliš mnoho kritických IT služeb. Malé lidské chyby mohou snadno způ-sobit velké problémy, které ovlivní velký počet uživatelů.

Například Amazon uváděl, že jeho nedávný výpadek způsobila změna konfigurace, která byla „vykonaná nesprávně“. Microsoft zase podotkl, že nedávný problém s jeho platformou Azure za-příčinila aktualizace systému. A není výjimkou, že dochází i k výpadkům služeb Google Gmail, Facebook nebo Yahoo Mail.

Uptime Institute uvádí, že analýza dat o ab-normálních incidentech za dobu 20 let ukazuje, že lidská chyba je na vině ve více než 70 % všech výpadků datových center. Tato selhání jsou nyní navíc dražší než v minulosti.

Když společnost Kroll Ontrack, poskytovatel služeb pro obnovu dat, udělala průzkum mezi svými zákazníky ohledně ztráty dat, uvedla tře-tina respondentů, že hlavní příčinou byly poru-

chy desktopů a serverů, zatímco pouze čtrnáct procent uvedlo, že by ztráty mohly způsobit lid-ské chyby. To druhé číslo ale není tak malé, jak by se mohlo zdát.

Jeff Pederson, manažer obchodu pro obnovu dat ve společnosti Kroll, poznamenává, že 25 až 30 % obratu jeho firmy tvoří obnova dat ztrace-ných v důsledku lidské chyby.

Trocha prevenceStandardní odpovědí, když se něco pokazí, je připomenout uživatelům, že obnova po havárii je sdílenou odpovědností. Existují však konkrét- ní kroky, které uživatelé, dodavatelé a poskyto-vatelé služeb IT mohou udělat, aby předcházeli výpadkům a narušením.

Jedním z kroků je používání osvědčených postupů. Například CenturyLink, globální po-skytovatel datových center, nedávno obdržel od konsorcia Uptime Institute certifikát Manage-ment and Operations Stamp of Approval pro svých 57 datových center. Tento certifikační pro-gram uznává zařízení s přísnými procesy řízení provozu.

Drew Leonard, viceprezident CenturyLink, uvedl, že snaha udržet bezchybný provoz je zá-sadní, protože výpadek může poškodit pověst da-tového centra na celá léta.

Dodavatelé se také obracejí k novým bezpeč-nostním nástrojům, které se spoléhají na pre-diktivní analýzy a strojové učení, aby umožnily uživatelům „pokusit se zasáhnout před vznikem evidentních škod“, uvádí John McClurg, ředitel zabezpečení v Dellu.

Myšlenkou je využívat strojovou analýzu inci-dentů, a interpretaci přitom nechat na lidi, říká Kevin Conklin, viceprezident pro marketing a strategie ve společnosti Prelert, která se spe-cializuje na systémy strojového učení. „Lidé jsou ale velmi nepředvídatelní,“ dodává Conklin. ■

CW4-VIII.indd VIIICW4-VIII.indd VIII 23.04.15 13:4923.04.15 13:49