RPO a RTO – cíl bodu obnovy a cíl doby obnovy – jsou zásadní metriky při vývoji plánů a strategie obnovy po havárii (DR).
Jsou zásadní pro zjištění podrobností o tom, jak se zotavíte z neplánovaného výpadku, ať už technického, nebo stále častěji v důsledku nekalých úmyslů, jako je ransomware.
Je to proto, že požadavky vaší organizace, pokud jde o to, kolik dat si můžete dovolit ztratit a jak dlouho si můžete dovolit, aby byly systémy nedostupné, určují techniky a produkty úložiště a ochrany dat, které musíte specifikovat.
Tento článek se podívá na to, jak definujeme RPO a RTO, proč jsou důležité a jak je vypočítat pro vaši organizaci a funkce v ní.
Definovat RTO a RPO
RTO je definováno globálním standardem ICT pro obnovu po havárii, ISO/IEC 27031:2011, jako: „Časové období, během kterého jsou minimální úrovně služeb a/nebo produktů a podpůrné systémy, aplikace nebo funkce musí být po narušení obnoveny.“
RPO je mezitím definováno jako: „Časový okamžik, do kterého musí být data obnovena poté, co došlo k přerušení.“
V jednoduché angličtině je RTO doba, po kterou si můžete dovolit, aby systémy a data byly nedostupné. Měří se v čase a je to období, během kterého požadujete obnovení systémů po výpadku.
RPO je množství dat, které si můžete dovolit ztratit. Také se měří v čase, ale viděno optikou toho, kolik dat si můžete dovolit ztratit. Bude se tedy řídit tím, jak dlouho uplynula poslední záloha a/nebo snímek, nebo jak aktuální jsou data na webu, na který přepnete při selhání.
Organizace tedy může například určit, že může pracovat s daty v délce jedné hodiny a RPO v hodnotě dvou hodin.
Obrázek však bude pravděpodobně méně jednoduchý.
Různé RTO a RPO pro různé aplikace?
Aplikační prostředí v rámci organizace se však nehodí k plošným metrikám, které pokrývají vše.
Skutečnost je taková, že granulární RTO a RPO jsou pravděpodobně to, co je potřeba k reakci na situace v reálném světě.
Pokud by tedy například vypadly všechny vaše systémy, prioritou by bylo obnovit ty, které jsou veřejně přístupné a generují příjmy, což může zahrnovat časově velmi kritické transakční aplikace.
Tyto by měly nejvyšší prioritu a zabíraly by opačný konec kontinua, řekněme, dlouho uložená a nepoužívaná archivovaná data nebo nestrukturovaná data bez kritických časových omezení.
Pokud jde o praktické důsledky, tyto rozdíly se projeví v používání různých tříd úložiště a ochrany dat.
Výpočet RTO a RPO
Místo, kde začít, je určit úroveň rizika pro organizaci nedostupnosti systémů a po jakou dobu to lze tolerovat.
Má smysl kategorizovat a upřednostňovat systémy a klást otázky jako:
Příklady RPO a RTO
Ideální RPO a RTO by byly nulové. Ale čím víc se blížíte nule, tím víc to stojí.
Pro většinu systémů tedy nula není volbou, ale některé ji budou potřebovat – jmenovitě bankovní transakční systémy, které nesnesou téměř žádnou ztrátu dat nebo nedostupnost systému.
Reálněji byste pravděpodobně kategorizovali aplikace a systémy podle úrovní. Takže například:
Vrstva RTO/RPO a metoda ochrany dat
Vrstva z velké části určuje úroveň ochrany dat. Takže například systémy Tier 1 potřebují duální zápisy a/nebo častou replikaci dat, aby se chránily před lokalizovanými problémy. Pravděpodobně bude také potřebovat schopnost rychlého převzetí služeb při selhání do vzdáleného umístění v případě hrozeb na úrovni lokality.
Systémy úrovně 2 by potřebovaly méně časté kopírování dat, ale také by musely být schopny přepnout na vzdálené systémy. Všechny úrovně by byly podloženy každodenním zálohováním a také umístěním do cloudových a/nebo páskových archivů, jak data stárnou.
Schopnost vaší organizace splnit smlouvy o úrovni služeb RTO a RPO (SLA) bude určena rozsahem výpadku, takže je třeba ji vypracovat ve spojení s posouzením rizik a analýzou dopadu na podnikání, která se zabývá pravděpodobným rozsahem potenciálních příčin prostojů a seřadí je z hlediska pravděpodobnosti a účinku. Selhání disku je zcela zjevně méně dopadné než například zaplavené místo.
Cloudové úložiště a RTO/RPO
Když vymyslíte typy úložiště a ochrany dat vhodné pro vaši organizaci a různé systémy, které musí provozovat a chránit, je stále pravděpodobnější, že budete muset použít cloud skladování v úvahu.
Použití cloudu vedle datového centra je do značné míry běžné, přičemž průzkumy zjistily, že téměř polovina zákazníků nějakým způsobem využívá cloud k obnově po havárii.
Problém, který přináší požadavky a výpočty RPO a RTO, je ten, že jste nyní závislí na externím poskytovateli. Ujistěte se tedy, že důkladně prodiskutujete své požadavky na RPO a RTO pro různé třídy dat a svažte poskytovatele co nejvíce jasnými smlouvami SLA. Spolupráce s poskytovatelem cloudu a vzdálenými weby může být jiná.
Takže můžete dokonce uvažovat o tom, že některé systémy a data nelze ponechat pod správou SLA s třetí stranou a zjistíte, že je chcete přenést zpět do společnosti.
