Rpo rto что это

Что такое RPO и RTO

В этой статье я бы хотел подробно остановиться на двух магических показателях, с которыми необходимо определиться до того, как планировать резервное копирование и восстановление не только баз данных Microsoft SQL Server, но и любых других хранилищ информации. Не понимая и не зная этих двух чисел, вы рискуете неправильно оценить риски для бизнеса и составить неверный план восстановления.

Итак, RPO (recovery point objective) это максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, у нас имеется информационная система и RPO для нее мы определили в 1 час. Это значит, что, если вдруг происходит авария, мы готовы к тому, что систему удастся восстановить, но в ней будут потеряны данные не более, чем за последний час. Количество потерянных данных может быть меньше, если нам повезет, но не более 1 часа. Этот показатель говорит нам о том, как часто мы должны делать резервные копии нашей системы, и какие технологии применять, чтобы удержать этот показатель. Может ли он быть ноль? Теоретически да, но на практике организовать это очень сложно. Это можно организовать, только, если запись идет как минимум в 2 разных хранилища. Использование AlwaysOn Availability Groups или Database Mirroring вам не поможет, т.к. эти технологии не спасут от случайного удаления таблицы.

RTO (recovery time objective) это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Например, в центре обработки данных произошел пожар, но мы хотим, чтобы система была снова доступна для работы через 2 часа. Это и есть наш RTO. Мы должны планировать так, чтобы за этот промежуток восстановить работоспособность информационной системы на резервном оборудовании или площадке. Это можно реализовать с помощью различных технологий отказоустойчивости или же простым восстановлением из резервных копий на другой сервер. В любом случае мы должны обеспечить этот показатель при инциденте.

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

Источник

Что такое Disaster Recovery

Disaster Recovery (аварийное восстановление) — это сервис восстановления ИТ-систем и данных после сбоя любого уровня. Как правило, предлагается облачными провайдерами как отдельная услуга или включается в состав крупного решения. Условно можно разбить на три составляющие: резервная площадка, программные решения и план восстановления.

Причины востребованности Disaster Recovery

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

Помимо стабильности также необходимо обеспечить быстрое восстановление систем после сбоя. Чем скорее всё заработает, тем меньше негативных последствий для компании. Для этого существуют решения Disaster Recovery — системы аварийного восстановления ИТ-инфраструктуры после сбоя.

Disaster Recovery является частью плана обеспечения непрерывности бизнеса. Его идея в том, что компания должна работать, несмотря на внутренние сбои, кибератаки, другие инциденты. А в случае аварии — не потерять ценные данные и быстро восстановить работоспособность.

Для аварийного восстановления необходима параллельная IT-инфраструктура, которая будет использоваться для хранения данных и шаблонов виртуальных машин либо выступит в роли вспомогательной системы, которая возьмёт на себя рабочие задачи на время инцидента.

Чаще всего Disaster Recovery предлагают облачные провайдеры. Компании-клиенту предоставляются облачные мощности, на которых можно расположить резервную информационную систему (ИС). Основная же располагается в другом ЦОД. Между системами настраиваются каналы связи, чтобы данные одновременно поступали в основную и резервную ИС.

Важно понимать, что аварийное восстановление как сервис (DRaaS) отличается от бэкап-решений. Основная задача системы резервного копирования — сохранность данных в случае аварии. Disaster Recovery же отвечает за сокращение времени простоя ИТ-систем. Бэкап не даёт компании возможность продолжить работу на резервной платформе, пока будет восстанавливаться работоспособность основной. Услуга DRaaS гарантирует, что у компании будет площадка, идентичная основной, которая сможет сохранить непрерывность бизнес-процессов.

Ключевые параметры аварийного восстановления

У решений Disaster Recovery есть два основных параметра, которые влияют на стоимость катастрофоустойчивой системы и размер ущерба в случае инцидента: RTO и RPO.

RTO (recovery time objective) — период времени, за который ИТ-система должна восстановиться. Если RTO составляет четыре часа, то инфраструктура заработает не позже, чем за этот срок. Если RTO несколько секунд, то пользователи могут даже не заметить, что система «падала». Часть решений аварийного восстановления поддерживают автоматическое переключение трафика на резервную инфраструктуру. Это позволяет нивелировать последствия аварии, сделав их незаметными для пользователей. Длительность RTO определяется потребностями бизнеса. Например, сайту с маленьким трафиком большой RTO не повредит, а для крупного онлайн-магазина 2-3 часа RTO — это серьёзные убытки.

RPO (recovery point objective) — период времени, за который могут быть утеряны данные в результате аварии. Заявленные три часа RPO означают, что после восстановления системы могут быть утеряны данные не более чем за три часа до инцидента. А при RPO в несколько секунд сохранятся почти все данные, что особенно критично для банков, крупных девелоперов и других организаций, которым нельзя терять данные даже за минуту. Величина RPO влияет на частоту создания копий IT-инфраструктуры.

