Існують два поняття, які настільки часто вживаються разом, що їх починають сприймати як єдине ціле. У світі інформаційних технологій та забезпечення безперебійності бізнесу це не дивно. Ми поговоримо про такі поняття, як RPO (Recovery Point Objective) та RTO (Disaster Recovery).
Чомусь багато керівників використовують ці абревіатури як синоніми. Але насправді RPO і РТО відповідають на два абсолютно різних питання. І плутати їх — це все одно, що переплутати гальмо і кермо в автомобілі. У них різні функції, і ціна помилки незрівнянна.
RPO – це Recovery Point Objective, тобто цільова точка відновлення, яку пропонує компанія IT-Solutions. Цей показник відповідатиме на питання, який саме обсяг даних може втратити компанія під час збоїв. Він визначається хвилинами, годинами. І залежно від того, наскільки часто буде здійснюватися резервне копіювання, визначається й саме RPO. Нульове RPO означатиме, що не може бути втрачена жодна операція. І це найдорожчий та найскладніший режим захисту, оскільки тут використовуються сучасні технології та рішення, які забезпечують максимальну безперервність бізнесу.
РТО – це Disaster Recovery, час відновлення після відмови. Тобто тут ви отримуєте відповідь на питання, як довго система може відновлюватися після збоїв або помилок. Якщо ваше РТО становить 2 години, то це означає, що ви повинні відновити свою роботу протягом 2 годин. А РТО дорівнює 0, це означає, що система повинна бути доступною завжди, без перерв. Це вимагає кластеризації та архітектури високої доступності.
Чому небезпечно плутати ці два поняття? Тому що стратегії досягнення малого RPO та малого РТО кардинально відрізняються за технологіями та вартістю. РТО може бути коротким і дорівнювати кільком хвилинам. Але якщо РТО займатиме добу і більше, то це може не відповідати потребам самої компанії.
Класична помилка бізнесу і навіть деяких IT-директорів – це те, що вони просто формулюють фразу «нам потрібне швидке відновлення» і «нам потрібна мінімальна втрата даних». Вони зовсім не розрізняють поняття цільової точки відновлення та часу відновлення після відмови, а змішують їх в одну розпливчасту фразу. У результаті буде спроектована система, яка або невиправдано дорога, або, що ще гірше, виявляється незбалансованою, яка чудово захищає від втрати даних, але не дає жодних гарантій щодо часу відновлення сервісу. Справжня біда настає в момент реальної аварії, коли з’ясовується, що очікування керівництва та можливості інфраструктури кардинально розходяться.
