RTO против RPO: понимание их различий

RTO против RPO - в чем разница?

Пока ваши производственные системы и основные функции работают нормально, это успех для вашего отдела. Но в определенный момент времени происходит неприемлемое нарушение вашей работы, которое представляет собой серьезную угрозу. Часто бедствия случаются неожиданно, без предупреждения или без предупреждения. Это побуждает вас провести расчеты рисков и установить приоритеты восстановления, что является важным элементом как Непрерывность бизнеса и Аварийное восстановление (DR) процесс планирования.

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

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

RTO объяснил

Целевое время, затрачиваемое организацией на восстановление своих приложений и процессов после аварии, известно как целевое время восстановления (RTO). График восстановления является важным параметром для определения допустимого уровня простоя предприятия. RTO отвечает на вопрос: «как долго приложение может не работать, чтобы снова заработать после аварии без значительных потерь для бизнеса и недовольства клиентов». Этот ключевой показатель может помочь вам рассчитать время между восстановлением и допустимой потерей данных.

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

Чтобы рассчитать RTO на основе приоритета бизнес-приложений, очень важно сделать RTO как можно точнее.

• RTO близко к нулю: требуются услуги аварийного переключения для критически важных приложений
• RTO 4 часа: локальное восстановление после восстановления с нуля, завершающееся полной доступностью приложения и данных
• RTO 8+ часов: для второстепенных приложений, которые могут не работать в течение нескольких дней, не нанося серьезного ущерба бизнесу.

• Если минимально возможное время восстановления составляет 2 часа, время восстановления в час не может быть достигнуто.
• В другом случае, если вы установили RTO на 4 часа и в 12 часов произошел сбой системы, то сервер будет отремонтирован и запущен к 4:XNUMX, что означает достижение целевого RTO.
• Если ваш RTO установлен на 2 недели, инвестиции будут намного меньше, так как у вас будет достаточно времени для восстановления данных после того, как произошел сбой.

Разъяснение RPO

Проще говоря, цель точки восстановления (RPO) - это объем данных, который бизнес может позволить себе потерять и продолжить работу, не нанося значительного ущерба бизнесу. RPO обеспечивает непрерывность бизнеса с приемлемой продолжительностью устойчивости к потере данных во время простоя. Определение количества времени, «приемлемого» для вашей компании, чрезвычайно важно для вашего плана обеспечения непрерывности бизнеса. Чем дольше RPO, тем больше вероятность потери данных из-за длительного простоя. RPO пытается ответить на вопрос: «Сколько данных может позволить себе потерять бизнес?» Другими словами, RPO определяет возраст данных, которые необходимо восстановить, чтобы возобновить нормальные бизнес-операции.

RPO создает основу для определения вашего план аварийного восстановления (DR). Следовательно, важно оценить критичность данных, чтобы решить, какие приложения, процессы или информацию необходимо восстановить. Исходя из уровня критичности, вы должны восстановить данные. Поскольку RPO указан в указанном временном интервале последнего резервного копирования и типе резервного копирования, RPO полностью зависит от вашей системы резервного копирования. Резервное копирование данных с индивидуальным RPO обычно может быть автоматизировано каждый час, 24 часа, 12, от 8 до 4 часов или, возможно, каждые 10 минут. Это означает, что для 1-часового RPO вы можете потерять данные за один час или, если вы можете потерять данные за 24 часа, для вашего RPO установлено значение 20 часов.

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

• Почти нулевой показатель RPO: используйте непрерывную защиту данных (CDP) или репликацию (критически важные данные)
• RPO 4 часа: Использование почти непрерывная защита данных (CDP) который использует запланированную репликацию моментальных снимков
• RPO от 8 до 24 часов: используйте существующее решение для резервного копирования (данные, которые потенциально могут быть скопированы из других репозиториев)