Очевидно, что стоимость решения Disaster Recovery будет тем дороже, чем меньше RTO/RPO. Подбирайте модель аварийного восстановления, стоимость которой не превышает размер убытков в случае простоя. Необходим баланс между затратами на катастрофоустойчивость и убытками из-за инцидента с учётом времени восстановления бизнес-процессов и объёма утерянных данных.

Что такое Disaster Recovery Plan

Disaster Recovery Plan (DRP) — это план аварийного восстановления всех ИТ-систем после катастрофы (который в идеале никогда не должен понадобиться). Представляет собой документ с детальным описанием всех действий по устранению последствий аварии и восстановлению данных. В плане указаны роли и обязанности ответственных сотрудников, последовательность предпринимаемых ими действий.

На каком этапе развития компании требуется DRP, сказать непросто. Можно сформулировать этот критерий следующим образом. Disaster Recovery Plan требуется компании, когда:

Если потеря БД за день ничего не меняет, а ИТ-отдел месяцами может ждать комплектующих к старому серверу, DRP вряд ли потребуется. Хотя этот документ способен выручить в трудной ситуации.

Основная цель Disaster Recovery Plan: создание пошаговой инструкции с указанием времени на выполнение отдельных процедур. С помощью плана компания:

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

Целью DRP может являться:

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

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

DRaaS от Cloud4Y

Корпоративный облачный провайдер Cloud4Y предлагает три модели аварийного восстановления:

Использование облачных решений Disaster Recovery проще с точки зрения организации и управления, а также дешевле, чем построение собственной инфраструктуры. Используя услугу DRaaS от Cloud4Y, вы гарантируете себе возможность вернуться к привычному функционированию в срок, установленный договором. Проработка схем взаимодействия, подключения и маршрутизации занимает немного времени, поэтому интегрировать решения аварийного восстановления может компания любого уровня.

Источник

Данные высокой доступности

Успешный бизнес любой современной компании невозможен без надежной ИТ-инфраструктуры и непрерывной работы критически важных приложений

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

RTO, RPO и «девятки» высокой готовности

Эффективность решений, обеспечивающих высокую готовность критически важных для бизнеса приложений, обычно оценивают по трем показателям. Первый: целевое время восстановления RTO (Recovery Time Objective) – это то время, которое потребуется для восстановления нормальной работы приложений после аварии, то есть продолжительность простоя приложения, вызванного катастрофой либо неплановым сбоем. Чем меньше показатель RTO, тем раньше приложение начнет работать после ликвидации аварии и тем меньше будут убытки от его простоя. Второй показатель – это целевая точка восстановления RPO (Recovery Point Objective), определяющая, к какому состоянию приложения можно выполнить откат системы после ликвидации последствий аварий. RPO измеряется в единицах времени (минуты, часы, дни) и определяет объем последних по времени данных, которые будут безвозвратно потеряны в случае аварии. Чем эффективнее построено решение высокой доступности, тем меньше RPO и потери данных при аварии.

Наконец, сама степень готовности измеряется в процентах и показывает, сколько времени система сохраняет работоспособность в течение длительного периода эксплуатации. Чем больше показатель готовности, тем более надежно работает компьютерная система и тем меньше ее плановые и неплановые простои. Если у системы показатель доступности равен 90%, то это означает, что она простаивает 10% времени и за год ее простои составляют 36,5 дня. Большинство современных решений высокой доступности обеспечивают значение этого показателя до 99,999% (пять девяток) и 99,9999% (шесть девяток), что означает продолжительность простоев за год всего 5,26 минуты и 31,5 секунды соответственно.

Классический подход к защите от аварий

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

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

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

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

При аварии на основном дата-центре наиболее важные из приложений перезапускаются на резервном дата-центре

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

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

Новые требования к доступности приложений

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

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

Для резервного копирования без прерывания работы приложений сегодня широко применяется технология «мгновенных снимков»

Для резервного копирования без прерывания работы приложений сегодня широко применяется технология «мгновенных снимков» данных: с помощью метаданных практически мгновенно с данных приложений делается «снимок», и затем на его основе создается резервная копия «замороженных» данных. Периодичность «мгновенных снимков» определяет значение RPO. Например, если «мгновенные снимки» делаются каждый час, то RPO равен одному часу, а если четыре раза в час, то RPO равен 15 минутам. Благодаря мгновенным снимкам объем данных, которые можно потерять при аварии, существенно сокращается.

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

На протяжении последних двух лет продажи приставок резервного копирования постоянно росли, однако во втором квартале нынешнего года аналитическое агентство IDC впервые зафиксировало снижение спроса на эти системы. Как считают аналитики, сейчас многие компании, особенно малые и средние, вместо системы резервного копирования начинают применять сервисы обеспечения высокой готовности, предлагаемые провайдерами облачных вычислений. Стоит отметить, что такие сервисы не ограничиваются только резервным копированием данных в облако провайдера, а обеспечивают продолжение работы критически важных приложений в случае аварии. Для этого в публичное облако провайдера постоянно удаленно реплицируются данные приложений заказчика, а при возникновении нештатной ситуации в ИТ-инфраструктуре заказчика на виртуальных машинах облака провайдера быстро запускаются копии приложений – таким образом, простои из-за аварий сводятся к минимуму. Применение услуг облачного провайдера позволяет даже небольшим компаниям реализовать катастрофоустойчивое решение высокой готовности.

