План восстановления отвечает на один вопрос: что делать, когда основная система недоступна. Он нужен не только после пожара в дата-центре, но и при отказе диска, ошибке администратора или шифровальщике.
Два числа, с которых всё начинается
RTO это допустимое время простоя. Сколько сервис может быть недоступен, прежде чем ущерб станет неприемлемым.
RPO это допустимая потеря данных. За какой период не жалко потерять работу: за час, за сутки, ни за какой.
Эти числа определяет бизнес, а не ИТ. Ответ «всё должно работать всегда и ничего не терять» означает бюджет, который никто не выделит. Поэтому разговор идёт по каждому сервису отдельно.
| Сервис | Типовой RTO | Типовой RPO | Что это значит |
|---|---|---|---|
| Бухгалтерия 1С | 4 часа | 1 час | копии раз в час, резервный сервер |
| Почта | 2 часа | 15 минут | облачный сервис или кластер |
| Файловый архив | 1 рабочий день | 1 сутки | ночная копия достаточно |
| Сайт с приёмом заявок | 30 минут | 5 минут | резервная площадка |
| Внутренний портал | 2 рабочих дня | 1 сутки | восстановление из копии |
Как только числа проставлены, становится понятно, где нужен дорогой резерв, а где хватит обычной ночной копии.
Приоритеты сервисов
Восстанавливать всё одновременно невозможно. Составьте список в порядке очереди, и пусть его подпишет руководитель: во время аварии спорить будет некогда.
Практика показывает, что первая тройка почти всегда такая: связь с внешним миром, учётная система, доступ к файлам. Всё остальное подождёт до вечера.
Отдельно опишите зависимости. Бесполезно поднимать 1С, если не работает служба каталогов, через которую пользователи входят. Такие цепочки выясняются на учениях, а не при написании плана.
Что должно быть в документе
- перечень сервисов с RTO, RPO и приоритетом
- схема инфраструктуры: где что стоит и как связано
- где лежат резервные копии и как до них добраться
- пошаговые инструкции восстановления по каждому сервису
- список ответственных с телефонами, включая личные
- контакты провайдеров и вендоров с номерами договоров
- порядок оповещения сотрудников и клиентов
- критерии, по которым авария считается завершённой
Документ должен быть доступен в бумажном виде или на устройстве, не зависящем от упавшей инфраструктуры. План восстановления, лежащий на сетевом диске, который недоступен, это классика.
Учения
План без проверки не работает. Минимальная программа выглядит так:
Раз в квартал восстанавливаете один произвольный файл и одну базу из копии. Засекаете время. Это проверка, что копии живые.
Раз в полгода разворачиваете критичный сервис на резервной площадке целиком. Обычно на этом этапе обнаруживается, что не хватает лицензии, дистрибутива или пароля.
Раз в год проводите полноценные учения с отключением основной системы в выходной день. Это дорого, но только так проверяется реальный RTO.
После каждых учений план правится. Если после учений в документе ничего не изменилось, значит их провели формально.
Типовые ошибки
Копии есть, восстановления нет. Резервное копирование настроено, но никто ни разу не восстанавливался. В половине случаев выясняется, что копируется не то или копии повреждены.
Все копии в одном месте. Основной сервер и хранилище копий в одной серверной. Пожар, залив или шифровальщик уничтожают оба.
План написан для идеального случая. В нём есть шаг «администратор восстанавливает базу», но нет ответа на вопрос, что делать, если администратор в отпуске и недоступен.
Нет критериев завершения. Сервис вроде работает, но никто не сказал, что авария закончена, и половина сотрудников продолжает сидеть без дела.
С чего начать, если плана нет
Не пытайтесь сразу написать документ на сорок страниц. Достаточно первого шага: соберите руководителей отделов и составьте список из пяти сервисов, без которых компания не работает, с ответом на вопрос «сколько мы протянем без него».
Дальше проверьте, есть ли для этих пяти сервисов рабочие копии и сколько занимает восстановление. Полученные два числа и будут вашими реальными RTO и RPO, а не желаемыми.
Схему копий с проверкой восстановления мы настраиваем в услуге резервное копирование. Если задача шире и нужен резерв по всей инфраструктуре, смотрите решение защита от простоев.