• Если в 2:11 произошел сбой в системе, и система автоматически выполняет резервное копирование в 11:2, информация сохраняется в пригодном для использования формате в самой последней резервной копии. RPO должен быть XNUMX:XNUMX, что означает, что бизнес может потерять XNUMX часа данных без нарушения непрерывности бизнеса.
• Опять же, если ваш RPO составляет 6 часов, вы должны выполнять резервное копирование каждые 6 часов, учитывая, что каждые 24 часа могут представлять риск потери данных. Но если вы планируете резервное копирование каждые 1 час, это может вам дорого обойтись.

Существенные различия между RTO и RPO

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

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

Достижение RTO и RPO: разница между Zmanda

Обеспечение высокой доступности и доступности операций 24/7/365 - мечта любого бизнеса. Но расчет требований к RTO и RPO может повлечь за собой значительные риски потери данных и затраты на смягчение последствий. Кроме того, в течение длительного периода простоя, если цели RTO и RPO нереалистичны, это может серьезно ударить по вашему бизнесу. Результат? Утраченная репутация, доверие клиентов и сотни потерянных транзакций! Поэтому выбор правильного партнера для восстановления имеет решающее значение для достижения ваших целей восстановления. Здесь вам нужно оценить уравнение затрат и выгод, улучшив показатели RTO и RPO как часть вашего План аварийного восстановления.

Оставьте все это с помощью комплексного облачного решения «все в одном» от Zmanda. решение для аварийного восстановления, который объединяет решения для резервного копирования, аварийного восстановления и безопасного доступа к шлюзу для масштабирования резервного копирования в разных регионах и при любом количестве рабочих нагрузок. Архитектура собственного кода Zmanda может помочь вам в мгновенном восстановлении критически важных приложений и данных, а также в нескольких типах хранилищ резервных копий, сведя время восстановления к минимуму. Кроме Архитектура хранилища Amazon Glacier также предлагает более быструю архитектуру хранилища, которая обеспечивает бесшовное гибридное резервное копирование. Кроме того, благодаря многоуровневой безопасности клиенты Zmanda могут рассчитывать на повышенную безопасность во время восстановления и резервного копирования, что снижает управление данными затраты, не влияя на их бизнес.

Хотите узнать больше о том, как мы можем помочь вам определить практические цели восстановления и добиться непрерывности бизнеса? Свяжитесь с нами для получения дополнительной информации или просто посетите наш Решение DR стр.

Попробуйте Zmanda 4.0 бесплатно Запрос демо

RTO против RPO - в чем разница?

Пока ваши бизнес-приложения и системы работают, это успех для вашего отдела. Но в определенный момент, если произойдет неприемлемый сбой, он может представлять значительную угрозу. Часто бедствия случаются неожиданно, без предупреждения или без предупреждения. Это побуждает вас провести расчеты рисков и установить приоритеты восстановления, что является важным элементом Непрерывность бизнеса и Аварийное восстановление (DR) процесс планирования.

Во время сбоя ваша система должна быть немедленно восстановлена ​​без каких-либо значительных потерь для бизнеса. Целевое время восстановления (RTO) и Целевая точка восстановления (RPO) - это два критических параметра, с помощью которых вы можете оценить, сколько потерь данных может выдержать ваш бизнес. Вы должны согласовать целевые показатели RPO и RTO, чтобы восстановить критически важные приложения в кратчайшие сроки. Если значения восстановления нереалистичны, риск и расходы, связанные с достижением цели аварийного восстановления, могут сказаться на вашем бизнесе. Следовательно, RTO и RPO являются важными бизнес-метриками, которые играют ключевую роль в определении непрерывности бизнеса и аварийного восстановления в долгосрочной перспективе.

Теперь вопрос: связаны ли цели RTO и RPO?

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

Что такое RTO?

Целевое время восстановления (RTO) - это целевое время, которое ваша организация может использовать для восстановления своих приложений и процессов после аварии. График восстановления является важным параметром для определения допустимого уровня простоя предприятия.

