Obnova po havárii (v ruských zdrojích se také používá ne zcela správný termín zotavení po havárii ) zahrnuje soubor zásad, nástrojů a postupů, které umožňují obnovit nebo pokračovat v provozu životně důležité technologické infrastruktury a systémů po přírodní katastrofě nebo způsobené lidskou činností. katastrofa [1] . Obnova po havárii se zaměřuje na informační technologie (IT) nebo technologické systémy, které podporují kritické obchodní funkce, na rozdíl od kontinuity podnikání, která zahrnuje udržování všech podstatných aspektů obchodních operací navzdory velkým přerušením; proto jej lze považovat za podmnožinu úkolů kontinuity provozu [2] [3] . Disaster recovery předpokládá, že hlavní část původně fungujícího informačního systému nelze po určitou dobu obnovit a jedná se o proces obnovy dat a služeb na sekundární dochovaná místa, na rozdíl od procesu obnovy informačních systémů na původní místo.
Plánování kontinuity služeb IT (ITSC) [4] [5] je podmnožinou plánování kontinuity podnikání (BCP) [6] , které se zaměřuje na cíl bodu obnovy (RPO) a cíl doby obnovy (R.T.O.). Tento proces zahrnuje dva typy plánování; Plánování obnovy IT po havárii a širší plánování odolnosti IT. Kromě toho obsahuje také prvky pro správu IT infrastruktury a služeb souvisejících s komunikací, jako je telefonie (hlas) a data.
Plánování zahrnuje nastavení pohotovostních míst, ať už jsou horké, teplé nebo studené, a také podporu pohotovostních míst vybavením potřebným k zajištění kontinuity provozu.
V roce 2008 zveřejnil British Standards Institution specifický standard související se standardem kontinuity podnikání BS 25999 a podporující jej, nazvaný BS25777, konkrétně pro sladění kontinuity IT systému s kontinuitou provozu . Tato norma byla stažena po zveřejnění ISO/IEC 27031 Bezpečnostní postupy v březnu 2011. Pokyny pro zajištění připravenosti informačních a komunikačních technologií pro kontinuitu podnikání“ [7] .
ITIL také definuje některé z těchto pojmů [8] .
Cíle doby obnovy (RTO) Tento termín se také překládá jako „Cíl doby obnovy“ [9] [10] je cílová doba trvání a úroveň služby, v rámci které musí být obchodní proces obnoven po katastrofě (nebo selhání), aby se předešlo nepřijatelným následkům s tím spojeným. s přerušením provozu [11] .
V souladu s metodikou Business Continuity Planning je RTO nastavena během analýzy Business Impact Analysis (BIA) vlastníkem (vlastníky) procesu a zahrnuje definici časového rámce pro alternativní nebo ruční řešení obnovy.
V literatuře na toto téma se RTO označuje jako doplňkový k cíli bodu obnovy (RPO). Místo toho popisují limity přijatelného nebo „akceptovatelného“ výkonu ITSC. RTO a RPO měří výkon ITSC z hlediska časové ztráty v důsledku normálního fungování obchodních procesů a dat ztracených nebo nezálohovaných během tohoto období (RPO), respektive [11] [12] .
Přehled Forbes uvádí [9] , že Recovery Time Actual (RTA) je ve skutečnosti kritickou metrikou pro kontinuitu podnikání a obnovu po havárii.
Tým pro zajištění kontinuity činnosti provádí zkoušky s načasováním skutečných provedených akcí, během nichž se stanoví a v případě potřeby upraví RTA [9] .
Cíl bodu obnovy ( Recovery Point Objective , RPO ) je maximální cílové období, během kterého dojde ke ztrátě transakčních dat ze služby IT v důsledku závažného incidentu [11] .
Pokud se například RPO měří v minutách (nebo dokonce několika hodinách), pak je v praxi nutné neustále udržovat vzdálené zrcadlené zálohy, protože denní zálohování na pásku mimo pracoviště nestačí [13] .
Vztah k cíli doby zotaveníObnova, která není okamžitá, umožní obnovení transakčních dat v průběhu času, a to bez významného rizika nebo ztráty.
RPO měří maximální dobu, po kterou mohou být nejnovější data nenávratně ztracena v případě závažného incidentu, a není přímým měřítkem výše takové ztráty. Pokud například BC plánuje obnovit data do poslední dostupné zálohy, pak RPO je maximální interval mezi takovými zálohami, které byly bezpečně odstraněny z úložiště.
Často se mylně chápe, že RPO je určeno stávajícím režimem zálohování, zatímco ve skutečnosti analýza dopadu na podnikání určuje RPO pro každou službu. Když jsou vyžadována vzdálená data, období, během kterého může dojít ke ztrátě dat, často začíná od okamžiku, kdy jsou zálohy připraveny, a nikoli od okamžiku, kdy jsou přeneseny mimo místo [12] .
Bod synchronizace dat (je to také bod zálohy ) [14] je bod v čase, kdy jsou zálohována fyzická data. V nejjednodušší implementaci je to bod, ve kterém se zastaví zpracování fronty aktualizace dat v systému, zatímco probíhá kopírování z disku na disk. V moderních systémech zpracování dat obvykle pokračuje paralelně se zálohováním, které se provádí pomocí snímků . Záloha [15] bude odrážet dřívější verzi dat, nikoli stav, ke kterému došlo, když byla data zkopírována na záložní médium nebo přenesena do umístění zálohy.
RTO a RPO musí být v rovnováze s obchodním rizikem i se všemi ostatními hlavními kritérii návrhu systému.
RPO je vázáno na čas, kdy se zálohy nahrávají mimo web. Synchronní kopírování dat do externího zrcadla překonává většinu nepředvídaných problémů s dostupností hlavního webu. Fyzický přesun pásek (nebo jiných přenosných médií) mimo pracoviště poskytuje některé potřeby zálohování za relativně nízkou cenu. Obnovu z takových kopií lze provést na předem vybraném místě [16] .
Pro velké objemy cenných transakčních dat lze hardware rozdělit na dvě nebo více lokalit oddělením podle geografické oblasti, což zlepšuje odolnost.
Pro podrobnější plánování obnovy slouží indikátory jako DOO – Degraded Operations Objective – přijatelné zpomalení provádění operací systémem, ke kterému dochází v procesu přenosu zpracování dat na záložní místo a NRO – Network Recovery Objective – minimální šířka pásma sítě. který musí být obnoven, lze také použít k zajištění minimálního přijatelného výkonu obnoveného systému [17] .
Plánování obnovy po havárii a informačních technologií (IT) se začalo rozvíjet v polovině až koncem 70. let, kdy si manažeři počítačových center začali uvědomovat závislost svých organizací na počítačových systémech.
V té době byla většina systémů dávkově orientovaných sálových počítačů . Jiný vzdálený sálový počítač může zavést systém ze záložních pásek, zatímco čeká na obnovení hlavního serveru; prostoje byly relativně méně kritické.
Odvětví obnovy po havárii se objevilo jako poskytovatel záložních počítačových center. Jedno z prvních takových center se nacházelo na Srí Lance (Sungard Availability Services, 1978) [18] [19] vyvinuté pro poskytování záložních počítačových center. Jedno z prvních takových center se nacházelo na Srí Lance (Sungard Availability Services, 1978). [20] [21] .
V 80. a 90. letech 20. století, kdy rostlo vnitropodnikové sdílení času, online zadávání dat a zpracování v reálném čase, byla potřeba větší dostupnost IT systémů.
Kontinuita služeb IT je pro mnoho organizací důležitá při zavádění řízení kontinuity podnikání (BCM) a řízení bezpečnosti informací (ICM) a jako součást zavádění a řízení zabezpečení informací a řízení kontinuity podnikání, jak je specifikováno v ISO/IEC 27001 a ISO 22301 , v tomto pořadí.
Vzestup cloud computingu od roku 2010 pokračuje v tomto trendu: nyní je ještě méně důležité, kde jsou počítačové služby fyzicky hostovány, pokud je samotná síť dostatečně spolehlivá (samostatný problém, který nás příliš neznepokojuje, protože moderní sítě jsou velmi odolné. ). podle návrhu). Recovery as a Service (RaaS) je jednou z bezpečnostních funkcí nebo výhod cloud computingu propagovaných Cloud Security Alliance [22] .
Katastrofy lze rozdělit do tří širokých kategorií hrozeb a nebezpečí. První kategorie zahrnuje přírodní katastrofy, jako jsou povodně, hurikány, tornáda, zemětřesení a epidemie.
Druhou kategorií jsou technologická nebezpečí, která zahrnují havárie nebo poruchy systémů a konstrukcí, jako jsou výbuchy potrubí, dopravní nehody, poruchy inženýrských sítí, poruchy přehrad a náhodné úniky nebezpečných látek.
Třetí kategorií jsou hrozby způsobené člověkem, které zahrnují úmyslné činy, jako jsou aktivní škodlivé útoky, chemické nebo biologické útoky, kybernetické útoky proti datům nebo infrastruktuře a sabotáže. Opatření připravenosti pro všechny kategorie a typy přírodních katastrof spadají do pěti oblastí poslání: prevence, ochrana, zmírňování, reakce a obnova [23] .
Nedávný výzkum podporuje myšlenku, že přijetí holističtějšího přístupu k plánování před katastrofou je z dlouhodobého hlediska nákladově efektivnější. Každý dolar vynaložený na zmírnění nebezpečí (jako je plán obnovy po havárii) ušetří komunitě 4 dolary na reakci a náklady na obnovu [24] .
Statistiky obnovy po havárii z roku 2015 ukazují, že jedna hodina výpadku může stát
Jak se IT systémy stávají stále důležitějšími pro hladký chod společnosti a možná i ekonomiky jako celku, je stále důležitější udržovat tyto systémy v provozu a rychle je obnovovat. Například 43 % společností, které zažijí velkou ztrátu obchodních dat, se nikdy znovu neotevře a 29 % se zavírá do dvou let. V důsledku toho je třeba brát přípravu na pokračování nebo obnovu systémů velmi vážně. To vyžaduje značné časové a finanční investice, aby byly v případě destruktivní události zajištěny minimální ztráty [26] .
Kontrolní opatření jsou akce nebo mechanismy, které mohou snížit nebo odstranit různé hrozby pro organizace. Do plánu obnovy po havárii (DRP) lze zahrnout různé typy opatření.
Plánování obnovy po havárii je součástí většího procesu známého jako plánování kontinuity podnikání a zahrnuje plánování obnovení aplikací, dat, vybavení, elektronické komunikace (jako jsou sítě) a další infrastruktury IT. Plán kontinuity podnikání (BCP) zahrnuje plánování pro aspekty nesouvisející s IT, jako jsou klíčový personál, zařízení, krizová komunikace a ochrana pověsti, a měl by odkazovat na plán obnovy po havárii (DRP) pro obnovu/kontinuitu infrastruktury související s IT.
Opatření pro řízení obnovy po havárii IT lze rozdělit do následujících tří typů:
Dobrý plán DR vyžaduje, aby tyto tři typy kontrol byly zdokumentovány a pravidelně uplatňovány pomocí takzvaných „testů obnovy po katastrofě“.
Před výběrem strategie obnovy po havárii plánovač obnovy po havárii nejprve konzultuje plán kontinuity podnikání své organizace, který by měl specifikovat klíčové metriky pro cíl bodu obnovy a cíle doby obnovy [28] Metriky obchodních procesů jsou poté mapovány na jejich systémy a infrastrukturu [ 29 ] .
Nedostatek správného plánování může zvýšit dopad přírodní katastrofy [30] . Po porovnání metrik organizace zkontroluje rozpočet IT; RTO a RPO musí odpovídat dostupnému rozpočtu. Analýza nákladů a přínosů často určuje, která opatření pro obnovu po havárii by měla být použita.
The New York Times píší, že přidání cloudového zálohování k výhodám místní a offsite páskové archivace „přidává vrstvu ochrany dat“ [31] .
Mezi běžně používané strategie ochrany dat patří:
V mnoha případech se organizace může rozhodnout použít externího poskytovatele obnovy po havárii k poskytnutí záložního místa a systémů, spíše než používat vlastní vzdálená místa, stále častěji prostřednictvím cloud computingu.
Kromě toho, že se organizace připravují na nutnost obnovy systémů, přijímají také preventivní opatření, aby zabránily katastrofě. Mohou zahrnovat:
Jedním široce používaným typem klasifikace plánu obnovy je sedmistupňová klasifikace, vyvinutá koncem 80. let 20. století Technickým řídícím výborem SHARE, který byl vyvinut společně s IBM. Vyvinuli bílou knihu popisující úrovně služeb obnovy po havárii pomocí úrovní 0 až 6. Od té doby se objevila řada klasifikací, které s tím soutěží a odrážejí další vývoj v technologii a průmyslu jako celku. Různé klasifikace se zaměřují na různé aspekty nebo technické vlastnosti procesu restaurování. Klasifikace Wiboobratr a Kosavisutee je tedy zaměřena především na řešení DRaaS . Níže je uvedena srovnávací tabulka takových klasifikací [33] .
| Úroveň | SDÍLET/ IBM [34] [35] [36] | Hitachi [37] | Wiboonratr a Kosavisutte [38] | Novell [39] | Xiotech [40] |
|---|---|---|---|---|---|
| 0 | Neexistuje žádný plán obnovy po havárii. | ||||
| jeden | Probíhají zálohy, zálohy jsou přesunuty do samostatné budovy, ale není tam žádná aktivní pohotovostní lokalita . Tato metoda rezervace je označována jako metoda přístupu k pickupu (PTAM) [17] . | Zálohování na pásku mimo pracoviště . | Obnova bodu v čase je možná. | Záloha na pásku/ruční obnovení. | Úroveň 4
Plánované zálohy na "studené" zálohovací místo |
| 2 | Probíhá zálohování, existuje horké záložní místo , na které lze data ze zálohy obnovit [17] . Metoda je známá jako PTAM+hotsite. | Záloha se provádí na pásku v primárním nebo záložním místě. | Kopie vytvořené na pásce se doručují na předem připravené místo zálohování. | Tradiční ukládání/obnovení obrazu disku. | |
| 3 | "Elektronické úložiště" (elektronická úschovna). Oproti úrovni 2 přibyla možnost pravidelně kopírovat (a podle toho i obnovovat) data z hlavního webu. Typická doba zotavení je 24 hodin [34] . | „Elektronické úložiště“ – obdoba klasifikace SHARE/IBM. | Diskové kopie poskytující obnovu v určitém okamžiku jsou vytvářeny na více místech | Flexibilní (včetně jednotlivých souborů a s výběrem verze souboru pro obnovu) ukládání/obnovení obrazu disku. | Úroveň 3
Relativně rychlá obnova ze záloh prováděných asynchronně nebo podle plánu na „teplé“ místo zálohování. |
| čtyři | Vytvářejí se kopie, které umožňují obnovu v určitém okamžiku . | Jediná záloha zapsaná na disk. | Provádí se vzdálené protokolování provozu systému. | Zálohování/obnova na základě virtualizace. | |
| 5 | Zajišťuje integritu transakčních dat . | Schopnost obnovit pomocí konsolidace souborů z různých obrazů disku | Vytvořte paralelně stínovou kopii produkční databáze | Redundance založená na serverech běžících v clusteru. | Úroveň 2
Rychlá obnova z asynchronní kopie na web v pohotovostním režimu. |
| 6 | Nulová nebo malá ztráta dat po obnovení. | Dostupnost dat na disku sdíleném mezi primárním a záložním systémem. | Data se kopírují vzdáleně. | ||
| 7 | Vysoce automatizovaná obnova. | Zrcadlení disku mezi primárním a sekundárním systémem. | Provádí se vzdálené kopírování dat odolné proti chybám. | Úroveň 1
Okamžité obnovení ze synchronní kopie na web v pohotovostním režimu. | |
| osm | Kompletní duplikace dat. | ||||
Rozumí se, že každá další úroveň v rámci jedné z klasifikací svými vlastnostmi doplňuje nebo nahrazuje předchozí.
Disaster Recovery as a Service (DRaaS) je smlouva s třetí stranou, poskytovatelem služeb a/nebo hardwaru. [41] . Obvykle nabízené poskytovateli služeb jako součást jejich portfolia služeb. Řada velkých dodavatelů vybavení nabízí jako součást této služby modulární datová centra , která vám umožní co nejrychleji nasadit vybavení potřebné pro obnovu po havárii.