что такое rto и rpo
Олонцев Сергей
Блог об обработке и анализе данных
Что такое 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 для них может быть критичен, т.к. в случае недоступности, несколько человек не смогут работать какое-то время. В то же время не надо переусердствовать, обеспечивая очень маленький показатель, т.к. затраты на его поддержку могут легко превысить оплату труда простаивающих специалистов. В то же время для основных баз данных эти показатели будут играть большую роль, т.к. от них будет зависеть доход и репутация компании.
Что такое 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: облака и аварийное восстановление IT-инфраструктуры
Чем быстрее информационные системы возобновят работу, тем меньше последствий. Поэтому компании создают катастрофоустойчивые инфраструктуры, развертывая резервные мощности на физических серверах или в облаках.
По прогнозам компании Grand View Research, к 2025 году объем мирового рынка решений для аварийного восстановления достигнет 26,23 млрд долларов США. Спрос растет из-за того, что IT-системы становятся сложнее, поэтому увеличивается число случаев отказа инфраструктуры вследствие внешних и внутренних угроз.
Самый быстрый рост ожидается в сегменте малого и среднего бизнеса — такие компании будут активно внедрять облачные решения Disaster Recovery, которые стали доступнее. Мы расскажем, как работают сервисы восстановления IT-инфраструктуры в облаках и как сделать работу бизнеса непрерывной.
Что такое Disaster Recovery
Disaster Recovery (DR) или катастрофоустойчивость — способность IT-инфраструктуры восстановиться после катастрофы.
Это часть планирования непрерывности бизнеса (Business Continuity, ВС), в которую входят процессы, методы и оборудование для того, чтобы критичные функции бизнеса выполнялись бесперебойно. То есть компания должна продолжать работать, несмотря на стихийные бедствия, атаки, внутренние сбои, или хотя бы быстро восстановить работу и не потерять важные данные.
Для этого основные системы хранения и обработки данных резервируют на удаленной площадке — физическом оборудовании или через облачных провайдеров. Если ЦОД компании распределен по нескольким площадкам, нужно организовать каналы связи между ними, составить план резервного копирования и восстановления систем.
Экономика Disaster Recovery: время восстановления и точка восстановления
Есть два ключевых параметра Disaster Recovery, которые влияют на стоимость катастрофоустойчивой системы, и ущерб для бизнеса в случае сбоя.
Чем меньше RTO и RPO, тем дороже решение: систему, которая моментально восстанавливается после сбоя и не теряет данные, организовать сложнее.
Зависимость стоимости от величины RTO/RPO
Чтобы выбрать подходящую модель аварийного восстановления, нужно посчитать, какие убытки понесет бизнес в результате простоя. Потом подобрать такие RTO и RPO, когда вероятные потери перевешивают затраты на организацию Disaster Recovery. То есть найти баланс между расходами на катастрофоустойчивость и убытками компании в случае катастрофы с учетом времени восстановления бизнес-процессов и объема потери данных.
Выбор оптимального решения
Что лучше для Disaster Recovery: резервный ЦОД или облако
При классическом подходе к аварийному восстановлению инфраструктуру дублируют в резервный дата-центр: организуют второй ЦОД, который либо полностью дублирует рабочий, либо берет на себя создание и хранение копий данных, критичных для бизнеса.
Вместо того, чтобы создавать собственную резервную площадку, компания может перейти на Cloud DRaaS — облачные сервисы для быстрого аварийного восстановления IT-инфраструктуры. Disaster Recovery в этом случае предоставляется облачным провайдером как услуга.
Это дешевле и проще, чем строить вторую IT-инфраструктуру. Сравним Cloud DRaaS с классическим вариантом — собственным резервным ЦОД,
Организация
Резервный ЦОД. Его сложно организовать. Дублирующая инфраструктура большую часть времени простаивает, однако, нужно закупить или арендовать оборудование, настроить, обслуживать, ремонтировать и обновлять его. Нужен обслуживающий персонал, важно настроить репликации, переключение доменов и DNS-записей, чтобы система заработала в случае аварии. Не всегда можно совместить с нужными платформами.
Cloud DRaaS. Внедрить просто. Можно настроить облачную инфраструктуру силами собственных специалистов или заказать консалтинг у провайдера. Не нужно обслуживать резервную систему и нанимать персонал. Облачные решения интегрируются с большинством популярных платформ, они могут работать с разным оборудованием и приложениями.
Стоимость
Резервный ЦОД. Высокая стоимость. Нужны серьезные вложения для создания и обслуживания дублирующей инфраструктуры, электропитания ЦОД, ремонта и замены оборудования, оплаты услуг персонала, покупки лицензий для серверов и хранилищ, обеспечения безопасности.
Cloud DRaaS. Стоимость зависит от модели, которую использует компания, есть разные решения, отличающиеся по цене. Однако облачные технологии всегда дешевле собственного резервного ЦОД, так как не надо платить за машинные залы, их обслуживание и работу инженеров. При размещении инфраструктуры в облаке часто используют модель Pay-As-You-Go, когда оплата идет за фактически использованные ресурсы — если система не используется, бизнес платит меньше.
Три модели облачных решений Disaster Recovery
В зависимости от масштаба бизнеса и желаемого RTO/RPO можно выбрать три варианта аварийного восстановления в облаке.
Решение для резервного копирования и восстановления (Backup & Restore Solution). Информация копируется и восстанавливается по заданному расписанию, например, раз в сутки или несколько часов. Скопированная IT-инфраструктура помещается в надежное облачное хранилище, например, облачное решение для «горячего хранения» данных Hotbox. Когда наступает катастрофа, клиент восстанавливает информационные системы из облака. Если катастрофа происходит между копированиями, то данные, которые не были сохранены, потеряются.
RTO и RPO у этого облачного решения самые высокие — от 2-3 часов, зато оно экономично и подходит малому бизнесу, которому не критична непрерывная работа инфраструктуры.
Решение можно сравнить с поломкой автомобиля во время поездки. Например, лопнула шина или порвался ремень генератора, а у водителя нет запасных. Теперь нужно ждать эвакуатор, тратить время на ремонт в автосервисе или шиномонтаж. Чем больше повреждения, тем дольше автомобиль никуда не поедет.
Копии инфраструктуры делают периодически и хранят в облачном хранилище
Такой вариант резервного копирования и восстановления можно реализовать и без облака: обычно данные копируют на ленту и хранят в том же ЦОДе, что не станет страховкой от пожара. Кроме этого, в таких случаях восстановление системы может занять несколько дней. Облачные хранилища вроде Hotbox ускоряют процесс, так как позволяют оперативно вытащить данные. Поэтому можно вернуть систему к работе за несколько часов.
Решение для быстрого восстановления (Quick Recovery Solution). Информационная система содержится в облаке в минимально рабочей конфигурации. Рабочая и резервная базы данных непрерывно синхронизируются в инкрементальном режиме — то есть сначала делают полную копию системы, а потом копируют только новую информацию. В облаке содержатся готовые к запуску шаблоны виртуальных машин и приложений. После сбоя IT-инфраструктуру можно запустить одной кнопкой.
После аварии время нужно только на запуск приложений, в облаке хранится актуальная копия информационной системы, поэтому данные не теряются. Этот вариант дороже первого, так как он подразумевает платное агентское решение, клиент платит за использование ресурсов и образов, организацию непрерывного копирования и систему восстановления «по одной кнопке». Зато RTO/RPO решения меньше: до получаса/несколько минут. Оно универсально и подходит большинству компаний, в том числе интернет-магазинам, где важно не терять данные о заказах и транзакциях. Кроме того, хранение инфраструктуры в «спящем режиме» дешевле, чем организовать и обслуживать вторую боевую инфраструктуру, находящуюся в рабочем состоянии.
Если продолжить аналогию со сломанным автомобилем, то оно похоже на ситуацию, когда поломка случилась, но под рукой все, чтобы ее исправить. Не надо вызывать эвакуатор и ехать в сервис, однако, нужно потратить немного времени на ремонт.
В облаке содержится актуальная копия рабочей IT-инфраструктуры
Синхронность записи данных зависит от системы, есть два варианта с учетом нужной точки восстановления (RPO):
Переключение трафика на резервную инфраструктуру может быть ручным или автоматическим. В таком варианте простоя после аварии практически не будет, но решение подходит не для всех IT-инфраструктур.
Параллельная активная инфраструктура подходит компаниям, где работа информационных систем критична для бизнеса: не должно быть сбоев, потеря данных недопустима. Например, финансовые компании и банки, госуслуги, крупные IT-компании. В этом решении RTO/RPO минимальны: несколько минут/несколько секунд. Оно самое дорогое из облачных вариантов Disaster Recovery, но его стоимость меньше, чем стоимость резервного дата-центра.
Еще одно преимущество параллельной инфраструктуры: возможность эластичного масштабирования — если нужны дополнительные вычислительные ресурсы или память, они выделяются динамически в широких пределах.
Решение можно сравнить с электроснабжением операционных. Всегда есть резервный источник энергии: если отключат электричество, то аппаратура, поддерживающая жизнь пациента, не выключится, произойдет переключение на автономную электростанцию.
При отключении основной инфраструктуры трафик можно переключить на резервную
Есть похожие решения, в которых облачная инфраструктура не стоит «в резерве», а также ставится под нагрузку и представляет собой «второе плечо» инфраструктуры. При этом выполняется балансировка нагрузки с равномерным распределением запросов между инфраструктурами. Строго говоря, это решение не относится к классу DRS, но позволяет на сходной с DRS архитектуре организовать высокодоступный геораспределенный сервис (high availability).
Два плеча инфраструктуры с балансировкой нагрузки
Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA
Сегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных и\или аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:
Начнем «от печки», то есть с прямой линии вдоль оси времени, где:
Ясно, что все системы в компании работают не просто так, а для различных нужд/целей. Сама же компания зарабатывает (и тратит) деньги. В случае сбоя системы компания, очевидно, деньги теряет. Показатели RTO и RPO – то, что говорит о приемлемых размерах этих потерь.
Из такого графика уже видно, что стоимость простоя сервиса растет со временем: чем дольше не работает система, тем больше денег теряет компания.
Тоже самое и со стоимостью потерь данных: чем больше мы их (в исторической перспективе) теряем, тем дороже такая потеря обойдется компании. И да, эти графики в живой природе не симметричны.
Как правило, эти стоимости меняются не линейно, что отражено на картинке. Чаще всего наступает момент, когда стоимость потери начинает резко возрастать – отсюда и те самые печальные истории, когда компании теряли так много от сбоя системы, что некоторые даже не смогли вернуться в бизнес.
Чтобы защититься от таких проблем, необходимо внедрить систему, которая будет обеспечивать защиту от потерь данных и восстановление после сбоев. Такие системы имеют свои стоимости, и, значит, их тоже можно отразить на графике (нарисуем их синим):
Как видно из графика, чем меньше показатели RPO и RTO при потере данных, чем меньшее время простоя сервиса обеспечивает решение по защите, тем дороже такая защита стоит.
Определим точки безубыточности решения по защите
И тут мы наблюдаем пересечение кривых на графике – я отметил эти точки зелеными стрелками. Это так называемые точки безубыточности для системы защиты и для защищаемой информационной системы. Отдаляясь от данной точки, мы получаем дорогую систему защиты, стоимость которой превышает стоимость потери/простоя, либо наоборот – дешевую систему защиты, но не обеспечивающую приемлемый уровень потерь.
Как кажется, вывод напрашивается сам собой: именно ориентируясь на точки безубыточности, и надо подбирать системы, которые обеспечат нам необходимую защиту.
На самом деле, если мы построим такие графики, ориентируясь на данные из реальной жизни, то получим несколько иную картину. В частности, график стоимости решения по защите будет иметь вид не сплошной линии, а множества точек. Различные защитные решения не выстраиваются вплотную друг за другом вдоль графика, а представляют собой отдельные точки, ведь каждое имеет свои «координаты»: стоимость (обозначенная вендором-производителем данного решения) и время обеспечения этим решением соответствующих потерь данных (RPO) и скорости восстановления работоспособности (RTO).
К тому же, как правило, ищется решение по защите не одной конкретной информационной системы (ИС), а группы (или вообще всех) инфосистем компании (то есть всей инфраструктуры). При этом каждое такое решение, скорее всего, будет иметь свои графики зависимостей стоимости простоя/потери данных от времени.
Получается, что наши точки безубыточности – уже не точки, а области:
Если мы рассмотрим нашу инфраструктуру более пристально и начнем строить графики для каждой ИС, то мы увидим интересную тенденцию — системы группируются со схожими. Об этом ниже.
Рассматриваем различные классы решений
Обратите внимание, до сего момента я говорил про «защиту», но не оговаривал, что это за защита конкретно: резервное копирование, кластер, какие-то еще виды защиты? Тут стоит сказать, что системы защиты бывают разные, и их можно классифицировать.
На схеме ниже видно, какой примерно класс решения в зависимости от целевых RTO/RPO рекомендуется выбирать.
Конечно, на картинке всё изображено достаточно схематично. На самом деле нет четких границ между типами решений, как и точных значений в виде точек.
Например, сейчас многие решения по резервному копированию используют технологию запуска сервиса из резервной копии. Время обеспечения доступности при использовании такой технологии — в среднем
2-5 минут на одну ВМ. И такие показатели находятся в рамках RTO для реплик или даже кластеров.
Немного о кластерах
Кластеры, как и DR-решения (и вообще практически все решения по защите от потерь данных или восстановлению работоспособности) имеют свои значения по скорости восстановления данных и объемам данных, которые теряются. Потому они также связаны со своими показателями RTO/RPO.
Говоря, например, про HA-кластер (HA – High Availability), имеем в виду, что его RTO равно времени переключения. Допустим, MSCS для двух нод переключает СУБД за 30 секунд. Значит, целевое RTO, которое можно обеспечить этим видом кластера — от 30 секунд.
А если рассмотреть VMware HA, которое отработает за 2 минуты (с учетом старта виртуальной машины, ее гостевой ОС и приложений)? Значит, такое решение подходит для приложений с целевым значением RTO от 2 минут.
Где же потери для HA-кластера (и соответственно, обеспечение RPO), спросите вы? Когда сервис поднимается, есть вероятность небольших потерь данных. Например, если СУБД проверит состояние базы данных и может откатить своё состояние на некорректно проведенную транзакцию. Или если файловая система вернется к некорректно сохраненной версии файла, и т.д., и т.п.
Вывод: не всегда стоит строить одинаковые решения одно поверх другого, например, HA над HA. Это только излишне усложнит инфраструктуру, усложнит (и удорожает) поддержку работы таких систем.
К предыдущим примерам двух HA. Определите, какое реальное значение RTO необходимо обеспечить для приложения? Для значений больше 2 минут нет смысла стоить еще и HA-кластер для сервисов внутри ВМ.
Обратим внимание еще на ряд факторов:
К примеру, резервное копирование почтового сервера не исключает, но дополняет использование кластера HA для почтовых серверов. Кластер защищает от выхода из строя физического сервера и обеспечивает быстрое переключение на резервный сервер. Но кластер не защищает от потери данных (нежелательного удаленных данных, невозможности запуска ВМ после сбоя оборудования и т.п.). Для этого необходимо применение резервного копирования.
Что при этом дает совместное использование VMware vSphere HA? Быстрое восстановление уровня защиты. Если просто выключился один сервер с одной нодой MS Exchange, то вначале отработает DAG, переключив сервисы на другую ноду, а затем HA VMware загрузит сбойный сервер на другом плече своего кластера. И система готова к работе. (Хотя в этом примере я бы рассматривал применение виртуализации не только для одной функции только кластера, но и для всех остальных преимуществ самой платформы).
Говорим и пишем правильно! Или еще раз про RTO и RPO
Хочу сделать на этом акцент, поскольку я сам периодически совершаю ошибку, потому и остерегаю от этого вас:
RTO ≠ скорость восстановления!
RPO ≠ количество потерянных данных!
RTO и RPO – это целевые значения для информационных систем (ИС), максимальные рамки, в которые мы должны уложиться. И эти целевые значения нам, ИТ-специалистам, сообщает бизнес, точнее, бизнес-владельцы соответствующей ИС, но не наоборот.
То есть:
Нельзя сказать, что RTO функции Instant Recovery – 2 минуты.
Нельзя считать, что резервное копирование раз в сутки и есть RPO 24 часа.
Всё идет в обратную сторону, то есть от бизнеса, и конкретно для RTO будет озвучиваться так:
Для определенного сервиса, в случае сбоя обслуживающей этот сервис системы, необходимо обеспечить восстановление, не допустив простоя в работе этого сервиса более 5 минут (RTO – 5 минут). Значит, подойдет решение, которое позволит сделать систему доступной за срок менее 5 минут.
Для базы данных, в случае сбоя СУБД, нужно обеспечить восстановление с допустимой потерей данных сроком не более 24 часов от момента сбоя. Значит, подойдет решение, которое обеспечит гарантированное восстановление базы из точек восстановления, производимых чаще, чем 1 раз в сутки. При этом отмечу, что резервное копирование раз в час, создающее 24 точки восстановления, дает больше гарантий восстановления, чем копирование раз в сутки, делающее только 1 точку.
А вот и практический пример
Казалось бы, можно рассуждать так:
«Применение функции Instant Recovery обеспечит технический процесс восстановления в 2 минуты. »
Но! При этом надо понимать еще несколько моментов:
Поэтому рассуждаем дальше:
«У меня настроен мониторинг для этого сервиса, и оповещение сработает и будет замечено за минуту-две (телефон с полученной СМС надо из кармана достать, или почтовый клиент с новым письмом надо открыть). Я сяду за компьютер, пингану сервис, попытаюсь открыть на нем консоль, посмотрю, что там с гипервизором и железом. Проведу первичную реанимацию (попробую перегрузить машину). На все это я потрачу порядка 15 минут. Если не помогут действия по быстрой реанимации — восстановлюсь из резервной копии. Но так как копироваться из бэкапа данные будут еще минут 15-20, то я воспользуюсь Instant VM Recovery за 2 минуты, а затем запущу онлайн перенос данных машины в продакшен.»
Как видим, в 5 минут мы вряд ли укладываемся.
Теперь подумаем, возможно, нужен HA-кластер со временем восстановления 2 минуты? Но и он не обеспечит нам защиту от всех типов сбоев: рестарт машины в BSoD вполне вероятен, диск ВМ — тоже точка отказа, и т.п. Следовательно нужна дополнительная защита. Значит, продолжаем наши рассуждения:
«В случае кластера я восстановлюсь за 2 минуты. А в дополнение я потрачу, как уже прикинул(а), 15+2 минут при восстановлении из резервной копии, всего 2+15+2=19 минут, и 11 минут ещё остаются в запасе.»
В итоге, ваш ответ бизнес-владельцу ИС будет таким:
«ОК. Я обеспечу RTO в 30 минут. Я включу этот сервис в кластер — для обеспечения 5 минутного RTO, и настрою резервное копирование — для защиты от сбоев с более серьёзными последствиями.»
Очень важно! Самый главный совет: после того, как вы согласовали с владельцем ИС конкретные целевые показатели, договорились – обязательно фиксируйте ваши договоренности с ним в письменном виде, подписывайте с ним соглашение об уровне обслуживания (SLA).
Почему мы называем это «концепцией доступности»?
Заметили, что я пишу постоянно «восстановление данных и восстановление работоспособности сервиса»? Чаще всего пишу вместе, в одном предложении. Это две связанные между собой вещи, которые почти всегда не могу жить друг без друга.
Мы восстановили работу сервиса, но при этом потеряли все его данные – это неприемлемо. Мы восстановили БД, но СУБД не запускается, прочитать данные не могут – это неприемлемо. Именно поэтому мы говорим о доступности и данных, и сервисов. Важны и RPO, и RTO – в совокупности они обеспечивают доступность и того, и другого.
Через 15 минут после сбоя восстановлен доступ к сервису с данными за весь предыдущий период работы (до 1 часа включительно) – это всё про общую доступность.
Вот такой вот дуализм 😉 Вместе дуальная пара RTO и RPO является важным показателем в том самом соглашении об уровне обслуживания (Service Level Agreement, или SLA) для конкретной ИС в части обеспечения доступности её сервисов и данных в случае возникновения сбоя. А подписывается соответствующее соглашение, как я говорил выше, между владельцем ИС (заказчиком услуги), и вами, ИТ-отделом (поставщиком услуги).