RTO отвечает на вопрос: «Как долго приложение может не работать после стихийного бедствия? RTO также отвечает, сколько времени потребуется, чтобы начать работу без значительных потерь для бизнеса. Используя этот ключевой показатель, вы можете рассчитать время между восстановлением и приемлемой потерей бизнес-данных.

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

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

Чтобы точно установить целевые значения RTO, сначала необходимо определить высокоприоритетные бизнес-приложения на основе трехуровневой модели аварийного восстановления:

1-го уровня	Почти нулевое значение для критически важных приложений	Чтобы достичь почти нулевого RTO, приложения должны переключиться на возможность аварийного переключения.
2-го уровня	Критически важные для бизнеса приложения, требующие 4 часа RTO	Чтобы достичь RTO в 4 часа, необходимо выполнять локальное восстановление не реже, чем каждые 4 часа. Это обеспечит доступность данных для вашего бизнеса.
3-го уровня	Некритические приложения, требующие RTO 8 часов	Чтобы достичь RTO более 8 часов, вы можете восстановить второстепенные приложения с помощью существующего решения для резервного копирования.

Примеры использования RTO:

Давайте рассмотрим пример сценария обеспечения непрерывности бизнеса для банковской системы во время стихийного бедствия:

• Учитывая, что 1-часовой простой может быть катастрофическим, вы не сможете достичь RTO в час, если наименьшее время восстановления составляет 2 часа. Потому что RTO стремится восстановить все в течение часа после сбоя.
• Если вы установили RTO на 4 часа, а в 12 часов произошел сбой системы. Вы должны восстановить данные сервера к 4:XNUMX, чтобы достичь целевого RTO.
• Если RTO установлен на 2 недели, ваши вложения на аварийное восстановление будут намного меньше. Это потому, что у вас есть достаточно времени для восстановления данных после того, как произошел сбой.

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

Что такое RPO?

Целевая точка восстановления (RPO) - это максимальный объем потери данных, который ваш бизнес может себе позволить без значительного ущерба. Вы должны определить количество времени, «приемлемое» для вашей компании в своем плане обеспечения непрерывности бизнеса. Чем длиннее RPO, тем больше потери данных из-за длительного простоя. RPO пытается ответить на вопрос: «Сколько данных может позволить себе потерять бизнес?» Другими словами, RPO определяет возраст данных, которые необходимо восстановить, чтобы вернуть бизнес-операции в нормальное состояние.

Почему вам нужно заботиться о RPO?

RPO создает основу для определения план аварийного восстановления (DR). Первый шаг - определить временные рамки RPO, которые определяют периодичность резервного копирования. Идея состоит в том, чтобы до стихийного бедствия всегда была доступна резервная копия. Однако вы должны оценить ценность данных, которые необходимо восстановить. В зависимости от уровня критичности данных вам необходимо установить RPO для непрерывного резервного копирования. Для предприятий очевидна потеря данных во время простоев. Но, определив временные рамки RPO, вы можете установить частоту резервного копирования данных, чтобы потерять наименьший объем данных, что вполне приемлемо.

Вы также можете автоматизировать резервное копирование данных с отдельными RPO. Это означает, что вы можете устанавливать RPO ежечасно, 24 часа, 12 часов, от 8 до 4 часов или каждые 10 минут. Таким образом, за 1 час RPO бизнес может потерять данные за один час. Опять же, если вы можете потерять данные за 24 часа, вы можете установить RPO на 20 часов.

Хотя поддержание почти нулевого RPO возможно с помощью стратегий аварийного переключения / восстановления после сбоя, но это дорогостоящее мероприятие.

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

Для высокоприоритетных приложений важно определить, сколько данных организация может позволить себе потерять.

Примеры использования RPO:

