Установка целевого времени восстановления имеет решающее значение, особенно когда растет число взломов сети и атак программ-вымогателей. Никогда не знаешь, когда станешь следующей жертвой. На данном этапе, если ваше целевое время восстановления не определено, как бы вы разработали план резервного копирования и восстановления данных?
В этом посте вы познакомитесь с основами RTO и факторами, которые следует учитывать при настройке RTO.
Что такое целевое время восстановления?
Целевое время восстановления (RTO) определяется как максимально допустимая продолжительность времени, в течение которого приложение может быть недоступно, или максимально допустимый простой, который может выдержать организация без причинения значительного ущерба бизнесу после аварии, сбоя или любого недопустимого события.
Время RTO предполагает время, необходимое для восстановления и завершения восстановления отказавшей системы, как определено в соглашении об уровне обслуживания. Целевой уровень обслуживания учитывает время восстановления, установленное организацией для восстановления/восстановления своих критически важных ИТ-процессов/операций до нормального состояния после аварии, чтобы обеспечить непрерывность бизнеса.
Про Совет: Вы всегда должны стремиться к минимально возможному RTO, чтобы свести к минимуму последствия аварии. Чтобы определить RTO, вы должны сначала определить влияние продолжительности на ваш бизнес, в котором данные недоступны.
Например:
- Если 10% данных должны быть доступны в течение 24 часов,
- А после полной потери БД 50% данных должны быть доступны в течение 2 дней,
- Остальные 40 % данных должны быть доступны в течение следующих 5 дней, после чего
Ваш общий RTO = 8 дней.
Чтобы привести другой пример:
Предположим, сервер Exchange не работает. Если ваше RTO составляет 5 часов, то максимальное допустимое время простоя, которое может выдержать ваш бизнес, составляет 5 часов, а ваше RTO для Exchange Server должно быть меньше 5 часов. Ваша политика аварийного восстановления должна включать необходимые шаги, предпринимаемые ИТ-отделом для резервного копирования и восстановления данных.
Таким образом, при установлении целевого времени восстановления не существует универсального решения для план продолжения работы компании. RTO можно настроить для восстановления данных после аварии. Однако в случае возникновения инцидента практическая целесообразность плана аварийного восстановления в реальной жизни также зависит от конкретных инструментов и технологий, используемых для обеспечения восстановления. Таким образом, возможности достижения RTO различаются по мере того, как разные технологии и инструменты аварийного восстановления различаются по своим возможностям. RTO измеряется еще до начала сбоя и включает время, затрачиваемое на ремонт серверов, установку приоритетных приложений и восстановление данных. Он также включает методы восстановления и резервные копии данных, которые необходимо восстановить.
Что определяет RTO?
Целевое время восстановления — это целевое время, в течение которого приложения, системы и/или процессы переживают время простоя и не функционируют до начала сбоя. RTO имеет первостепенное значение для определения продолжительности времени для определения приоритетов приложений и процессов в рамках параметров RTO. В плане защиты данных и стратегии аварийного восстановления RTO отвечает на вопрос: «Каково целевое время, установленное для восстановления услуг после уведомления о нарушении работы службы?»
РТО может определить:
- Продолжительность в реальном времени, которая должна быть установлена для восстановления сайта с момента, когда инцидент прерывает нормальный поток операций до восстановления.
- Какие ИТ-подготовки должны быть разработаны для реализации плана аварийного восстановления
- Приемлемый уровень риска потери данных при отключении системы или ключевых приложений.
Как рассчитать RTO для планирования аварийного восстановления?
Метрика RTO заранее устанавливает целевое ожидание для ИТ-команды, поскольку она определяет пороговое значение того, насколько быстро система или приложение могут быть восстановлены после простоя и возвращены в оперативный режим. Определив эту меру с точки зрения объема «реального времени» для восстановления системы, вы можете спланировать свою стратегию восстановления, чтобы снова запустить службу. Чтобы рассчитать RTO, вы должны учитывать потери, связанные с нарушением целевого времени восстановления Плана обеспечения непрерывности бизнеса (BCP). Также включите анализ воздействия, который объясняет краткосрочные или долгосрочные последствия перерыва в предоставлении услуг. Сюда входят риски, упущенная выгода, расходы, приложения для клиентов, критически важные приложения и менее приоритетные приложения, которые затронуты или станут недоступны. RTO больше касается времени простоя и временных ограничений для процесса восстановления данных.
Чтобы определить RTO, вам может понадобиться несколько категорий RTO, поскольку для некоторых сбоев может не потребоваться много времени на восстановление, а для некоторых могут потребоваться другие решения для долгосрочной защиты. Например, RTO может быть намного больше для менее важных приложений (не часто используемых). В зависимости от уровня сложности нескольких действующих систем безопасности вам, возможно, придется установить RTO в соответствии с короткими и длинными интервалами резервного копирования. Это может произойти из-за вируса-вымогателя или другой крупной катастрофы.
Основные факторы, которые необходимо учитывать при расчете RTO
- Уравнение затрат и выгод для решений по восстановлению
- Приоритетные приложения отдельных систем и данных
- Шаги, которые должен предпринять ИТ-отдел на основе процессов, автоматизированных методов или технологий для восстановления ИТ-инфраструктуры.
- Стоимость простоя и смягчения последствий
- Сложность процедуры восстановления
Интервалы выборки RTO
Достижение почти нулевого RTO дорого обходится большинству ИТ-предприятий, но его можно достичь, если вы отдаете приоритет приложениям и данным. Для менее важных бизнес-приложений часы RTO могут потреблять больше объективного времени, чем обычно. Планы с почти нулевым RTO для критически важных приложений могут потребовать от вас рассмотреть возможность немедленного восстановления после сбоя.
В зависимости от серьезности сбоя можно установить достижимое целевое время RTO. Однако время восстановления RTO также зависит от ограничений ИТ-организации. Например, если восстановление всех ИТ-функций и операций занимает 3 часа, RTO должно быть не менее 3 часов.
Внимание: с точки зрения аварийного восстановления (DR) часы RTO запускаются сразу после запуска процессов восстановления.
При расчете RTO (целевого времени восстановления) для ваших бизнес-подразделений рассмотрите следующие выборочные интервалы:
1 час
Этот интервал предназначен для резервного копирования данных на внешние жесткие диски.
5-дневный
В этом случае наиболее экономичным решением будет резервное копирование данных с использованием компакт-диска, ленты или внешнего дискового хранилища.
Достичь RTO, путь Zmanda
Целевое время восстановления (RTO) и Целевая точка восстановления (RPO) являются невероятно важными целями и составляют основу плана восстановления. Как вы определяете последовательность шагов практических целей восстановления? Здесь мы можем помочь!
С планом Zmanda DRaaS и индивидуальными соглашениями об уровне обслуживания, независимо от размера вашего бизнеса, мы можем помочь вам сократить время простоя и избежать болезненных простоев в зависимости от потребностей вашего бизнеса. Помимо гибридного резервного копирования для поддержки перехода и достижения относительно более быстрого целевого времени восстановления, наше корпоративное решение сочетает в себе Amazon Glacier с 20-кратно более низкой стоимостью долгосрочного архивирования данных, что обеспечивает надежную высокую доступность и обеспечивает непрерывность бизнеса.
Наше корпоративное решение для резервного копирования объединяет резервное копирование, аварийное восстановление и долгосрочное архивирование, специально адаптированное к потребностям клиентов. Это обеспечивает безопасность, надежность, масштабируемость и доступность при восстановлении среды даже в случае полного отказа сервера.
Посмотрите сами! Давайте начнем с бесплатная пробная версия разработать стратегию резервного копирования данных или запросить демонстрация. Есть вопросы? Пожалуйста, свяжитесь с нами здесь.
