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

Цена катастрофы

Экономические и операционные убытки могут серьезно навредить неподготовленной компании. Согласно докладу Совета по готовности к чрезвычайным ситуациям (за 2016 год), один час "простоя" может стоить небольшим компаниям до 8 000 долларов, компаниям среднего размера до 74 000 долларов, а крупным предприятиям до 700 000 долларов.

Еще одно исследование, подготовленное компанией по аварийному восстановлению Zetta, показало, что более половины опрошенных компаний (54%) находились в простое более восьми часов за последние пять лет. Две трети опрошенных заявили, что их бизнес потеряет более 20 000 долларов за каждый день простоя.

Оценка риска

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

Но даже знание возможных уязвимых мест системы – не залог начала создания плана аварийного восстановления. Так, недавно авторы Том Рупке и Стивен Голдман написали, что создание такого плана может отвернуть внимание от других важных угроз.

Эксперты по информационной безопасности отмечают, что определяя худший сценарий, например, пожар, землетрясение или кибератаку, мы автоматически начинаем думать и планировать исходя из этой конкретной проблемы, упуская из внимания другие. Гиперконцентрация будет сосредоточена только на одной или двух конкретных областях. Именно эта проблема, по мнению авторов, является наихудшим сценарием, а не возможная "спланированная" катастрофа.

Ключевым моментом, на котором настаивают Рупке и Голдман, является сосредоточение внимания на "управлении кризисом и восстановлении критически важных функций".

Что входит в план аварийного восстановления данных

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

Сам план должен включать следующее:

  • Название, краткий обзор и основные цели плана;
  • Контактную информацию для ключевых сотрудников и членов команды аварийного восстановления;
  • Описание действий по реагированию на чрезвычайные ситуации сразу же после катастрофы;
  • Схема и алгоритм восстановления данных;
  • Схема всей IT-сети.

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

Определение наиболее важных IT-активов и максимального времени отключения.

Изучите термины "Целевая точка восстановления" (RPO) и "Время восстановления" (RTO).

RTO – это время, за которое файлы должны быть восстановлены из резервного хранилища для нормального функционирования после катастрофы.

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

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

Проработайте пакет предложений по решению финансовых и правовых вопросов, а также правила освещения инцидента в средствах массовой информации.

Создание команды по аварийному восстановлению данных

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

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

Произошла катастрофа – что делать?

Если катастрофа все-таки случилась, пришло время реализовывать план. Убедитесь, что команда реагирования на инцидент (если она отличается от команды планирования аварийного восстановления) имеет копию плана аварийного восстановления.

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