• Предположим, что на вашем предприятии произошел сбой системы в 2:11, а система выполняет резервное копирование в 11:2. Поскольку вы сохранили информацию в самой последней резервной копии, RPO должно быть XNUMX:XNUMX. Здесь бизнес может позволить себе потерять XNUMX часа данных без нарушения непрерывности бизнеса.
• Опять же, если RPO составляет 6 часов, вы должны выполнять резервное копирование каждые 6 часов. Это связано с тем, что каждые 24 часа может возникнуть риск потери данных. Но если вы планируете резервное копирование каждые 1 час, это может дорого вам обойтись.

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

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

• С помощью RTO вы можете измерить количество времени, в течение которого бизнес-приложения могут не работать во время простоя. Принимая во внимание, что RPO измеряет переменный объем допустимой потери данных во время простоя.
• Вы можете измерить RTO, взяв начальную точку отключения. Но для измерения RPO необходимо выполнить ретроспективное измерение, чтобы определить потерю данных, которую бизнес может выдержать из последней созданной резервной копии.
• RTO включает шаги, которые ИТ-отдел должен предпринять для сокращения времени простоя и восстановления работоспособности приложений. RPO определяет, насколько далеко ИТ-специалисты готовы зайти, чтобы восстановить данные, вернувшись к последней сделанной резервной копии.
• При расчете RTO время восстановления RTO варьируется, поскольку необходимо учитывать несколько факторов. Например, линейные временные рамки, день стихийного бедствия и т. Д. Еще больше усложняют его расчет. RPO легче рассчитать и реализовать, если взять последние данные об использовании данных и переменных резервного копирования.
• Поскольку RTO включает восстановление всей инфраструктуры, стоимость восстановления резко возрастает при соблюдении почти нулевого RTO. Однако с помощью детализированной репликации с почти нулевой RPO вы можете непрерывно реплицировать данные с почти нулевой потерей данных. Это упростит стоимость и ускорит восстановление приложений, которым требуется высокая доступность. Более того, более длительный RPO становится доступным, в отличие от восстановления всей инфраструктуры.

Достижение RTO и RPO: разница между Zmanda

Поддержание бизнес-операций в режиме онлайн 24/7/365 - мечта любого бизнеса. Но целевые значения времени и точки восстановления (RTPO) не являются универсальными. Во время простоев, если цели RTO и RPO нереалистичны, это может сильно ударить по вашему бизнесу. Результат? Утраченная репутация, доверие клиентов и сотни потерянных транзакций! Поэтому выбор правильного партнера для восстановления имеет решающее значение для достижения ваших целей восстановления. Здесь вам нужно оценить уравнение затрат и выгод, улучшив показатели RTO и RPO как часть вашего План аварийного восстановления.

Краткая сводка новостей

Итак, вы определили целевые значения RTO и RPO в зависимости от приоритета приложения. Большой! Пришло время выбрать правильную стратегию аварийного восстановления для достижения целей RTO и RPO. Не смотрите дальше. Универсальное облачное решение для аварийного восстановления Zmanda объединяет резервное копирование, аварийное восстановление и безопасный доступ к шлюзу, что позволяет масштабировать резервные копии для любого количества рабочих нагрузок. Благодаря архитектуре собственного кода Zmanda вы можете охватить все возможные сценарии сбоев, чтобы достичь RPO почти в реальном времени для рабочих нагрузок даже во время серьезных сбоев.

Зманда поддерживает Хранилище Amazon Glacier может значительно снизить стоимость хранения, обеспечивая при этом непрерывное резервное копирование всех ваших критически важных данных. Кроме того, благодаря многоуровневой безопасности вы можете рассчитывать на повышенную безопасность данных при одновременном сокращении управление данными затраты, не влияя на чистую прибыль вашего бизнеса.

Хотите узнать больше о том, как мы можем помочь вам в достижении целевых показателей RTO и RPO для обеспечения непрерывности бизнеса? Свяжитесь с нами для получения дополнительной информации или просто посетите наш Решение DR стр.