BCP и DRP. Разница иногда не очевидна
Привет, хабр! Это скорее не статья-разъяснение, а статья-рассуждение о непрерывности и самая мякотка, надеюсь, будет в комментариях.
В силу того, что business continuity превратился в модный тренд, что-то вроде нанотехнологий, инноваций и импортозамещения, самое время определиться, что такое BCP и что такое DRP, в чем их разница и почему BCP и DRP как в том анекдоте «не муж и жена, а четыре совершенно разных человека».
BCP (business continuity plan) – план обеспечения непрерывности бизнеса. Содержит детальный план, что необходимо сделать для восстановления бизнес процессов.
DRP (disaster recovery plan) – план восстановления после катастрофы. Содержит детальный план по восстановлению инфраструктуры. Обычно имеется ввиду ИТ инфраструктура, но это могут быть самые разные механизмы, автотранспорт и здания.
Оба плана будут использоваться сразу после возникновения кризисной ситуации или катастрофы. Оба плана содержат набор инструкций и описание людей, которые эти инструкции должны выполнить. Оба плана должны периодически тестироваться, чтобы быть уверенным, что план жизнеспособен. Оба плана должны быть разработаны исходя из требований бизнеса*. Пожалуй, на этом сходство заканчивается и начинаются различия.
DRP – это план про восстановление. Если сгорел склад, то есть запасной склад на такой случай. Если в ЦОД пришли маски-шоу, есть резервный ЦОД. Если сломался автомобиль – есть запасные части для ремонта. Или резервный автомобиль. В зависимости от требований бизнеса, о которых мы поговорим в другой статье.
BCP – это план про непрерывность бизнеса, а точнее, конкретного бизнес процесса. BCP позволяет продолжить бизнес процесс после катастрофы или кризисной ситуации так быстро, как это необходимо для бизнеса.
При выходе из строя офисного здания DRP будет описывать как оперативно запустить новое офисное здание. BCP будет описывать, как организовать удаленную работу сотрудников. В случае, если удаленная работа невозможна, BCP будет включать в себя DRP, но не наоборот. И где-то в этот момент возникнет ощущение, что это одно и то же, но это не так.
В случае выхода из строя ЦОД, например, телекоммуникационной компании, BCP план будет описывать процесс переезда в резервный ЦОД и соответствующие коммуникации. DRP будет описывать переезд каждой системы. Фактически, в этом случае BCP план включает в себя много DRP планов.
BCP создается и тестируется совместно с представителями бизнеса. DRP создается и тестируется внутри ИТ подразделения.
Очень интересует мнение практиков, которые забороли путаницу в терминологии в непрерывности.
— * — требования бизнеса – это именно требования от бизнеса, а не размышления внутри ИТ департамента, как могли бы выглядеть бизнес требования.
Disaster Recovery в облако: кому нужно и как его обеспечить
Рассказываем, кому стоит позаботиться об аварийном восстановлении инфраструктуры и какими способами можно реализовать DR.
Эта инструкция — часть курса «Начинаем работу с VMware».
Смотреть весь курс
Рассказываем, кому стоит позаботиться об аварийном восстановлении инфраструктуры и какими способами можно реализовать DR.
Что такое Disaster Recovery
Disaster Recovery, или аварийное восстановление, — это комплекс инструментов, обеспечивающих быстрое восстановление инфраструктуры, данных, работы всех систем в случае критических сбоев.
Причины сбоев могут быть как рядовыми — отключение электричества в районе размещения оборудования и проблемы с сетью, так и чрезвычайными. Например, DR готовит сервис к землетрясениям, пожарам, наводнениям. Любым событиям, которые серьезно навредят дата-центру с инфраструктурой компании, вплоть до полного уничтожения.
По сути, Disaster Recovery подразумевает резервную площадку для восстановления полного «клона» или части инфраструктуры компании. Чтобы отвечать требованиям DR, площадка должна:
→ быть географически удалена от основной (в таком случае ЧС, произошедшая в первом дата-центре, не затронет второй),
→ иметь хорошую сетевую связность с местом размещения инфраструктуры (чем выше пропускная способность канала, тем быстрее данные будут «добираться» до резервной площадки).
Способы организации DR
Disaster Recovery — концепция, которую можно реализовать разными способами.
Сделать самостоятельно на своей инфраструктуре (on-premises)
В таком случае не избежать капитальных затрат (всю инфраструктуру нужно будет умножать на два) и простаивания закупленного оборудования. Также Disaster Recovery собственными силами — это сложный проект, требующий серьезных компетенций сотрудников. Поэтому к CAPEX добавим еще и потребность в высококвалифицированных DevOps-, NetOps-специалистах и архитекторах инфраструктуры.
Построить Disaster Recovery на арендованных физических серверах
Сделать это можно за счет полного дубля инфраструктуры в концепции георепликации (размещения в другой географической точке). Такая реализация, впрочем, лишена гибкости — организация DR, как и внесение изменений в инфраструктуру, займет больше времени. Гибкости нет и в оплате резервной инфраструктуры — аренда минимум на месяц.
Развернуть Disaster Recovery в облако
На данный момент это наиболее оптимальный и распространенный сценарий в практике компаний. Облачную инфраструктуру легче создавать и масштабировать. Если компания использует Terraform или иные инструменты IaC-подхода, развернуть резервную площадку можно за несколько минут.
Также очевидным преимуществом является модель оплаты pay-as-you-go — оплата за потребленные ресурсы, которую поддерживают облака. Если компании не нужна активная репликация инфраструктуры 24/7/365, она может экономить на ресурсах.
Disaster Recovery as a service
В качестве альтернативы самостоятельному созданию резервной площадки в облаке можно рассмотреть готовый сервис по DR. Помимо перехода на OPEX-модель, он облегчит такие задачи, как поиск и — самое главное — настройка инфраструктуры в концепции Disaster Recovery. Также клиент, как правило, получает дополнительные «плюшки» в виде консультации экспертов и SLA. У Selectel в этом списке также защита от DDoS-атак и соответствие 152-ФЗ.
Аварийное восстановление в облако
Пользуйтесь вычислительными ресурсами в облаке на базе VMware в Selectel в случае аварии на вашей основной площадке.
Характеристики Disaster Recovery
Основные характеристики, своеобразные метрики аварийного восстановления — это RPO (Recovery Point Objective) и RTO (Recovery Time Objective). В зависимости от их значений компания выбирает техническое решение, которое будет в основе Disaster Recovery.
RTO
Определяет максимальное время простоя, которое может позволить себе бизнес. Чем меньше этот показатель, тем незаметнее для конечного пользователя пройдет переключение на резервную площадку. Допустим, RTO установлен на 15 минут. В таком случае сервис начнет работать в штатном режиме не позже этого времени. В идеале — раньше.
Чем меньше RTO, тем больше это будет стоить бизнесу. Поскольку в реализации будут использовать более технологичные (и дорогие) решения, а резервную инфраструктуру нужно будет держать в состоянии active-active.
RPO
Определяет максимальный объем данных, который может позволить себе потерять компания в случае аварии и простоя. Чем меньше устанавливается показатель, тем чаще компания делает резервное копирование. Так, если RPO составляет 1 минуту, значит, резервная копия будет создаваться каждую минуту.
Все это также влияет на стоимость решения. Поэтому нет «золотых стандартов» RPO и RTO — каждая компания определяет эти показатели индивидуально. Обычно это консенсус между тем, что потеряет компания из-за простоя, и тем, что она потратит на достижение нужных метрик RPO и RTO.
Есть компании — например, крупные банки, чьи потенциальные репутационные и финансовые издержки в случае даунтайма всегда покроют затраты на организацию Disaster Recovery на высшем уровне. А есть бизнес, которому выгоднее «полежать», чем увеличивать чек за инфраструктуру.
Определение показателей RTO и RPO – это часть плана аварийного восстановления IT-систем (Disaster Recovery Plan, DRP). В идеале такой план должен быть у любой компании — вне зависимости от масштаба и специфики бизнеса. О нем мы еще напишем подробнее.
Всем ли нужен Disaster Recovery?
Аварийное восстановление нужно не всем. Оно необходимо компаниям, где репутационные и финансовые потери при простое сервисов недопустимы. Рассмотрим несколько примеров.
Крупный банк
На основной площадке случилась авария — клиенты не могут зайти в мобильное приложение и личные кабинеты. Сервис недоступен 30 минут: физлица не могут оплачивать покупки и переводить деньги близким, юрлица не могут совершать необходимые транзакции. При восстановлении системы оказалось, что данные о транзакциях за последний час потерян. Менеджеры хватаются за головы — клиенты уходят в другой банк.
Служба доставки еды
В районе ЦОД, где расположена инфраструктура сервиса, случился шатдаун. Пользователи не могут заказать продукты домой (допустим, сервис неудачно выбрал провайдера без ИБП и ДГУ). За час, ушедший на восстановление систем, несколько сотен клиентов не смогли выполнить свои заказы — финансовые убытки оцениваются в несколько сотен тысяч. Половина этих клиентов заказали доставку у конкурентов. Добила ситуацию потеря части данных о заказах клиентов — несколько десятков людей ждали свою пиццу в течение 4 часов. Еще один денежный транш ушел на сохранение лояльности клиентов.
В обоих случаях затраты на Disaster Recovery окупятся с лихвой. Компаниям, которым отзываются описанные кейсы, стоит задуматься о DR. В остальных случаях будет достаточно бэкапов. В отличие от аварийного восстановления резервные копии — безусловный мастхэв для компаний любого размера.
Чем отличаются бэкапы от Disaster Recovery?
В случае бэкапов вы делаете резервную копию данных. Если случается локальная авария, систему можно будет развернуть из бэкапа на новой инфраструктуре. В облаке это можно сделать достаточно быстро, если у вас один-два сервера. Если речь о восстановлении всей инфраструктуры — конфигураций серверов, сетевой обвязки, БД и т.д., восстановление займет непозволительные часы. Резервное копирование данных — обязательная часть Disaster Recovery, но это лишь часть.
Гайд по репликации инфраструктуры в облако
Итак, вы задумались об организации аварийного восстановления. С чего начать?
- Определите, какие проекты или сервисы нужно «продублировать» в облако. Клонировать инфраструктуру полностью не обязательно. Так, тестовое окружение или внутренние сервисы, некритичные для бизнеса, можно исключить из этого списка.
- Выберите провайдера. При выборе отталкивайтесь от того, где расположены дата-центры, на какие ресурсы в облаке вы можете рассчитывать, какая пропускная способность каналов связи и производительность инфраструктуры. Нелишним будет уточнить, есть ли тестовый период решений, сравнить цены на рынке, выяснить, подписывает ли провайдер соглашение об уровне услуг (SLA) с клиентом.
- Выберите техническое решение. Как правило, провайдер предлагает несколько решений по организации Disaster Recovery с разными значениями RTO и RPO. Ознакомьтесь со всеми и выберите наиболее подходящее. Если сомневаетесь в выборе, хороший провайдер всегда подскажет решение.
- Сформируйте план аварийного восстановления (DRP), если у вас его еще нет. Базово в нем должен быть прописан алгоритм действий в случае аварии: кому звонить, кого подключать, как распределяется ответственность за восстановление систем. Главная задача плана — исключить паническое накопление ошибок и неправильных действий в случае ЧС. В крупных компаниях в DRP прописывают даже порядок коммуникации со СМИ, чтобы отработать потенциальные риски.
- Преднастройте сетевую инфраструктуру, NAT, межсетевые экраны. Инфраструктура — это не только набор серверов. Если вы быстро восстановили сервер БД, но при этом не связали его с веб-сервером, полноценно приложение работать не будет. Настройка сети требует много времени, поэтому откладывает ее на последний момент не стоит. К слову, часто в готовых DR-сервисах это можно настроить в интерфейсе.
- Настройте техническое решение и DR для сервисов. Вне зависимости от выбранного решения (если это, конечно, не полная настройка DR под ключ) систему придется настраивать. Так, например, если вы выбрали Cloud Director Availability, нужно будет обеспечить управление инфраструктурой через плагин vSphere или Cloud Director. Опасаться этого пункта, впрочем, не нужно: если вы выбрали правильного провайдера, подробные инструкции по настройке вы найдете в его базе знаний.
- Протестируйте работоспособность системы. Просто настроить и забыть — не вариант. Настроенный Disaster Recovery нужно протестировать, то есть искусственно устроить отказ инфраструктуры на основной площадке и реализовать тот самый план Б. Это ваш шанс найти слабые места в DRP и засечь время восстановления. Действительно ли оно соответствует желаемым метрикам RPO и RTO? В Selectel протестировать настроенную систему для решения можно бесплатно.
- Установите периодичность тестирования DR. Рекомендуется повторять предыдущий пункт гайда хотя бы раз в два месяца, чтобы удостовериться в корректности восстановления в облако.
Технические решения для DR
Существует несколько технических решений, которые позволяют организовать аварийное восстановление в облако. Наиболее распространенные реализуются через Cloud Director Availability и Veeam Cloud Connect Replication (в связке с Veeam Backup & Replication). Эти решения предлагает и Selectel.
Cloud Director Availability
Это решение может быть использовано как для безопасной миграции в облако, так и для аварийного восстановления нагрузок между облаками VMware в облаке Selectel или из частного облака клиента.
Особенности
- минимальный RPO – 5 минут,
- можно управлять и основной инфраструктурой, и репликациями в единой панели управления Cloud Director,
- при настройке сетей не нужно открывать дополнительные порты (достаточно порта TCP 443),
- есть подробная документация по настройке и видеодемонстрация настройки.
Кому подойдет
Решение более простое в настройке и не требует серьезной экспертизы. В среднем, развертывание системы занимает около 15 минут, но клиент должен иметь инфраструктуру в облаке VMware. Это может быть частное облако на собственной инфраструктуре, частное облако у другого провайдера, частное облако в Selectel. Подойдет компаниям, которые не хотят переплачивать за дополнительные лицензии.
Veeam Cloud Connect
Этот облачный репозиторий не только позволяет хранить бэкапы в облаке, но и восстанавливать данные в облако в случае критических сбоев.
Особенности
- минимальный PRO – 1 минута,
- необходимо иметь Veeam Backup & Replication (бесплатный Community Edition не подойдет, минимум — версия Standard, для сжатия трафика — Enterprise),
- тестировать настроенную систему придется вручную, автоматическое тестирование не поддерживается.
Кому подойдет
Решение больше подходит компаниям, которые уже использует платное ПО от Veeam в работе.
Если у вас остались вопросы по реализации Disaster Recovery для своего бизнеса, пишите на sales@selectel.ru.
Инструменты Veeam для резервного копирования — в чем разница?
Знакомство с публичным облаком на базе VMware в Selectel
Зарегистрируйтесь в панели управления
И уже через пару минут сможете арендовать сервер, развернуть базы данных или обеспечить быструю доставку контента.
План аварийного восстановления (DR)
Резервированная инфраструктура сводит риск отказа IT-систем к минимуму, однако сбои и аварии нельзя исключить полностью. Форс-мажоры сложно предсказать и предупредить, но когда авария уже случилась, необходимо как можно быстрее восстановить систему и минимизировать простой критичных сервисов. Для этого и существует Disaster Recovery Plan (DRP) или план аварийного восстановления.
Что такое план аварийного восстановления и зачем он нужен
Disaster Recovery Plan — документ с последовательным описанием согласованных процедур, ролей и обязанностей персонала в аварийной ситуации.
В первую очередь, план определяет критически важные объекты IT-инфраструктуры и степень риска при отказе каждого из них. Уровень риска оценивается по методу BIA (business impact analysis). Это не единственный, но один из самых доступных методов анализа для ранжирования факторов риска и определения степени влияния события на ключевые бизнес-процессы. По методу BIA удобно определять взаимосвязь между процессами, устанавливать максимально допустимый период их простоя и рассчитывать целевое время для восстановления.
Также в DR-плане обязательно учитываются ресурсы (персонал и объекты инфраструктуры), задействованные в восстановлении. Ранжируется очередность устранения последствий. Определяются технологии Disaster Recovery и данные, чью безопасность нужно обеспечить в первую очередь.
- С практической точки зрения план аварийного восстановления (DR) решает четыре задачи бизнеса:
- Сохранить доступность критичных сервисов при сбое на основной площадке.
- Как можно быстрее восстановить стабильную работу IT-инфраструктуры, чтобы минимизировать убытки.
- Добиться прозрачности и предсказуемости процесса восстановления, сократив влияние человеческого фактора.
- Исключить или свести к минимуму потери важных данных.
Как определить, нужен ли компании план аварийного восстановления
Говорить, что любому бизнесу нужен план аварийного восстановления — не совсем верно. Disaster Recovery Plan нужен компаниям, для которых остановка сервера оборачивается реальными финансовыми убытками, кибератака на базы данных чревата репутационными потерями, а сбой сайта или приложения нарушает операционный денежный поток.
Если потеря данных за 6-12 часов ничего в бизнес-процессах не меняет, компания может обойтись без детально прописанного DRP и ограничиться несложным планом восстановления из резервных копий. Пусть и не полноценный Disaster Recovery Plan, такой документ тоже полезен. Он помогает определиться с объектами копирования, расписанием и графиком бэкапов, видом, политикой хранения и регламентом восстановления резервных копий.
Как разработать план аварийного восстановления
План аварийного восстановления разрабатывает IT-отдел компании или архитекторы облачного провайдера. В нашем случае план разрабатывается архитекторами и параллельно с выбором DR-решения:
1. Проводится аудит инфраструктуры и объектов защиты при аварийных инцидентах. По каждому объекту формируются ссылки на документацию.
2. Распределяются роли персонала, обязанности внешних подрядчиков с фиксацией KPI по процессу реализации (время реагирования, RTO). Взаимодействие между сотрудниками и аутсорсером удобно иллюстрировать схемой.
3. Прописываются сценарии возможных инцидентов с основными факторами риска. По каждому сценарию прорабатываются процедуры проверки, точки мониторинга, последовательность действий. Обязательно обозначаются критерии, по которым сотрудники могут отнести инцидент к аварийной ситуации или событию, не требующему запуска DRP.
4. Определяется порядок поддержания актуальности плана аварийного восстановления. Устанавливается частота аудита и тестирования, необходимые для проверки корректности DRP.
Дополнительно в плане может указываться путь или место хранения технической документации, по шагам расписываются действия группы оценки финансовых рисков, условия подключения страховой компании и пр.
У плана аварийного восстановления нет формализованной структуры. Он может быть шире и объемней вышеприведенного шаблона. Главное, чтобы документ выстраивал четкую последовательность шагов при потенциальном сбое, помогал оценить масштаб аварии и среагировать адекватно угрозе. Кроме того, DR-план не статичен. Его нужно регулярно актуализировать, адаптируя под меняющуюся IT-инфраструктуру, новые направления деятельности и приоритеты бизнеса.
Чтобы понимать, насколько эффективен новый или скорректированный план восстановления, DRP тестируют. На базовом уровне достаточно проверить, понимает ли команда цель и значение DR-плана, знает ли каждый из сотрудников свои задачи, сроки реагирования. Для полноценного тестирования в компании моделируют аварийную ситуацию, не прерывая работу IT-систем: имитируют отказ оборудования и ПО, отслеживают реакцию персонала, проверяют эффективность коммуникаций, отклик резервных систем. Самый показательный, но и самый сложный вариант тестирования — проверка в рабочем режиме. Здесь все по-настоящему: провайдер отключает IT-инфраструктуру основной площадки, а компания проходит процедуры DR-плана в условиях реального отказа.
Глобальные тенденции к цифровизации постепенно подводят нас к тому, что Disaster Recovery Plan становится неотъемлемой частью планирования непрерывности бизнеса (Business Continuity). Как один из инструментов антикризисного менеджмента, он берет на себя поддержание доступности и восстановление IT-процессов, чтобы компания продолжала работать, несмотря на геополитические угрозы, инсайдерские атаки, стихийные бедствия и саботаж.
Disaster Recovery Plan (DRP) — как составить и что в него включить
Какой бы надежной ни была IT-инфраструктура, невозможно на 100% застраховаться от отказов в работе ПО или оборудования. Поэтому каждая организация должна иметь план действий, помогающий как можно быстрей восстановить работу ресурсов.
Disaster Recovery plan (DRP) — это системный подход, который последовательно описывает действия по восстановлению работоспособности IT-инфраструктуры организации в случае аварийной ситуации.
Для составления плана в организации проводится анализ бизнес-процессов и формулируются цели Disaster Recovery.
Типы аварий
План аварийного восстановления должен учитывать три основных вида событий, приводящих к катастрофическим последствиям.
Природные бедствия
- Пожары.
- Наводнения.
- Землетрясения.
- Пандемия.
Инфраструктурные катастрофы
- Отключение электричества.
- Пожар или прорыв водопровода.
- Обрушение здания.
- Проникновение злоумышленников на объект и нанесение физического ущерба.
Технологические аварии
- Авария сервера.
- Сбой ПО на локальном сервере.
- Сбой SaaS-приложения в облаке.
- Потеря данных из-за сбоя или вируса.
- Сбой сетевой инфраструктуры.
- Выход из строя инфраструктуры интернет-провайдера.
Стратегии DRP
Правильно составленная стратегия включает расчет времени, которое понадобится на восстановление ключевых сервисов. Стратегия поможет предприятию быстрее справиться с инцидентами, сократить время простоя и уменьшить финансовый и репутационный ущерб. Существует четыре основных стратегии DRP.
Локальное восстановление
Так как приложения, системы и данные развернуты on-premise, стратегия восстановления должна предусматривать потерю одного или нескольких компонентов системы.
Для восстановления данных и приложений крупные компании могут использовать два географически распределенных корпоративных дата-центра. Небольшие организации используют для резервного копирования отдельный сервер.
Аварийное восстановление в облаке провайдера
Такой подход сокращает расходы организации, так как избавляет от необходимости вкладывать средства в резервное оборудование. Важно добавить, что за счет сильной конкуренции на рынке облачных услуг, пользователи получают недорогое и надежное решение. Вдобавок провайдеры обладают опытом и экспертизой в реализации DRP и могут проконсультировать и предложить свои варианты решения.
Аварийное восстановление как услуга (DRaaS)
Облачные провайдеры предлагают Disaster Recovery как услугу. По сути, она является горячей резервной площадкой для аварийного восстановления ресурсов. DRaaS использует облако для предоставления пользователям копий приложений из корпоративного дата-центра. За счет этого организации быстрее реагируют и восстанавливают критически важные приложения.
Аварийное восстановление за счет виртуализации ресурсов
Виртуализация позволяет быстро развернуть копию виртуальной машины из облака или резервного сервера.
Что включить в Disaster Recovery Plan
Он должен содержать несколько разделов:
- описание и цели DRP;
- периодичность тестирования на резервных ресурсах;
- процедуры восстановления и перечень персонала, ответственного за реализацию плана.
Цели и параметры плана аварийного восстановления
Цель DRP — свести к минимуму негативное влияние аварии на работу организации. План может предусматривать как восстановление только базовых параметров, так и полное восстановление работоспособности.
Перед составлением плана оценивается потенциальное влияние аварии на бизнес. Исходя из этого, определяются приоритеты и задаются параметры для ключевых показателей аварийного восстановления: RTO и RPO.
RTO (целевое время восстановления) задает период, в течение которого система недоступна после аварии. Он указывается в минутах, часах или сутках. RTO относится к допустимому времени простоя от сбоя до восстановления. Например, организация должна вернуться к работе в течение 4 часов, чтобы избежать ущерба.
Для определения RTO нужно ответить на вопрос: «Сколько времени займет восстановление после сообщения о сбое бизнес-процесса?»
RPO (целевая точка восстановления) определяет максимальный период, за который данные могут быть утеряны. Например, RPO допускает потерю данных в пределах одного часа. Для достижения этой цели резервное копирование должно выполняться не реже одного раза в час.
Для определения RPO нужно ответить на вопрос: «Какой объем данных может быть потерян без существенного негативного влияния на бизнес организации?»
Затем разрабатываются стратегии восстановления приложений и данных.
Персонал
В плане аварийного восстановления должен быть указан персонал, ответственный за реализацию DRP. Кроме того, должны быть предусмотрены меры на случай отсутствия на рабочем месте кого-либо из ключевых сотрудников во время аварии.
IT-оборудование
При разработке DRP организации проводят инвентаризацию и составляют перечень аппаратных и программных активов, а также всех облачных сервисов, необходимых для функционирования организации. Оценивается важность каждого актива для бизнеса, находится ли он в собственности, аренде или используется по модели SaaS. Также важно сделать инвентаризацию лицензий и проверить их работу на измененных системах, чтобы понять нужна ли повторная активация или физическое перемещение лицензионных ключей.
Кроме того, все прошлые аварии необходимо задокументировать и описать, как они устранялись.
Процедуры резервного копирования и восстановления
В DRP указывается, как создается резервная копия каждого ресурса данных — где именно, на каких устройствах и в каких папках, а также как IT-отдел должен восстанавливать их из резервных копий.
Размещение ресурсов для аварийного восстановления
Надежный план Disaster Recovery должен предусматривать горячую площадку для аварийного восстановления. По сути, это резервный ЦОД, хранящий копии всех критически важных систем. Организация переключается на него после отказа основного ЦОДа.
Тестирование плана
Мало составить план — его надо протестировать, чтобы подтвердить соответствие заданным параметрам RTO и RPO, выявить и исправить возможные недостатки. Тестирование необходимо проводить с определенной периодичностью.
Существуют следующие типы тестирования:
- кабинетные учения;
- проверка отказоустойчивости приложений;
- проверка отказоустойчивости инфраструктуры;
- симуляция нарушения работы в тестовой среде;
- симуляция нарушения работы в среде продакшн.
Важно понимать, что DRP не составляется раз и навсегда. Технологии быстро меняются, поэтому необходим регулярный аудит и корректировка плана в соответствии с текущими задачами организации.
Решения «Корп Софт» для аварийного восстановления
«Корп Софт» предлагает услугу DRaaS — аварийное восстановление как сервис.
В нее входит составление плана аварийного восстановления и его тестирование. Клиент получает резервную инфраструктуру в облаке с настройкой репликации виртуальных серверов и круглосуточной техподдержкой. Кроме DRaaS, «Корп Софт» предоставляет клиентам площадку с вычислительными ресурсами для Disaster Recovery.