Целевые RPO и RTO не выбирают «на глаз» и не задают одной цифрой на всю инфраструктуру — их выводят из цены простоя и потерь для каждого процесса. Метод в три шага: составить список систем и оценить, что стоит их остановка и потеря свежих данных; назначить каждой системе допустимый интервал потерь (RPO) и допустимый простой (RTO); перевести цели в технологию по матрице — от ночного бэкапа до журналов СУБД и репликации — и проверить достижимость тестом.
Эта статья — про сам выбор целевых значений и его перевод в схему восстановления. Что означают термины и как устроена дисциплина резервного копирования целиком — в хабе рубрики; здесь определения даются одной строкой: RPO — допустимый интервал времени, работа за который может быть потеряна; RTO — допустимое время восстановления после аварии.
Что разобрано в статье
Сначала бизнес-решение
Целевые RPO и RTO — ответ бизнеса на вопрос «что нам стоит простой и потеря данных», и уже затем — техническое задание для схемы восстановления.
По процессам, не «на всё»
У 1С, файлового архива и почты цена простоя разная — и цели у них разные. Одна цифра на всю инфраструктуру означает переплату за второстепенное или недозащиту главного.
Матрица технологий
Каждый уровень цели закрывается своим механизмом: ночной бэкап, дневные инкременты, журналы СУБД, репликация — и у каждого шага своя цена.
Цена ужесточения
Путь от «сутки потерь» к «минутам» — это не настройка галочки, а смена класса решения; стоимость растёт ступенями, а не плавно.
Сквозной пример
Три типовые системы малого бизнеса с условными целями и схемами: как одинаковый метод даёт разные ответы для разных процессов.
Проверка тестом
Цель на бумаге — гипотеза: достижимость подтверждается end-to-end тестовым восстановлением с замером, и если факт больше целевого — меняют схему или цель.
Почему это выбор бизнеса, а не настройка ИТ
Частая ситуация: расписание бэкапов настроено «как обычно» — ночная копия, хранение месяц, — а допустимые потери и простой никто не выбирал. Работает это ровно до первой аварии: тогда выясняется, что день работы отдела продаж терять было нельзя, а восстановление сервера шло дольше, чем бизнес готов был стоять.
Правильный порядок обратный: сначала бизнес отвечает на два вопроса — «сколько часов работы нам не жалко потерять» и «сколько часов мы готовы стоять», — и только потом эти ответы превращаются в расписание копий, глубину хранения и, при необходимости, в репликацию или резервную площадку. Такой порядок — стандартная логика планирования непрерывности: методика NIST SP 800-34 строит контингенси-план от анализа влияния на бизнес (BIA) — оценки процессов и приоритетов восстановления — к техническим решениям.
Пять шагов ниже — упрощённый рабочий чек-лист этой статьи для первичной приоритизации: он собирается на один лист и даёт достаточную основу для выбора целей. Формальный BIA он не заменяет — там, где полный анализ требуется регламентом, SLA, отраслью или внутренней политикой, выполняется именно он.
Разделение ролей в этом разговоре простое. Владелец процесса называет последствия: что остановится, кому и чем это грозит, сколько работы допустимо потерять. ИТ называет цену уровней защиты: во что обойдётся «сутки», «часы», «минуты». Решение — совместное и зафиксированное; тогда при аварии не возникает спор «почему восстановление идёт четыре часа», потому что эти четыре часа были выбраны и подписаны заранее.
Шаг 1. Инвентаризация: какие системы и что стоит их простой
Составьте список информационных систем и для каждой ответьте на три вопроса:
Кто и как работает с системой? 1С — учёт и продажи; файловый сервер — договоры и проекты; почта и CRM — коммуникации с клиентами; сайт — заявки. Из этого видно, чей рабочий день останавливает авария.
Что происходит при простое? Полезно оценить последствия часа, рабочего дня и нескольких дней остановки: где-то простой означает «неудобно», где-то — остановку отгрузок или срыв сроков. Точная цифра в рублях не обязательна — достаточно честного ранжирования систем по болезненности простоя.
Что происходит при потере свежих данных? Потерянный день документов в учётной системе придётся восстанавливать вручную по первичке; потерянный день переписки бьёт по договорённостям и коммуникациям с клиентами; потерянные проектные файлы могут не восстановиться никогда. Свежесть данных и болезненность их потери — разные у разных систем.
Итог шага — короткая таблица «система → кто работает → цена простоя → цена потери данных». Это и есть компактный аналог BIA: ранжирование, из которого следуют все дальнейшие решения.
Шаг 2. Целевой RPO: сколько работы допустимо потерять
Для каждой системы задайте владельцу процесса один вопрос: «Авария случилась в самый неудачный момент. Работу за какой интервал времени мы готовы восстановить руками или смириться с её потерей?» Ответ и есть целевой RPO этой системы.
Условные примеры классов ответа — иллюстрации, не типовые нормы для перечисленных систем:
Сутки — условный пример для систем, где день работы восстановим по первичным документам: файловые архивы, второстепенные базы, тестовые среды.
Несколько часов — условный пример для систем с активным дневным потоком: учётные системы с интенсивным вводом, CRM в разгар сезона. Потеря дня здесь означает ручное восстановление — его трудоёмкость и риски сравнивают со стоимостью дополнительных копий для конкретной системы.
Минуты — условный пример для систем, где ручное восстановление невозможно или недопустимо: интенсивные СУБД, обработка заказов в реальном времени. Это уже территория журналов СУБД и репликации — и другой класс затрат.
Важно: RPO — про допустимый интервал потерь, а не про расписание бэкапов. Расписание — следствие: частота копий подбирается так, чтобы худший случай укладывался в целевой интервал.
И не путайте RPO с глубиной хранения — это разные оси. Целевой интервал потерь отвечает на вопрос «как давно сделана последняя пригодная копия», а глубина — «как далеко назад мы можем откатиться». Система с часовым RPO и хранением в одни сутки беззащитна перед проблемой, замеченной через неделю: свежие копии уже содержат повреждение. Поэтому цель по интервалу всегда дополняется решением о глубине — оно принимается на этом же шаге, по той же цене последствий.
Шаг 3. Целевой RTO: сколько допустимо стоять
Второй вопрос владельцу процесса: «С момента аварии — через сколько система обязана снова работать?» Отсчёт идёт вперёд и включает всё: диагностику, решение о восстановлении, само восстановление, проверку.
Два уточнения, которые уберегут от нереалистичных ответов:
Учитывайте зависимости. «1С должна работать через два часа» означает, что за эти же два часа должны подняться и сервер, и СУБД, и сеть — не только сама база. Целевой RTO процесса считается по всему критическому пути восстановления: последовательные этапы — диагностика, восстановление платформы и данных, проверка работоспособности — складываются по времени, а параллельные ветки учитываются по самой длинной.
Разделяйте сценарии. Восстановление одного файла, отказ сервера и потеря всей серверной — разные события с разной ценой. Целевые значения имеет смысл задавать для типовых сценариев: локальный отказ (диск, сервер) и локальная катастрофа (помещение недоступно). Для катастрофического сценария задаются отдельные цели: они могут отличаться от целей локального сценария, а их значения определяются последствиями для бизнеса.
Полезный промежуточный вариант — деградированный режим: заранее решить, какая минимальная функциональность должна вернуться первой. «Через два часа принимаем заказы, полная отчётность — к утру» — это два разных RTO для одного процесса: подход может снизить требования к первой фазе восстановления, а его влияние на стоимость и сложность схемы оценивается для конкретного решения.
Как и с RPO, ответ «немедленно» — легальный, но дорогой: непрерывная доступность — это уже кластеры и резервирование инфраструктуры, разобранные в статье о высокой доступности. Задача этого шага — честный допустимый простой, а не желаемый ноль.
Шаг 4. Матрица «цель — технология»
Когда у каждой системы есть целевые RPO и RTO, они переводятся в технику. Таблица ниже — примеры классов решений, не нормативы: конкретный механизм и достижимый интервал подтверждаются проверкой полного контура восстановления, а не строкой матрицы.
| Целевой уровень | Типовой механизм | Что это означает на практике |
|---|---|---|
| RPO порядка суток | Ночной бэкап (полный или инкрементный) с версионированием | Базовый уровень: суточная частота пригодных точек восстановления; число копий, носители и офсайт — отдельное решение об архитектуре копий |
| RPO порядка часов | Дневные инкременты поверх ночной копии | Дополнительные точки восстановления в течение рабочего дня; нагрузка на хранилище и окна копирования проверяются проектно |
| RPO порядка минут | Журналы транзакций СУБД, непрерывная защита (CDP) | Средства платформы/СУБД; состав контура зависит от платформы, применимость журналов регулярно проверяется |
| RPO, близкий к нулю | Синхронная репликация или непрерывная защита — по возможностям платформы | Другой класс решения: дублированная инфраструктура и канал; репликация дополняет копии, но не заменяет их |
| RTO порядка дня | Восстановление из копии на подготовленное железо | Подходит второстепенным системам; фактическое время задают объём данных и готовность площадки |
| RTO порядка часов | Готовый резервный сервер + образы систем | Восстановление образа на подготовленную площадку; порядок действий отработан заранее |
| RTO порядка минут | Резервный узел в горячем режиме, кластер | Территория высокой доступности — отдельная дисциплина со своим бюджетом и требованиями |
Два замечания к матрице. Первое: механизмы складываются и не заменяют друг друга — журналы СУБД работают поверх регулярных копий, репликация — рядом с ними, потому что может распространить на вторую копию удаление, повреждение или шифрование (подробно об этой границе — обзорно в хабе рубрики). Второе: «железная» часть уровня — хранилище копий с достаточной ёмкостью и скоростью восстановления; выбор класса — в гайде по СХД.
Отдельно проверьте матрицу на сценарии локальной катастрофы: если единственная уцелевшая копия — офсайтная, фактическое время восстановления определяется скоростью её получения. Выгрузка больших объёмов из облака через интернет-канал может занять больше времени, чем весь целевой RTO, — тогда для критичных систем предусматривается локально доступная копия на отделённом носителе или заранее оговорённый способ ускоренного получения данных. Целевые значения для катастрофического сценария задаются отдельно и честно.
Шаг 5. Цена ужесточения целей
Ключевое свойство матрицы: стоимость растёт ступенями. Переход от «суток» к «часам» — это настройка дополнительных инкрементов в имеющейся схеме. Переход от «часов» к «минутам» — уже новая механика: журналы, их хранилище, дисциплина проверки. Переход к «около нуля» — смена класса решения: вторая система хранения, канал, репликация, а для RTO — ещё и резервный вычислительный узел.
Поэтому работает простое правило: ужесточайте цель только там, где цена простоя или потерь этого требует. «Минуты для всего» и «минуты для 1С, сутки для остального» — разные классы затрат; сравнивайте их с фактической ценой простоя каждой системы.
Обратное правило тоже верно: если цена простоя высока, экономия на уровне защиты — ложная: трудоёмкость и риски ручного восстановления потерянной работы оценивайте против стоимости более частых копий.
Чтобы матрица не превратилась в двадцать индивидуальных политик, системы группируют в два-три класса: «ключевые» (жёсткие цели, свой бюджет), «рабочие» (умеренные цели), «второстепенные» (базовый уровень). Политика назначается классу, а каждая новая система при вводе просто получает класс — так таблица целей остаётся управляемой и через год.
Сквозной пример: три системы малого бизнеса
Компания на 40–60 сотрудников, три ключевые системы. Все числа условные — иллюстрация метода: ваши значения даст только ваш шаг 1.
| Система | Цена простоя / потерь | Целевой RPO | Целевой RTO | Схема |
|---|---|---|---|---|
| 1С + СУБД | Останавливаются продажи и отгрузки; ручной перенос дня документов очень дорог | 1 час | 4 часа | Ночной бэкап + журналы СУБД в течение дня; восстановление на подготовленный резервный сервер |
| Файловый сервер | Неудобно, но день можно работать локально; потеря дня файлов болезненна точечно | Сутки | 8 часов | Ночной инкрементный бэкап с версионированием на NAS + офсайт-копия по 3-2-1 |
| Почта / CRM | Простой тормозит коммуникации; потеря переписки бьёт по договорённостям с клиентами | 4 часа | 4 часа | Дневные инкременты поверх ночной копии; восстановление сервиса из образа |
Обратите внимание: метод один, ответы разные. Именно поэтому «один RPO на всю инфраструктуру» — плохая отправная точка: он либо навязывает файловому архиву цену журнальной защиты, либо оставляет учётную систему с суточными потерями.
Для сценария локальной катастрофы во всех трёх строках работает одна и та же страховка: офсайт-копия по правилу 3-2-1 и отдельные, заранее оговорённые целевые значения — восстановление после пожара честно займёт больше времени, чем замена диска, и таблица целей должна это отражать.
Под итоговую схему подбирается и «железная» часть — хранилище копий с запасом ёмкости под версии и скоростью под целевой RTO: системы хранения в каталоге ANDPRO.
Фиксация целей и проверка достижимости
Выбранные цели стоит зафиксировать письменно — таблицей на страницу: система, целевой RPO, целевой RTO, механизм, ответственный. Это короткий документ, который превращает устные договорённости в проверяемые обязательства и переживает смену подрядчика или администратора.
Дальше цели связываются со схемой копий: частота и типы копий закрывают целевой RPO, а глубина хранения и разнесение носителей строятся по правилу 3-2-1 — практический разбор архитектуры копий в статье о правиле 3-2-1.
И последнее: цель на бумаге — гипотеза. Достижимость подтверждает end-to-end тестовое восстановление: система поднимается из реальной копии на резервное железо с замером времени и проверкой данных и зависимостей. Если фактический результат больше целевого RTO — меняется либо схема (быстрее хранилище, готовый резервный узел), либо цель (честно признать больший простой). Обе развязки лучше, чем узнать о расхождении во время настоящей аварии.
И назначьте целям срок пересмотра. Бизнес меняется: появляются новые системы, растут объёмы, процесс, который год назад терпел сутки простоя, сегодня останавливает отгрузки. Стартовая рекомендация этой статьи — пересматривать таблицу целей при каждом заметном изменении процессов и не реже раза в год: это короткая встреча, а не проект.
Пять типовых ошибок целеполагания
| Ошибка | Чем оборачивается | Как правильно |
|---|---|---|
| Один RPO/RTO на всю инфраструктуру | Переплата за второстепенные системы или недозащита ключевых | Цели — по системам, из цены простоя и потерь каждой |
| Цели выбраны без владельцев процессов | ИТ отвечает за компромисс, который бизнес не принимал | Допустимые потери и простой называет владелец процесса |
| RPO приравнен к расписанию бэкапа | «Копия раз в сутки» без глубины и проверки не гарантирует суточного интервала потерь | Расписание — следствие цели; худший случай должен укладываться в интервал |
| Цели заданы, но не проверены тестом | Фактическое восстановление дольше целевого — выясняется в аварию | Тестовое восстановление с замером; расхождение лечится схемой или целью |
| «Ноль потерь и ноль простоя» по умолчанию | Смета другого класса без соразмерной выгоды | Ужесточать только там, где этого требует цена простоя/потерь |
Частые вопросы
Можно ли задать один RPO и RTO сразу на всю инфраструктуру?
Технически — да, но единая цель может переусложнить защиту второстепенных систем или недозащитить критичные. Поэтому цели сравнивают и назначают по системам или классам. Для управляемости можно начать с двух-трёх классов: ключевые, рабочие и второстепенные.
Реально ли получить RPO и RTO, близкие к нулю?
Достижимо, но это другой класс решения: синхронная репликация на независимое хранилище, резервный вычислительный узел, кластеризация — и соответствующие требования к каналам и дисциплине эксплуатации. Для отдельных критичных систем это бывает оправдано; решение диктует цена минуты простоя, «сделать надёжно» само по себе аргументом не является. Архитектуры этого уровня — тема статьи о высокой доступности.
Как понять, что выбранные цели достижимы?
Достижимость подтверждается end-to-end тестовым восстановлением: система поднимается из реальной копии на резервное железо, фактическое время сравнивается с целевым RTO, свежесть и целостность восстановленных данных — с целевым RPO, работоспособность проверяется вместе с зависимостями. Расхождение — нормальный результат теста: оно означает, что схему или цель нужно скорректировать до аварии, а не во время неё.
Авторство и ответственность
Материал подготовлен для блога ANDPRO / ООО «АНД-Системс» как информационная статья о выборе целевых значений RPO и RTO: инвентаризация процессов и оценка последствий простоя, метод назначения целей по системам, матрица соответствия целей и технологий, цена ужесточения, документирование и проверка достижимости. Статья описывает метод и типовые ориентиры, но не заменяет проектирование схемы восстановления под конкретную инфраструктуру и требования.
Материал подготовлен при участии AI-ассистента, прошёл фактчекинг и редакторскую вычитку. Подход «от анализа влияния на бизнес к целям восстановления» соответствует методике contingency planning NIST SP 800-34 Rev. 1; пятишаговая схема статьи — упрощённый рабочий чек-лист, не заменяющий формальный BIA. Определения RPO/RTO согласованы с публикациями Veeam и хабом рубрики. Уровни матрицы «цель — технология», ориентиры интервалов и значения сквозного примера — стартовые допущения этой методики, помеченные в тексте как условные.
Для подбора хранилища под схему восстановления, расчёта ёмкости под глубину хранения, подготовки КП и документов обратитесь в ANDPRO: info@andpro.ru, +7 (495) 545-48-70, +7 (800) 707-78-15.
Дата последнего обновления материала: 21 июля 2026 года.
