Требовать нулевой потери данных и мгновенного восстановления для каждой системы — верный способ выйти за рамки бюджета. Практичный способ классифицировать системы с помощью анализа влияния на бизнес и подобрать для каждой подходящие цели RPO/RTO и технологию.
Спросите компании малого и среднего бизнеса об их плане аварийного восстановления (DR), и многие ответят: «Мы делаем резервные копии каждую ночь». Но резервная копия — это копия данных, а аварийное восстановление — это возобновление работы бизнеса. Если вы заранее не знаете, сколько данных можете потерять и как долго можете простаивать после пожара, отказа оборудования или атаки вымогателей, плана у вас нет. На эти два вопроса отвечают RPO и RTO.
Что такое RPO и RTO?
- RPO (Recovery Point Objective — целевая точка восстановления): максимально допустимый объем потери данных, измеряемый во времени. Если вы делаете резервную копию каждую ночь, ваш RPO составляет около 24 часов: авария во второй половине дня уничтожит все данные за этот день.
- RTO (Recovery Time Objective — целевое время восстановления): максимально допустимое время до того, как система снова станет доступна для работы.
Чем короче оба показателя, тем выше стоимость. Поэтому вместо того чтобы везде стремиться к «нулевым потерям и мгновенному восстановлению», системы следует группировать по их важности для бизнеса.
Шаг 1. Анализ влияния на бизнес
Для каждой системы задайте следующие вопросы:
- Что мы теряем, если эта система не работает час? Продажи, производство, удовлетворенность клиентов, договорные штрафы?
- Если данные этой системы за последний час будут утеряны, сможем ли мы их восстановить?
- Есть ли юридическое или договорное обязательство по доступности?
- От каких других систем она зависит?
ИТ-отдел не должен проводить этот анализ в одиночку — только вместе с бизнес-подразделениями. Насколько система критична, лучше всего знает команда, которая ею пользуется.
Шаг 2. Разделите системы на уровни
- Уровень 1 — критичные: ERP, интернет-магазин, платежные системы и системы обработки заказов. Цель: RPO — минуты, RTO — несколько часов. Подходящая технология: непрерывная репликация в другой дата-центр.
- Уровень 2 — важные: почта, файловый сервер, CRM. Цель: RPO — 1–4 часа, RTO — в тот же рабочий день. Подходящая технология: частая репликация или копии снапшотов.
- Уровень 3 — вспомогательные: архив, тестовые среды и среды разработки. Цель: RPO — 24 часа, RTO — несколько дней. Подходящая технология: восстановление из внешней резервной копии.
Шаг 3. Определите зависимости и порядок
Поднять сервер приложений за несколько минут бесполезно, если не работают аутентификация (Active Directory) и DNS. Зафиксируйте порядок восстановления: сначала сеть, учетные записи и DNS; затем базы данных; в последнюю очередь — приложения и доступ пользователей. В плане также должно быть описано, как меняются IP-адреса, DNS-записи и VPN-подключения в DR-среде.
Шаг 4. Регламент действий при аварии
- Кто объявляет аварию и на основании каких критериев?
- Какую систему кто поднимает и в каком порядке?
- Что и по каким каналам сообщается сотрудникам, клиентам и поставщикам?
- Как и когда выполняется возврат в основной дата-центр?
Шаг 5. Учения
Непроверенный DR-план — всего лишь предположение. Проводите учения не реже двух раз в год и замеряйте фактический RTO. Современные решения для репликации позволяют проводить учения в отдельной тестовой сети, не затрагивая рабочую среду. После каждых учений обновляйте план.
Не забывайте о сценарии с программой-вымогателем
Репликация за считаные секунды копирует на DR-площадку и зашифрованные данные. Поэтому ваше DR-решение должно хранить не только «последнее состояние», но и исторические точки восстановления. Планируйте срок хранения журнала репликации вместе с неизменяемыми резервными копиями, чтобы можно было вернуться к чистой точке непосредственно перед началом атаки.
Типичные ошибки
- Путать резервные копии с планом аварийного восстановления
- Хранить DR-копию в том же здании или дата-центре, что и рабочую среду
- Не продумать сеть, DNS и доступ пользователей
- Написать план и ни разу его не протестировать
- Отсутствие четкого ответственного за план и периодичности его пересмотра
CloudRUX DRaaS
CloudRUX DRaaS использует непрерывную репликацию на базе Zerto для копирования ваших виртуальных серверов в отдельный дата-центр в Турции и позволяет проводить учения, не затрагивая рабочую среду. В рамках нашей сертификации ISO 22301 по управлению непрерывностью бизнеса мы вместе с вами распределим системы по уровням и определим для каждой подходящие цели RPO/RTO. Чтобы получить оценку, напишите нам на info@cloudrux.com.