Поделитесь материалом с коллегами и друзьями

Источник

Раскрываем тайны целевых показателей восстановления

В современных организациях простои недопустимы: необходимо соответствовать требованиям и ожиданиям клиентов. Однако различные типы инцидентов могут нанести вашей компании финансовый ущерб и даже поставить под угрозу ее существование. Атаки программ-вымогателей, отключения электроэнергии, наводнения и просто человеческие ошибки — все эти события невозможно предсказать, поэтому нужно просто БЫТЬ К НИМ ГОТОВЫМИ.

Готовность означает, что необходимо разработать надежный план обеспечения непрерывности бизнес-процессов и послеаварийного восстановления (план BCDR). Этот план необходимо протестировать и убедиться, что его легко реализовать.

Два важных параметра, которые характеризуют план BCDR, — целевая точка восстановления (RPO) и целевое время восстановления (RTO). Для тех, кто еще не знаком с этими терминами, приведу их краткое определение:

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

Давайте рассмотрим целевые показатели восстановления подробнее. RPO определяет, каковы допустимые потери данных, чтобы это не повлияло на работу компании. Например, для банковской системы, работающей в режиме реального времени, потеря данных за 1 час может стать катастрофой. Чтобы вам проще было понять, что такое RPO, представьте себе, что это момент, когда вы последний раз сохраняли документ, над которым работаете. Если произойдет сбой в работе системы и все сделанные изменения пропадут, какой объем проделанной работы вы готовы безболезненно потерять?

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

Определение показателей RTO и RPO для приложений

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

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

Например, при создании плана обеспечения непрерывности бизнеса можно разделить приложения на три уровня:

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

Распределив приложения и сервисы по уровням и понимая, какие последствия ждут вас в случае тех или иных аварий, нужно найти решение, которое поможет защитить данные и работу компании. Veeam Availability Platform — комплексный набор инструментов, который позволяет достичь минимальных целевых показателей восстановления данных виртуальных, физических и облачных систем.

Обеспечение RTO и RPO на практике

Быстрое восстановление объектов приложений

Представитель отдела продаж удалил сообщение электронной почты, которое нужно срочно отправить заказчику. Microsoft Exchange относится к приложениям 2 уровня. Поскольку у ИТ-администратора запланированы задания резервного копирования в течение дня, компании нетрудно достичь показателя RPO, равного 1 часу. С помощью Veeam Explorer for Microsoft Exchange, который входит во все версии Veeam Backup & Replication, очень просто восстановить отдельное сообщение электронной почты за несколько минут и даже секунд. При этом вы экономите время и ресурсы, которые потребовались бы для остановки и восстановления целой ВМ, на которой работает сервер приложения!

Мгновенное восстановление виртуализованного сервера непосредственно из резервной копии

Представим себе банк, у которого есть некоторое количество банкоматов. Банкоматы очень важны для работы банка (2 уровень), их недоступность в течение нескольких часов повлияет на проводимые банком операции, но не остановит их полностью. С помощью Veeam Backup & Replication и функции мгновенного восстановления ВМ можно сразу же перезапустить виртуализованный сервер банкоматов из дедуплицированного и сжатого файла резервной копии Veeam. Это позволяет достичь показателя RTO, равного нескольким минутам! Более того, используя функции миграции гипервизора и Veeam Quick Migration, можно легко перенести работающую ВМ с резервной площадки в производственную, завершив процесс восстановления.

Полное переключение на резервную площадку

Работы с электросетью привели к полному отключению питания и остановке работы одного из ваших дата-центров. В результате все критически важные приложения 1 уровня оказались недоступны. Допустим, вы делаете реплики всех критически важных ВМ на удаленную площадку каждые 10 минут, используя решение Veeam. Таким образом, вам несложно достичь требуемого показателя RPO в несколько минут. Что касается RTO, Veeam обеспечивает возможность быстрого восстановления в случае крупных аварий: переключение на реплику в один клик, упрощенное обратное переключение, автоматическое переназначение IP для восстановления сети на резервной площадке и полноценное послеаварийное восстановление с использованием облака.

Защита персональных компьютеров

Помимо виртуальной инфраструктуры, Veeam позволяет защитить и физические устройства, в том числе предлагает возможности резервного копирования и восстановления данных персональных компьютеров и ноутбуков. С помощью Veeam Agent for Microsoft Windows можно восстановить файлы с аварийного загрузочного диска на компьютер под управлением Windows или даже запустить образ ПК из резервной копии как виртуальную машину, чтобы обеспечить низкий RPO.

Кроме того, с помощью Veeam Agent for Linux можно защитить системы Linux как на локальной площадке, так и в публичном облаке.

Заключение

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

Источник