Целевое время восстановления (Recovery Time Objective, RTO) и целевая точка восстановления (Recovery Point Objective, RPO) играют совершенно разные роли в резервном копировании и аварийном восстановлении (Backup and disaster recovery, BDR). Рассказываем, что подразумевают эти параметры в техническом и деловом смысле, а также почему невозможно обеспечить безопасность бизнес-активов без чётко определённых RTO и RPO. 

Основные различия между RTO и RPO

Целевое время восстановления — это временной интервал, в течение которого бизнес-актив должен быть восстановлен в случае технического сбоя. Целевая точка восстановления — это приемлемый объём данных, который компания готова потерять в случае инцидента.

Оба показателя измеряются временем и жизненно важны для успешного аварийного восстановления. Оба требуют комплексного планирования и инициативы в области информационной защиты.

Различия этих двух показателей: 

• RTO учитывает аварийное восстановление, бизнес-процессы и ИТ-инфраструктуру. RPO берёт во внимание стоимость создания резервных копий и ценность данных.

• RTO фокусируется на восстановлении информационной системы и приложений, а RPO — на приемлемых потерях данных и периодичности создания резервных копий.

• RPO проще рассчитать, поскольку этот показатель охватывает только данные в контексте восстановления.

• RTO сложнее, поскольку в нём учтено множество характеристик (команды реагирования, отказоустойчивость, холодные и горячие участки и т. д.).

• RPO полагается в основном на автоматизацию процессов восстановления и создания резервных копий, а RTO подразумевает в основном механические задачи и практичность восстановления.

• Низкие показатели RTO намного дороже низких показателей RPO.

Вместе RTO и RPO помогают бизнесу узнать, как долго он может позволить себе оставаться без работы и насколько свежими будут данные после их восстановления. Большинство компаний предпочитают восстанавливаться после сбоев как можно быстрее, но чем короче RTO или RPO, тем выше стоимость восстановления.

Лучший способ гарантировать низкие показатели RTO и RPO без дорогостоящих первоначальных инвестиций — положиться на облачные сервисы аварийного восстановления (Disaster-Recovery-as-a-Service, DRaaS). Что бы ни пошло не так, DRaaS гарантирует, что вы вернётесь к обычному режиму работы за считанные минуты, а не за часы или дни.

Подробнее об RTO

Целевое время восстановления означает временные рамки, в течение которых ИТ-ресурс должен полностью восстановиться после разрушительного события. Например, система может иметь RTO 30 минут. В этом случае у группы реагирования на инциденты есть полчаса, чтобы всё восстановить и запустить.

«Часы» RTO начинают отсчитывать время, когда затронутая система выходит из строя, и заканчивают отсчёт, когда система снова полностью работоспособна. Некоторые RTO начинаются, когда ответственная группа получает уведомление об инциденте, — подход, более распространённый для не критически важных систем.

Любая система с определённым RTO должна также измерять фактическую продолжительность восстановления (Recovery Time Actual, RTA). RTA и RTO редко бывают идентичны, но цель состоит в том, чтобы удерживать RTA в ожидаемых временных рамках RTO (RTA ≤ RTO).

Если RTA превышает RTO, вы можете: пересмотреть расчёт RTO и снизить порог восстановления (подход, который часто приводит к сокращению расходов на ИТ); обновить свой план восстановления после сбоев, чтобы в будущем обеспечить более быстрое реагирование.

RTO обычно совпадает с максимальным временем простоя, которое система может выдержать без ущерба для непрерывности бизнеса. Каждая система имеет разный уровень толерантности, поэтому нет необходимости иметь низкий RTO для каждого актива. Например, база данных HR не требует той же скорости восстановления, что и ваш основной сервер или брандмауэр.

Если вы полагаетесь на управляемые ИТ-услуги, то поставщик определяет ожидания RTO в соглашении об уровне обслуживания (SLA). Этот же документ также определяет все показатели доступности, времени отклика и времени разрешения.

Как рассчитать RTO

Не существует универсальной математической формулы для расчёта показателей RTO, которая подходит для каждой компании или типа системы. Для того, чтобы определить максимально подходящий период восстановления, нужно провести углублённый анализ рисков и влияния на бизнес-процессы (Business Impact Analysis, BIA), в ходе которого рассматриваются уникальные характеристики каждого актива, включая:

• последствия краха системы (денежные, регулятивные, репутационные и т. д.);

• общая критичность (то есть насколько повлияет простой системы на другие системы и конечных пользователей);

• предполагаемая стоимость простоя (обычно рассчитывается в минутах или часах);

• максимально допустимый период простоя;

