RTO vs RPO: Понимание ключевых различий для восстановления после сбоев

Организации все больше полагаются на резервное копирование для защиты своих данных и обеспечения бизнес-непрерывности в случае катастрофы. Однако оценивается, что более 72% предприятий не могут соответствовать своим ожиданиям по восстановлению ИТ, связанным с целями восстановления точки (RPO) и времени (RTO).

Чтобы помочь вам создать эффективный план восстановления, необходимо полностью понять RTO и RPO, а также изучить различия между ними. В этом сообщении объясняется все, что вам нужно знать о этих двух параметрах для надежной стратегии восстановления после катастрофы. Продолжайте чтение, чтобы узнать, как вы можете добиться более строгих RPO и RTO для минимизации потери данных и быстрого возобновления нормальной бизнес-деятельности в случае катастрофы.

Что такое RTO?

Цель времени восстановления (RTO) относится к максимально допустимому времени простоя, которое организация может терпеть после наступления события, нарушающего работу. Другими словами, RTO – это длительность между наступлением катастрофы и восстановлением затронутых критических рабочих нагрузок.

Расчет RTO в основном зависит от вашего плана восстановления после катастрофы, доступных ресурсов и бюджета. В то время как ваша ИТ-инфраструктура недоступна, вам нужно некоторое время, чтобы определить причину(ы) сбоя и принять необходимые меры для его устранения. Однако шаги по восстановлению после катастрофы должны быть предприняты, чтобы обеспечить доступность и доступность критических систем и рабочих нагрузок, пока проблема на производстве не будет устранена. Ваш RTO – это время между сбоем и доступностью систем через резервные копии или рабочие нагрузки-реплики.

Что такое RPO?

Объект восстановления (RPO) представляет собой максимальное количество данных, которое организация может потерять в результате катастрофы без критических последствий. Этот показатель измеряется в часах/минутах с момента последних резервных копий/процесса репликации. Используйте его, чтобы определить, насколько часто вам нужно создавать резервные копии данных и реплики, чтобы снизить потери данных в случае нарушительного события.

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

Что такое RTO и RPO в восстановлении после катастрофы

Основная цель защиты данных ясна: вы хотите быть уверены, что критические данные не будут потеряны, если что-то пойдет не так, и что вы сможете соблюсти SLA вашей организации в терминах времени работы и доступности. Однако достаточно дорого отражать все изменения в вашей виртуальной среде на сайте чрезвычайного восстановления (DR) в реальном времени. Поэтому вам нужно принять идею того, что некоторые данные будут потеряны, и ваши ИТ-сервисы будут нарушены в случае сбоя. Таким образом, ваша задача – минимизировать эти потери и прерывания.

Давайте проиллюстрируем концепции RPO и RTO на простой диаграмме:

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

Различия между RTO и RPO

Чтобы понять, как определить RTO и RPO, вам следует рассмотреть их различия и их роль в процессе ЧС.

оцен

  • RTO в первую очередь заботится о периоде времени, в течение которого ожидается возобновление бизнес-операций в случае катастрофы. Пункты, которые следует учитывать, следующие:
    • Оцените потребности и приоритеты вашей организации, так как они уникальны для каждой организации.
    • Рассмотрите, какие приложения являются наиболее критическими для услуг и приложений, необходимых для выживания организации, а также какие могут быть последствия, если эти приложения выйдут из строя.
    • Определите порядок восстановления каждой системы/приложения, чтобы обеспечить успешное восстановление после катастрофы с минимальными потерями времени простоя.
  • RPO более сосредоточен на объеме данных, которые могут быть потеряны во время простоя, не нанося серьезного ущерба финансовому состоянию организации. Пункты, которые следует учитывать, следующие:
  • Определите частоту резервного копирования/репликации и объем данных, который может быть потерян между последним резервным копированием виртуальной машины и реальной катастрофой.
  • Рассмотрите объем данных, который ваша организация может позволить себе потерять для каждого типа нагрузки.

Затраты

Основное различие между RTO и RPO заключается в том, что первый учитывает все аспекты бизнес-структуры и процесса восстановления после катастрофы в целом, в то время как второй учитывает только критичность данных и приложений для обеспечения бизнес-продолжительности. Поэтому достижение значений RTO может быть сложной и дорогостоящей задачей для обеспечения быстрого восстановления. Точно так же, имея меньшие значения RPO, означает, что вам нужно выполнять больше резервных копий и создавать дополнительные точки восстановления, что может увеличить ваши затраты на хранение.

Автоматизация

  • Поскольку RPO сконцентрирован на данных и устойчивости вашей системы к потере, рекомендуется выполнять частые резервные копии данных. Многие современные резервные решения позволяют выполнять автоматизированные резервные копии виртуальных машин, что означает, что ваши стратегии резервного копирования могут быть настроены таким образом, чтобы эффективно соответствовать вашим целям RPO с минимальными затратами с вашей стороны.
  • Достижение RTO является более сложным процессом управления, так как учитываются все бизнес-процессы и системные компоненты, которые необходимо восстановить во время события восстановления после катастрофы. С этой точки зрения рекомендуется автоматизировать и оркестрировать весь процесс восстановления после катастрофы от начала до конца, чтобы обеспечить достижение ваших целей RTO.

Простота расчета

  • Метрика RPO легко рассчитывается, так как она охватывает только один аспект процесса восстановления – данные.
  • RTO учитывает все аспекты вашей организации, включая важность ваших данных и услуг, стоимость простоя, инвестиции в мероприятия по восстановлению после катастрофы и т. д. При расчете RTO следует учитывать различные типы нагрузок и приложений, поскольку они могут иметь разные процессы восстановления. Рекомендуется рассчитывать RTO на основе плана обеспечения бизнес-непрерывности, который описывает возможные бизнес-риски и угрозы, а также описывает шаги, которые должны быть предприняты для восстановления бизнес-операций.

Чтобы определить RTO , применимый к различным нагрузкам в вашей организации, ответьте на следующий вопрос:

Как долго определенное приложение/система/машина может быть отключена без значительного влияния на основные операции вашей организации?

Ответив на этот вопрос для разных машин, рассмотрите, удовлетворяют ли ожидаемые результаты ваши текущие бизнес-потребности. Если нет, подумайте, как можно улучшить ваши стратегии резервного копирования и планы восстановления после катастрофы, чтобы сохранять резервные данные как можно более актуальными.

Как достичь более жестких показателей RPO и RTO с помощью NAKIVO

NAKIVO Backup & Replication позволяет создавать резервные копии виртуальных и физических машин чаще, что улучшает RPO. Просто запланируйте регулярные резервные копии с интервалом, который не превышает вашего целевого значения.

Решение также помогает снизить RTO с мгновенным восстановлением виртуальной машины и функционалом репликации для VMware vSphere, Microsoft Hyper-V и Amazon EC2. Интегрируйте ваши службы мониторинга сети и запускайте процесс восстановления немедленно после недоступности виртуальной машины. Вы также можете создавать удаленные реплики (точные копии) критических виртуальных машин. Если оригинальная виртуальная машина вышла из строя, реплики будут автоматически включены. Если поддержка реплик требует больше ресурсов, чем вы можете позволить, вы можете выбрать функцию мгновенного запуска виртуальной машины из резервной копии.

Для достижения минимальных RTO NAKIVO Backup & Replication представил функционал оркестровки восстановления сайта. Полностью автоматизируйте отказ и возврат для различных сценариев ЧС и выполняйте бесперебойное тестирование для обеспечения восстановления в заданные сроки.

Source:
https://www.nakivo.com/blog/rpo-and-rto-difference/