zvláštní neprodejná příloha | duben 2015

Z VL Á ŠTNÍ NEPRODE JNÁ PŘÍLOHA | DUBEN 201 5
Zálohování
a obnova po havárii
2015
S I LV E R PA R T N E R S
Bez názvu-5 obI
Zalohovania obnova dat_2015_DEF.indd 9
23.04.15 15:21
4/23/15 11:43 AM
ZÁLOHOVÁNÍ A OBNOVA DAT
Chytré strategie pro ochranu dat
Obnova 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.
MAT T PR I GGE
D
ata jsou jako kyslík. Bez nich začne většina
moderních organizací rychle lapat po dechu 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é smazá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 metodiky 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 obnovu po haváriích (DR, Disaster Recovery) a postupy 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í
II
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 provozu 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ě selhání hardwaru, až po téměř okamžité převzetí
funkce při selhání pomocí sekundárního datové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ší organizaci obnovu, když dojde ke katastrofě postihují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, Recovery 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 obnovy po havárii bude také obsahovat vše potř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í hardware, pokud jsou primární systémy nedostupné,
zda bude zapotřebí instalační médium pro aplikace 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í fungování firmy. Obvykle se přitom spoléhá na hardware s vysokou dostupností (HA, High Availability) – 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řeberou 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, softwarové 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 obnovy DR. Pečlivě koncipovaný návrh BC vám
tedy umožní obnovu z úplné havárie s jen omezenou 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ásad
Existují čtyři hlavní etapy, jak vytvořit konzistentní zásady BC a DR ve firmě. Prvním úkolem
CO M P U T E RWO R L D 4 | 2015
CW4-II-VI.indd II
23.04.15 13:48
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žadavky zásad, pokud jde o parametry RTO a RPO
pro jednotlivé kategorie rizik, které jste dříve definovali. 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 zodpovědné firemní osoby do procesu rozhodování
nehledě na to, jak netechnicky založení dotyční
jednotlivci jsou. Ve skutečnosti čím méně technicky orientované tyto osoby jsou, tím důležitě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.
Rozsah
Př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í infrastrukturu IT.
Je to především důsledek popularity virtualizace serverů, konvergence sítí a centralizace
prostředků primárních úložišť. V takových prostředích mohou zásady BC/DR, které se snaží
chránit důležité aplikace zajišťované malým souborem 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.
Rizika
Po stanovení rozsahu pravidel je dalším krokem
určit, jaká rizika se zásady pokusí řešit. Architektury IT jsou zranitelné velkým množstvím situací, počínaje selháním disku až po přírodní katastrofy 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 nebudou 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 vynaklá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í.
Jste připraveni i na selhání cloudu?
JOHN GRADY
Navzdory 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 doporuč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.
Požadavky
Poté, 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 použí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 balancová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 diskutovalo 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ídnou 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.
▶
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 dostat 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 streamová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 vztahovat i na následné ztráty zisku.
CO M P U T E RWO R L D.C Z
CW4-II-VI.indd III
III
23.04.15 13:48
ZÁLOHOVÁNÍ A OBNOVA DAT
Stavební bloky
Poté, 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 komplexní řešení.
■ Softwarové stavební bloky
Srdcem 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 replikaci na aplikační úrovni nebo dokonce plně vybavený, hostitelsky založený replikační software
pro dosažení cílů nepřetržitého provozu.
Zálohování založené na agentech – Tradičně nejčastější softwarová komponenta, kterou
uvidíte, je zálohovací nástroj založený na agentovi. 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
IV
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ěpodobně 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 napří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 souboru a obnoví ho do stejného stavu. Vytvoření
backupu a obnova jsou tak snadnější. Deduplikace 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žené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ě obnovy po havárii). Namísto ukládání záloh na vyhrazená ú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 skupiny 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 založeného softwaru, který replikuje data z fyzický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 vychá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í nutnost 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árního úložného zařízení právě pro účely DR,
a přitom průběžně replikoval transakční protokoly 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-
CO M P U T E RWO R L D 4 | 2015
CW4-II-VI.indd IV
23.04.15 13:48
ZÁLOHOVÁNÍ A OBNOVA DAT
ních skriptů, může přinést rostoucí složitost
vyšší pravděpodobnost selhání samotného zálohování, nebo hůře – data se mohou vystavit ještě
většímu riziku.
■ Hardwarové stavební bloky
Nehledě na vámi použitý druh přístupu k backupu 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 (Network 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řemýš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álohová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 lokalitu, 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ě protože jde o sekvenční médium. Čtení náhodných
bloků z různých částí pásky může být velmi časově 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álohovací 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ůzných protokolů pro sdílení souborů. Druhé má
podobu virtuálních páskových knihoven (VTL),
které emulují páskové knihovny připojené rozhraní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 využí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ěpodobně zálohovací zařízení NAS. Hlavním důvodem je to, že téměř každý backupovací systém
podnikové úrovně používá nějakou formu deduplikace pro eliminaci částí dat, které jsou přesnou 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álohovací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 produktů, 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 deduplikace 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í backupu se vykoná příslušná deduplikace. Ve dru- ▶
Partnerský příspěvek
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.
R AFAE L NOAS
V
multivendorovém prostředí je klasické zálohování vhodné z hlediska funkcionality a poskytuje vysokou flexibilitu, zvyšuje ale složitost celé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í diskového pole, jako je řešení HP 3PAR StorServ
(3PAR) s funkcí virtual copy (VC). Vytváření virtual copies je rychlé, ale kvůli umístění na stejné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 funkcionalitu 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 vSphere (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 dlouhodobě uchovat. RMC 1.0 chrání i jiná data uložená na daném 3PAR.
RMC ve formě virtuální appliance komunikuje s VMwarem (především k zajištění konzistence 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 efektivní; RMC může zvolit kopírování jen změně-
ných dat. Tím se výrazně sníží množství přenesený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ů. Inkrementá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álních strojů i přímo z vSphere Web Client pomocí 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
CO M P U T E RWO R L D.C Z
CW4-II-VI.indd V
V
23.04.15 13:48
ZÁLOHOVÁNÍ A OBNOVA DAT
hém případě se data deduplikují hned během zapisování do zařízení.
Obvykle platí, že systém využívající deduplikaci po uložení zálohuje a obnovuje data rychlejším způsobem, protože nemusí data deduplikovat 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 použití. Pokud například chcete ukládat backupy
virtualizovaného prostředí na NAS, možná budete 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 virtuální stroje z dat umístěných na NAS a dosahovat u toho vynikajících hodnot RTO.
Při tomto typu okamžité obnovy může hostitel 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 obvykle 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 spolé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 sekundární SAN replikující data produkční sítě SAN.
Protože to ale v podstatě zdvojnásobí investice vaší organizace do hardwaru úložiště a vyžaduje to i velkou šířku pásma s nízkou latencí pro
propojení obou míst, může být tento druh replikace poměrně drahý. Je však široce uznávaný
jako nejkomplexnější dostupný přístup pro zachová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 produkč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 minimalizace 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-
VI
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ěpodobně 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 situacích, kdy je k dispozici velká šířka
pásma pro přístup do internetu,
může veřejný cloud také poskytnout použitelnou možnost pro
cíle DR a BC.
V aplikacích DR může cloudové zálohování nabídnout náhradu za pásková média nebo replikaci NAS, když je cílem poskytnout 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 vybaveného datového centra pro okamžitou obnovu.
Použitím zálohovacího softwaru podle konkrétních aplikací a hostitelsky založených replikačních nástrojů lze chránit celé serverové infrastruktury pomocí úložišť a výpočetních prostř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řebují a jaká regulační nařízení pro bezpečnost dat
musíte dodržovat.
Testování a kompatibilita
Bez ohledu na to, jaké řešení si vyberete pro obnovu 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 skuteč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 automatizací. 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 platformu jen pro účely čtení a pro pravidelné generování reportů. Pokud nastane problém s reportem, 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 objekty v případě potřeby vyššího výkonu také demonstruje, ž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řednictvím promyšleného a na vnitrofiremní 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 dostatečně ochrání životně nezbytné firemní
funkce.
■
CO M P U T E RWO R L D 4 | 2015
CW4-II-VI.indd VI
23.04.15 13:48
Nová sada Veeam Availability Suite v8
vee.am/v8cz
Bez názvu-5 VII
23.04.15 14:51
ZÁLOHOVÁNÍ A OBNOVA DAT
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.
PAT R I C K T H I B O D E AU
E
xistuje 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ému
Jaký je společný bod selhání u téměř každého
incidentu? 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é inteligence (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 Hawking nedávno jako fyzik a kosmolog poznamenal: „Vývoj plné umělé inteligence by mohl znamenat 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ě nezastavitelný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 poslední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 karet, 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 miliardy 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ů.
omezeným na pouhých 5 minut a 26 sekund),
hlavní poskytovatelé cloudových služeb pak proklamují dostupnost nejméně 99,99 % (to znamená, ž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 poskytovatelů 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 zapříč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 abnormá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řetina 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 lidské 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 ztracených v důsledku lidské chyby.
Trocha prevence
Standardní 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étní kroky, které uživatelé, dodavatelé a poskytovatelé 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í poskytovatel datových center, nedávno obdržel od
konsorcia Uptime Institute certifikát Management and Operations Stamp of Approval pro
svých 57 datových center. Tento certifikační program 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 datového centra na celá léta.
Dodavatelé se také obracejí k novým bezpečnostním nástrojům, které se spoléhají na prediktivní 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 incidentů, a interpretaci přitom nechat na lidi, říká
Kevin Conklin, viceprezident pro marketing
a strategie ve společnosti Prelert, která se specializuje na systémy strojového učení. „Lidé jsou
■
ale velmi nepředvídatelní,“ dodává Conklin.
Ohrožení doby provozu
Vý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
VIII
CO M P U T E RWO R L D 4 | 2015
CW4-VIII.indd VIII
23.04.15 13:49