RPO и RTO – цел за точка на възстановяване и цел за време за възстановяване – са жизненоважни показатели при разработването на планове и стратегия за възстановяване след бедствие (DR).
Те са фундаментални за изясняване на подробностите за това как ще се възстановите от непланирано прекъсване, било то техническо или все по-често в резултат на злонамерено намерение, като например рансъмуер.
Това е така, защото изискванията на вашата организация по отношение на това колко данни можете да си позволите да загубите и колко дълго можете да си позволите системите да бъдат недостъпни, диктуват техниките за съхранение и защита на данните и продуктите, които трябва да посочите.
Тази статия ще разгледа как дефинираме RPO и RTO, защо са важни и как да ги изчислим за вашата организация и функциите в нея.
Дефинирайте RTO и RPO
RTO се определя от глобалния ИКТ стандарт за възстановяване след бедствие, ISO/IEC 27031:2011, като: „Периодът от време, в рамките на който минималните нива на услуги и/или продукти и поддържащите системи, приложения или функции трябва да бъдат възстановени след настъпване на прекъсване.“
RPO междувременно се дефинира като: „Моментът във времето, до който данните трябва да бъдат възстановени след настъпило прекъсване.“
На обикновен английски, RTO е времето, през което можете да си позволите системите и данните да бъдат недостъпни. Измерва се във времето и е периодът, в рамките на който изисквате системите да бъдат възстановени след прекъсване.
RPO е количеството данни, което можете да си позволите да загубите. То също се измерва във времето, но се гледа през призмата на това колко данни можете да си позволите да загубите. Така че ще се управлява от това колко време е било преди последното архивиране и/или моментна снимка или колко скорошни са данните на сайт, към който прехвърляте при срив.
Така например една организация може да определи, че може да работи с RTO от един час и RPO от два часа данни.
Картината обаче вероятно ще бъде по-малко проста от това.
Различни RTO и RPO за различни приложения?
Но пейзажът на приложенията в една организация не се поддава на общи показатели, които покриват всичко.
Реалността е, че детайлните RTO и RPO вероятно са това, което е необходимо, за да се отговори на ситуации в реалния свят.
Така че, например, ако всичките ви системи се повредят, приоритетът ще бъде възстановяването на тези, които са публични и генерират приходи, което може да включва изключително критични във времето приложения за транзакции.
Те ще бъдат с най-висок приоритет и ще заемат противоположния край на континуума от, да речем, дълго съхранявани и неизползвани архивирани данни или неструктурирани данни без критични за бизнеса времеви ограничения.
Що се отнася до практическите последствия, тези разлики ще бъдат отразени в използването на различни класове съхранение и защита на данните.
Изчисляване на RTO и RPO
Мястото, от което трябва да започнете, е да определите нивото на риск за организацията на системите да бъдат недостъпни и за какъв период от време това може да бъде толерирано.
Има смисъл да се категоризират и приоритизират системите и да се задават въпроси като:
Примери за RPO и RTO
Идеалните RPO и RTO биха били нула. Но колкото повече се доближавате до нулата, толкова повече струва.
Така че нулата не е опция за повечето системи, но някои ще се нуждаят от нея – а именно системи за банкови транзакции, които почти не издържат на загуба на данни или неналичност на системата.
По-реалистично, вероятно бихте категоризирали приложенията и системите по ниво. Така например:
Ниво RTO/RPO и метод за защита на данните
Нивото в голяма степен определя нивото на защита на данните. Така например системите от ниво 1 се нуждаят от двойно записване и/или честа репликация на данни, за да се предпазят от локализирани проблеми. Вероятно ще се нуждае и от възможност за бързо прехвърляне към отдалечено местоположение в случай на заплахи на ниво сайт.
Системите от ниво 2 ще се нуждаят от по-рядко копиране на данни, но също така ще трябва да могат да преминават при срив към отдалечени системи. Всички нива ще бъдат подкрепени от ежедневно архивиране, както и поставяне в облачни и/или лентови архиви с остаряването на данните.
Способността на вашата организация да изпълни RTO и RPO споразуменията за ниво на обслужване (SLA) ще се определя от обхвата на прекъсването, така че трябва да се разработи във връзка с оценка на риска и анализ на въздействието върху бизнеса, който разглежда вероятния диапазон на потенциални причини за престой и ги класира по отношение на вероятност и ефект. Повредата на диска очевидно е по-малко въздействаща от наводнен сайт, например.
Съхранение в облак и RTO/RPO
Когато изработите типовете съхранение и защита на данните, подходящи за вашата организация и различните системи, които тя трябва да управлява и защитава, е все по-вероятно да се наложи да използвате облак съхранение предвид.
Използването на облака заедно с центъра за данни е почти масово, като проучванията показват, че почти половината от клиентите използват облака за възстановяване след бедствие по някакъв начин.
Трудността, която води до изискванията и изчисленията на RPO и RTO, е, че сега сте зависими от външен доставчик. Така че не забравяйте да обсъдите обстойно вашите изисквания за RPO и RTO за различни класове данни и обвържете доставчика възможно най-много с ясни SLA. Възможно е да има други усложнения при работа с облачен доставчик и отдалечени сайтове.
Така че може дори да помислите, че някои системи и данни не могат да бъдат оставени да се управляват от SLA с трета страна и да откриете, че искате да ги върнете обратно в компанията.