• оценка уязвимостей, имеющихся в системе на данный момент;

• текущие меры безопасности и функции, защищающие актив;

• потенциальные угрозы (перебои с электроснабжением, локальные стихийные бедствия, определённые типы кибератак и т. д.);

• вероятность возникновения проблем в системе;

• последствия соблюдения отраслевых норм.

После того, как будет достигнуто глубокое понимание системы, группа аналитиков определяет оптимальный RTO с точки зрения ИТ. Следующий шаг — проконсультироваться с руководителями бизнес-подразделений и старшим руководством, чтобы определить, является ли предлагаемый RTO жизнеспособным с точки зрения бюджета.

В случае с RTO «быстрее» всегда означает «дороже». Возврат системы в строй менее чем за час требует больших инвестиций, поэтому не устанавливайте низкие значения для каждого актива. Определение RTO требует баланса между:

• последствиями простоя системы;

• риском возникновения неполадок в системе;

• стоимостью настройки процесса восстановления.

Будьте реалистичны при расчёте скорости восстановления — впечатляющий RTO, который ваша система или персонал не могут обеспечить, не имеет значения во время кризиса.

Подробнее об RPO

Целевая точка восстановления — это максимальный объём данных, с которым бизнес готов проститься во время инцидента. Команды измеряют показатель в часах или минутах с момента последнего резервного копирования рабочих данных. По истечении периода RPO объём потерянных данных превышает максимально допустимый порог. Например, если у системы RPO составляет 3 часа, то команда должна иметь рабочую копию данных не старше 3 часов в любое время. В случае аварии затронутая система может потерять до 3 часов данных, не вызывая долгосрочных проблем.

RPO обычно не применяются к архивным и историческим данным. Эта метрика предназначена для транзакционных файлов и обновлений, которые недавно вошли в систему.

RPO определяет частоту, с которой компания должна создавать резервные копии, чтобы гарантировать, что потеря данных не превысит порога толерантности. Чем короче период, тем меньше данных подвержены риску потери (как постоянной, так и временной).

Как и в случае с RTO, более короткие RPO требуют более значительных инвестиций. Нулевые или близкие к нулевым значения обычно требуют высокоскоростных технологий резервного копирования (например, непрерывной репликации и зеркалирования), высокой пропускной способности сети. Это дорогостоящие меры с точки зрения внедрения и поддержки, поэтому для определения RPO команде необходимо найти золотую середину между последствиями потери данных и стоимостью резервного копирования и восстановления.

Любой набор данных с RPO должен также измерять фактическую точку восстановления (Recovery Point Actual, RPA). Эта метрика представляет собой точное количество потерянных данных во время инцидента, поэтому RPA должен быть ниже или равен установленному RPO. Если это не так, у вас есть два варианта: снизить ожидания RPO или улучшить стратегию восстановления данных.

Как рассчитать RPO

Как и в случае с RTO, не существует универсальных формул для определения RPO, которые подходят для каждой компании. Определение RPO требует глубокого анализа каждого набора данных. Вот основные факторы:

• финансовые и операционные последствия потери данных;

• вероятность инцидентов;

• количество приложений, использующих набор данных;

• стоимость внедрения стратегии RPO;

• релевантные правила хранения.

Большинство компаний создают резервные копии своих данных с фиксированным интервалом (раз в час, день, неделю и т. д.).

Распространённые интервалы RPO и примеры их применения:

• 0 часов — наборы данных, потери которых неприемлемы из‑за их критической важности, правил или сложности воссоздания. Примеры: информация о платёжных шлюзах, истории болезни пациентов, торговля на фондовом рынке.

• 1 — 4 часов — стандарт для полукритических бизнес‑единиц с ограниченной устойчивостью к потерям. Примерами являются журналы чатов клиентов, панели управления продуктами и системы аутентификации паролей.

• 4 — 12 часов — оптимальный вариант для наборов данных, которые не окажут существенного влияния на бизнес в случае возникновения неполадок, например, баз данных маркетинговой или торговой статистики.

• 13 — 24 часов — подходит для некритичных данных, таких как файлы заказов на закупку или управления запасами.

Большинство наборов данных, которые не попадают ни в одну из категорий выше, требуют еженедельного резервного копирования. 

Заключение

Точно предсказать, когда произойдут инциденты, невозможно, но подготовиться к неприятным событиям все же можно. Надёжные RTO и RPO гарантируют, что вы контролируете последствия проблем и что сбои не окажут существенного влияния на прибыль вашего бизнеса. Эти преимущества делают выделение времени и ресурсов на подготовку RTO и RPO очевидным решением для большинства компаний.