Эта статья для ИТ-руководителей компаний малого и среднего бизнеса — тех, кто отвечает за работоспособность ИТ-инфраструктуры и обосновывает бизнесу расходы на восстановление после аварий. В небольшой компании эту роль берет на себя единственный системный администратор, тогда вы и «руководитель», и исполнитель в одном лице.
Ниже разберем как назначить системам целевые значения времени восстановления (RTO и RPO), как вынести резервную площадку, чтобы она не повторяла риски рабочей, и что вскрывает первый тест переключения. Если еще предстоит защищать затраты на резервное копирование перед руководством, статья даст аргументы для этого разговора.
Привет, на связи Авдей Мартынович, руководитель подразделения по работе с СМБ в ALP ITSM. До ALP я был ИТ-директором региональной компании, теперь моя команда сопровождает ИТ малого и среднего бизнеса. В статье поделюсь опытом, который накопил за десятки внедрений и сопровождения систем резервного копирования.
Я регулярно слышу от ИТ-руководителей одно и то же: «У нас бэкапы делаются». Ночное копирование настроено, отчеты приходят, ошибок нет.
Тогда я задаю контрольный вопрос. Когда вы в последний раз переключались на резервную площадку целиком — хотя бы на тесте? Вот здесь обычно тупик. Мало кто может ответить, сколько времени займет возврат к работе и что из последних изменений пропадет. А когда возникнет кризисная ситуация, вопрос «когда заработаем?» зададут именно вам.
Осенью 2026 года компании на себе почувствовали, как остро стоит проблема резервирования. В октябре атаки беспилотников вывели из строя сразу несколько дата-центров одного облачного провайдера: доступ к ряду его сервисов пропал надолго, и у части компаний копии были, а развернуть их оказалось негде. В начале ноября кибератака на крупного хостинг-провайдера отключила инфраструктуру: сервисы были недоступны днями, а у части клиентов пропали данные облачных серверов.
Из этих случаев следует простой вывод: «хранить яйца в одной корзине» опасно. Копию на другой площадке еще нужно где-то развернуть, поэтому заранее готовят и площадку вне зоны риска основной.
RTO и RPO как договоренность бизнеса и ИТ
Что такое RTO и RPO — целевое время и точка восстановления
RTO и RPO — договоренность между бизнесом и тем, кто отвечает за ИТ. RTO (Recovery Time Objective, целевое время восстановления) задает время, за которое система должна снова заработать после сбоя. RPO (Recovery Point Objective, целевая точка восстановления) — до какого момента в прошлом бизнес готов откатиться. Данные, созданные позже этой точки, при аварии могут пропасть. Пока у системы нет целевых RTO и RPO, спор о резерве остается спором о вкусах. В идеале параметры отказоустойчивости по каждому сервису согласуются с заказчиком до начала проектирования ИТ-инфраструктуры.
Резервная площадка — это заранее подготовленное место, куда компания переключается, пока основная недоступна из-за сбоя. Копии и репликация отвечают прежде всего за допустимую потерю данных (RPO), схема восстановления — за допустимое время простоя (RTO).
Виды резервирования — от копий до двух активных площадок
Варианты организации резерва — от простого к сложному (границы между ними условны):
только копии, когда данные сохранены, но рабочую среду после аварии предстоит собрать;
минимальное резервное ядро (pilot light, «пилотный свет»): ключевые компоненты уже работают, остальное запускают при аварии;
теплый резерв — уменьшенная копия инфраструктуры на резервной площадке; в схеме ALP ITSM, которую разбираем ниже, вычислительные мощности включают только при переключении;
две активные площадки, обслуживающие нагрузку одновременно.
Какой бы вариант вы ни выбрали, допустимую потерю все равно придется оговорить. RPO мы принципиально согласуем по каждой системе (группе близких по критичности систем) отдельно, поэтому конкретную цифру я не называю. У каждой компании она своя, копировать чужую так же бессмысленно, как чужой бюджет.
Целевые RTO и RPO — определяет бизнес
Значения назначает бизнес, а разговор начинается с его потребностей.
Сколько данных при аварии компания готова потерять и сколько часов простоя выдержит до неприемлемого ущерба?
Последствия простоя каждого сервиса в деньгах знают владельцы процессов, а цену восстановления в нужные сроки и с допустимой потерей данных называете вы. Решение фиксируют совместно в соглашении об уровне сервиса (SLA) и регулярно пересматривают, потому что бизнес меняется.
На одном из аудитов я спросил собственника, согласованы ли у компании значения RTO и RPO. В ответ услышал, что никаких критериев нет, об этом не думали, и если она про вашу компанию, этот раздел подскажет, с чего начать разговор с бизнесом.
Классы критичности систем и допустимое время простоя
Чтобы не уходить в детали, для начала можно сгруппировать системы в два-три класса критичности и назначать политику классу: новая система при вводе получает свой класс. Для каждого класса задают свои значения RTO и RPO.
Универсальных «правильных» значений RTO и RPO нет. Минуты обычно нужны системам, от которых зависит коммерческая деятельность — телефонии call-центра, платежному шлюзу, складу и логистике. Остальным часто хватает часов или дней, ведь компания переживет день без архива документов, но не день без приема заказов. Чтобы определить критичность, достаточно разложить ИТ-сервисы по потерям от простоя.
Если целевых значений нет вовсе, начните с анализа влияния на бизнес: какие ИТ-сервисы критичны и как их простой бьет по доходу. Как строится этот диалог, мы разбирали в статье «План аварийного восстановления (DRP): почему наличие бэкапов не гарантирует спасение бизнеса».
Из практики: чего ждет бизнес и что может ИТ
Расхождение между ожиданиями бизнеса и возможностями ИТ часто всплывает на аудите. Однажды на встрече ИТ-директора и генерального директора розничной сети из сорока точек мы разбирали резервное копирование. Выяснилось, что бизнес ожидал восстановления работы 1С за час, а ИТ-команда в лучшем случае могла восстановить работу за четыре часа, и даже эту цифру назвали по экспертной оценке, без проверки. И никто не считал это проблемой, пока мы не посадили обе стороны за один стол.
Еще один случай из практики показывает, зачем ИТ и бизнесу говорить об этом напрямую. Мы проводили аудит в производственной компании. Я спрашиваю ИТ-директора про RTO критичных систем: «Часов за шесть поднимем». Идем к финансовому директору и считаем простой склада и линии сборки. Оказалось, каждый час простоя — это колоссальные штрафы за срыв отгрузок и простой фур. Когда собственник увидел, сколько стоят эти «шесть часов» в рублях, вопрос «зачем платить за теплый резерв, если есть ночные бэкапы» отпал. Мы договорились об RTO в 2 часа для критичных сервисов, и уже под эту бизнес-цель проектировали резервную площадку.
Правила разнесения резервных площадок — другой провайдер, другой регион
Резерв спасает, только если не повторяет риски основной площадки. У резервной площадки я бы проверял два требования, оба — до подписания договора.
Правило первое — другой провайдер. Дата-центры одного провайдера связаны общим управлением, правилами и часто географией, поэтому при аварии на нескольких площадках резервная может пострадать вместе с основной. Вторая зона доступности того же провайдера от этого не спасает, потому что зоны могут делить компоненты управления и зависеть от одного поставщика. Осенью это случилось с копиями, которые лежали в соседнем дата-центре того же провайдера, — мы подробно разбирали этот кейс в недавней статье на Хабре. Даже уцелевшие копии разворачивать было трудно: резерв уперся в ограничения того же провайдера на выдачу ресурсов. Один дата-центр, даже с внутренним резервированием, остается одной точкой отказа.
Правило второе — другой регион, и лучше внутри страны. Резерв в соседней области может пострадать от того же события, поэтому регион выбирают так же внимательно, как провайдера. Есть и правовая рамка. При сборе персональных данных граждан России закон требует записывать и хранить их в базах данных на территории страны, с ограниченным набором исключений (ч. 5 ст. 18 152-ФЗ). Такая географическая независимость и делает схему катастрофоустойчивой.
Переезжать целиком для этого не нужно. Основная площадка остается там, где удобно бизнесу, а в другом регионе готовят только резервную инфраструктуру под критичные системы.
Теплый резерв. За что платите в ожидании и где границы схемы
Экономика теплого резерва в схеме ALP ITSM скромнее, чем кажется. Копирование идет на уровне виртуальных машин. В описываемой схеме реплики занимают только хранилище, основные вычислительные мощности выключены и включаются в момент переключения (кроме небольших служб входа — в нашей практике это контроллер домена, DNS, DHCP, VPN-шлюз; о них ниже), поэтому в режиме ожидания компания платит в основном за хранение. Репликация в таких схемах обычно асинхронная. После первичной синхронизации система отслеживает измененные блоки данных и передает на резервную площадку только их. Реплика всегда немного отстает от рабочей системы, и это отставание и есть фактическое RPO: его стоит проверять в мониторинге и сверять с целевым значением.
Состав бюджета теплого резерва несложно прикинуть заранее. В режиме ожидания платите за хранение реплик и постоянно работающие службы входа;к этим расходам могут добавляться внешний роутер и IP-адреса. В момент переключения основные расходы — вычислительные мощности по часам или дням. Разовые расходы — первичная настройка репликации и тестовые запуски. Каждый тест — это включенные машины и время команды.
Точную смету даст только провайдер, но запрос к нему готовится заранее. Назовите количество и объем реплицируемых машин, характеристики, которые нужны им при переключении, и сколько дней в году резерв должен работать при аварии. И спросите прямо: что тарифицируется в ожидании, что в момент переключения, гарантированы ли вычислительные мощности в момент аварии и чем это подтверждается, входит ли тестовый запуск в тариф и что произойдет с данными, если решите уйти с площадки.
Как выглядит расчет, покажу на условном примере. Возьмем компанию, которая реплицирует пять виртуальных машин общим объемом два терабайта: учетная система, файловый сервер, сайт и пара служб. Пока все спокойно, в расходах только хранение этих двух терабайтов, минимальные службы входа и роутер с адресами. Во время аварии к ним добавляются пять машин по часовой ставке. Тестовый день устроен так же, только машины включены на восемь часов. Такой список уже можно нести провайдеру для сметы.
Безопасным тест делает изоляция. Главный риск перед первым запуском — конфликт идентичности: в одной сети оказываются два сервера с одним именем и адресом, рабочий и резервный (в кластерах похожую ситуацию называют split-brain). Поэтому резервный контур поднимают в изолированном сегменте, где машины видят друг друга, в рабочую сеть не выходят, а сотрудники для проверки подключаются, например, через отдельный VPN. После теста контур гасят, не трогая службы входа.
Такую схему — репликацию в облако провайдера с запуском резерва при аварии — часто называют аварийным восстановлением как услугой (DRaaS, Disaster Recovery as a Service). У схемы есть и граница. Резерв виртуальных машин не спасает сервисы, которыми управляет не ваша компания: облачную CRM, телефонию, внешнюю почту.
Резерв закрывает то, чем вы управляете сами — учетную систему, склад, сайт, файлы; для внешних сервисов нужны отдельные копии данных и запасной вариант работы.
DR-план аварийного восстановления, инструкция переключения и откат
До первого теста нужны три документа. Без них проверка превращается в импровизацию, а в настоящей аварии участникам придется выяснять порядок действий на ходу.
Первый документ — сам план аварийного восстановления, DR-план. В минимальном виде он отвечает на три вопроса: что считать инцидентом, кто принимает решение о переключении, какие сервисы поднимать первыми. Без ответа на второй вопрос восстановление даже не начнется. Мы подготовили шаблон такого плана, в нем семь разделов: критерии аварии и ответственные за ее объявление, перечень угроз, приоритеты систем с их RTO и RPO, стратегия восстановления по каждой системе, пошаговые процедуры восстановления, карта коммуникаций, расписание учений. Сам шаблон выложен на сайте.
Второй документ — пошаговая инструкция переключения (runbook). В ней описаны порядок запуска серверов, ответственные за шаги, доступ сотрудников к резерву и список тех, кого уведомлять.
Третий — инструкция отката: как вернуть все в исходное состояние, чтобы тест не задел рабочие системы. Возврат на основную площадку после ремонта планируют отдельно, чтобы не потерять то, что сделали за время работы на резерве, и тоже отрабатывают на учениях. Обычно для этого настраивают обратную репликацию: пока компания работает на резерве, накопленные изменения переносят на восстановленные серверы, и в финале нужна лишь короткая остановка на переключение назад. Спросите у подрядчика или ИТ-директора, предусмотрена ли она и проверяется ли при тесте.
Тест сценария восстановления проходит в отдельном контуре: рабочие системы не трогают, сотрудники работают в обычном режиме. Без такой проверки никто не знает, сработает ли DR-план.
Первый тест переключения на резервную площадку — что проверяем и что ломается
Первый тест редко проходит гладко, но он для того и нужен, чтобы найти разрывы до аварии.
Проверяем переключение целиком, в изолированном контуре. Серверы запускают в строгом порядке, сотрудники получают доступ к резервной площадке, а для банка, маркетплейсов и оператора электронного документооборота (ЭДО) отрабатывают, как они узнают новый адрес. Внешние обмены прогоняют в согласованном тестовом режиме, без реальных платежей, документов и заказов, а что в тесте проверить не удалось, записывают в протокол. Как показывает наш опыт, первый прогон вскрывает пять типовых проблем:
1. Программа стартует раньше базы данных и не может подключиться.
2. В ярлыках рабочих мест зашиты старые адреса, поэтому «восстановленная» система у сотрудника не открывается.
3. Пароль от резервного доступа знает один человек, который в день теста оказался в отпуске.
4. Не подготовлен доступ к банку с резервной площадки (например, исходящий IP не входит в разрешенные), и платежи не проходят.
5. Для оператора ЭДО и маркетплейсов не подготовлены настройки подключения с резервной площадки, поэтому останавливаются документооборот и обмен с каналами продаж.
Ни одна из этих проблем не видна из отчета «копирование прошло успешно». Первые три вскрываются при развертывании, а про банк и ЭДО тест лишь показывает, готовы ли обмены (реальных платежей и документов в нем нет). Первый тест обычно требует двух-трех итераций: первая находит дыры, вторая и третья закрепляют исправления.
Поломки поглубже: сервер лицензий, мощности и DNS
В разборах проверок восстановления встречаются и поломки поглубже, домен или обмен с банком, и провести платеж или отгрузку в такой системе нельзя. В другой раз провайдер не может создать виртуальную машину с нужными характеристиками, и готовую копию развернуть негде. Бывает, что сам DR-план и доступы к управлению доменными именами (DNS) лежат на сервере, который уже не работает. Отсюда правило: держать инструкции на бумаге и во внешнем облаке.
Почему машины поднялись, а пользователи не увидели систему
Причина пунктов 2 и 4 из списка — адресация: виртуальные машины поднялись, а пользователи и внешние сервисы по-прежнему идут на старую площадку. Чтобы это исправить, либо растягивают сетевой сегмент между площадками, либо меняют IP-адреса по заранее подготовленному сценарию и обновляют записи DNS, заранее снизив время их жизни (TTL), чтобы трафик быстрее пошел по новому маршруту. Что выбрано и кто это делает в день переключения, должно быть записано в инструкции. Есть и исключение из правила «мощности выключены» (см. выше раздел об экономике резерва): службы входа (контроллер домена, DNS, часто и VPN-шлюз) обычно работают на резервной площадке постоянно. Без них приложение может запуститься, а пользователи не смогут войти. Как это сделано в конкретном проекте, выясняйте при согласовании схемы. Как проходит тестовое восстановление из копии за один день, мы разбирали в статье о проверке бэкапа.
Фактические RTO и RPO — тест против договорных сроков
Времени на сам запуск часто уходит меньше, чем на остальное: заметить сбой, решить, что поднимать, убедиться в пригодности данных, перевести людей. Поэтому в протоколе теста фиксируют фактическое время восстановления и сравнивают его с целевым RTO. Результат относится к проверенному сценарию и условиям теста и не заменяет договорный срок. По договору переключение на резерв занимает не дольше 12 рабочих часов, на протестированной схеме обычно 1–2 часа. Разница между «по договору» и «обычно» и есть результат тестов. Расписание копирования само по себе ничего не подтверждает. Задание может завершиться позже срока, копия — не доехать до площадки, данные — оказаться непригодными.
Критерий успеха у теста бизнесовый. Восстановленная виртуальная машина еще не означает восстановленный бизнес-процесс. Бывает, что система расчета зарплаты поднята из копии, а посчитать в ней нечего, за годы доработок она обросла зависимостями от пропускной системы и интеграций. Работает то восстановление, после которого главный бухгалтер формирует в резервной базе ту же оборотно-сальдовую ведомость, а кладовщик проводит тестовую отгрузку. Сценарий берите неудобный, например отключение площадки целиком. Проверяйте и день, когда нет человека, который обычно запускает переключение.
Начать можно с настольной проверки, когда команда проходит план по шагам и ищет пробелы. Измерить время восстановления и проверить рабочие операции можно только практическим тестом, с полным запуском резервного контура и бизнес-проверкой. Его границы и непроверенные зависимости фиксируют отдельно.
Протокол теста и периодичность проверок восстановления
Тест заканчивается протоколом. В протокол попадают фактические RTO и RPO сценария (время восстановления и объем потери данных), ошибки в инструкциях, недостающие доступы, границы теста и то, что проверить не удалось. Каждая выявленная «дыра» становится задачей.
Периодичность тестирования восстановления
Разовое тестирование не работает, потому что инфраструктура меняется и проверенный сценарий тихо устаревает. Мы ориентируемся на полное тестирование плана аварийного восстановления не реже одного раза в год и на ежеквартальное восстановление отдельных систем; для критичных систем небольшой компании на практике выходит раз в квартал или полгода. К проверке возвращаются и после переезда, внедрения новой учетной системы или смены подрядчика.
План обновляется после каждого теста или значимого изменения, типовые правки предсказуемы. Уточненный порядок запуска дописывают в инструкцию, пароли из блокнота одного человека переносят в общий менеджер паролей, новые адреса прописывают в ярлыках и настройках. Если окажется, что все держится на одном администраторе и документированного порядка нет, тест вскроет это дешевле, чем авария.
Готовность — назначенные RTO и RPO, разнесенные площадки и протестированный сценарий
Путь от «у нас делают бэкапы» до готовности:
Назначить системам целевые значения RTO и RPO — допустимое время восстановления и допустимую потерю данных.
Вынести резервную площадку к другому провайдеру в другой регион.
Протестировать переключение и зафиксировать результат в протоколе.
Проверьте себя. Недоступность какого сервиса для компании критична, будь то учетная система, сайт или магазин, склад, файлы или облачные сервисы? Сколько бизнес выдержит без них — часы, день, несколько дней? Знаете ли вы, где лежат копии и когда в последний раз проверяли восстановление? Если хоть на один вопрос нет ответа, с его разбора и начинайте.
Если тест придется защищать перед руководством, аргумент простой. Тест измеряет фактическое время восстановления и актуальность восстановленных данных, помогает найти пробелы до аварии. Бюджет теста стоит сопоставить с потерями от простоя, а время восстановления из протокола — цифра, с которой вы придете к бизнесу, имея ответ на вопрос «когда заработаем».
Заказывать тест со стороны не обязательно. Производственная компания человек на двести после получения рекомендаций с нашего ИТ-чекапа внедрила регламент проверки восстановления силами собственной команды примерно за два месяца. Понять, что и как часто проверять, можно и самостоятельно.
Пока план не прошел тест, никто не скажет, сколько на самом деле займет переключение. Нужны резервная площадка, куда развернуть копию, и проверенный порядок действий. Если хотите пройти этот маршрут с командой, от назначения целевых значений до первого теста переключения, рекомендую начать с ревизии текущего состояния.
Механику подготовки мы подробно разобрали в статье «План аварийного восстановления (DRP): почему наличие бэкапов не гарантирует спасение бизнеса».
