«Резервные копии есть» — ещё не ответ на вопрос, что произойдёт с бизнесом после аварии. Сотрудникам нужно вернуться к рабочим операциям, а данные должны оказаться достаточно свежими и корректными. RTO и RPO помогают заранее договориться об этих двух разных результатах и подобрать способ восстановления под реальные задачи компании.
RTO — сколько можно ждать
Цель по допустимому времени от остановки сервиса до восстановления согласованной работы.
RPO — насколько можно откатиться
Цель по допустимой потере изменений, выраженная глубиной возврата во времени.
RTO и RPO: определения и отличия
| Показатель | Что согласуем | Чем проверяем |
|---|---|---|
| RTO — Recovery Time Objective | Допустимое время восстановления рабочего сервиса после прерывания | Время от установленного начала простоя до подтверждения нужных операций |
| RPO — Recovery Point Objective | Насколько старой может быть пригодная точка возврата относительно сбоя | Состояние восстановленных данных, а не только время запуска задания копирования |
| Фактический результат | Что действительно удалось в конкретных условиях | Протокол восстановления, проверка данных и рабочих действий |
Буква O означает objective — целевой показатель. Цель не становится гарантией только от записи в документе. Её достижимость нужно проверить на выбранной архитектуре и сценариях отказа.
Терминологическая основа: определения RTO и RPO в NIST. При описании RPO как интервала оценивают разрыв между пригодным состоянием данных и моментом нарушения работы.
Пример: данные потеряли за 15 минут, работу вернули за 80
Условие учебного примера: компания согласовала RPO 15 минут и RTO 60 минут для определённого сервиса и сценария. Последняя пригодная точка содержит изменения до 09:45. Сбой произошёл в 10:00, а нужная рабочая операция снова выполняется в 11:20.
Данные можно восстановить в согласованном состоянии на этот момент.
Между точкой данных и сбоем — 15 минут изменений.
От остановки до результата прошло 80 минут.
По данным: цель выполнена
Разрыв 15 минут не превышает учебную цель RPO 15 минут.
По времени: цель превышена
80 минут больше RTO 60 минут. Превышение — 20 минут.
Эти числа не являются условиями обслуживания AVG IT или результатом клиентского проекта. В реальном случае дополнительно проверяют корректность данных, полноту операций и ограничения восстановленной среды. За одинаковые 15 минут в разных компаниях может накопиться совершенно разный объём работы.
Как определить цели вместе с бизнесом
Начинайте с рабочих операций, а не с возможностей программы резервного копирования. «Сервер доступен» и «сотрудники снова оформляют заказы» — разные результаты. Для каждого сервиса ответьте на вопросы:
- Что должно работать: приём заказов, отгрузка, расчёт зарплаты или другой процесс.
- Когда остановка особенно чувствительна: рабочая смена, закрытие периода, сезонная нагрузка.
- Какие изменения допустимо потерять: можно ли восстановить их из документов или внешней системы.
- Какая работа считается восстановленной: полный режим либо заранее описанный ограниченный набор операций.
- Кто подтверждает результат: владелец процесса и технические ответственные.
Сопоставление влияния на бизнес и достижимой технологии описано в рекомендациях AWS по выбору целей восстановления. Универсальных «правильных» 15 минут или четырёх часов для всех компаний нет.
Цели задают для сервиса и сценария отказа
| Ситуация | Что меняется в восстановлении | Что заранее проверить |
|---|---|---|
| Отказ одного узла | Может быть доступен исправный резерв и текущее состояние данных | Ресурсы резерва, переключение и путь пользователя |
| Удаление или повреждение данных | Нужен возврат к пригодному историческому состоянию | Глубину истории и согласованность копии |
| Потеря площадки или канала | Могут понадобиться другая среда и изменение подключений | Доступ к копиям, ресурсы, сеть и зависимости |
| Компрометация инфраструктуры | Нужно определить доверенное состояние и исключить повторное заражение | Изоляцию копий, доверенные доступы и процедуру проверки |
Восстановление после удаления записи и после потери всей площадки не следует оценивать одним испытанием. В карточке цели укажите, какие события и границы она охватывает. Если для отдельных сценариев нужны разные решения, это должно быть видно до аварии.
Четыре ситуации из практики восстановления
Ниже — учебные сценарии, близкие к работе корпоративной инфраструктуры. Время выбрано для объяснения расчёта, а не взято из клиентских инцидентов. В каждом случае отдельно заданы пригодное состояние данных или конфигурации и момент возвращения нужных рабочих операций.
1С и СУБД: база поднялась, но работа ещё не вернулась
Ситуация: в 14:00 отказало хранилище базы 1С. Есть пригодная базовая копия и необходимые журналы; на резервной среде удалось вернуть состояние на 13:55.
- Что делаем: готовим совместимую среду, возвращаем данные и журналы по процедуре выбранной СУБД, подключаем приложение.
- Где уходит время: выдача ресурсов, чтение копии, применение журналов, настройка соединений и проверка обменов.
- Когда закончено: в 15:10 ответственный проверил вход, чтение контрольных документов и согласованную рабочую операцию; необходимые обмены работают.
Расчёт: разрыв данных — 5 минут; восстановление — 70 минут. При учебных целях RPO 15 минут и RTO 60 минут первая выполнена, вторая превышена на 10 минут.
Важная деталь: для PostgreSQL PITR нужны подходящая базовая копия и непрерывная необходимая цепочка WAL; один логический дамп не заменяет этот набор. У MS SQL Server свои условия резервирования и применения журналов — схему нельзя переносить между СУБД без проверки.
Файловый сервер: вернуть папку вместе с правами
Ситуация: в 11:20 удалили рабочую папку отдела. Последняя пригодная версия содержит данные на 11:00. Остальной файловый сервер доступен.
- Что делаем: возвращаем выбранную папку сначала в отдельное место, проверяем содержимое и согласуем возврат пользователям.
- Где уходит время: поиск правильной версии, множество мелких файлов, проверка владельцев и ACL, публикация нужного сетевого пути.
- Когда закончено: в 12:05 сотрудники открывают и сохраняют нужные файлы, а пользователь без разрешения доступа не получает.
Расчёт: глубина возврата — 20 минут; недоступность папки — 45 минут. Учебные RPO 30 минут и RTO 60 минут выполнены.
Важная деталь: восстановление одной папки не доказывает такой же срок для всего сервера. При полной потере дополнительно понадобятся ОС, диски, общие ресурсы и зависимости; файловые ACL и разрешения сетевой папки проверяют отдельно.
DNS: служба отвечает, но нужная запись отсутствует
Ситуация: в 10:00 потеряли файловую первичную DNS-зону. Копия отражает состояние на 08:00; созданная в 09:40 запись в неё не попала.
- Что делаем: возвращаем зону и настройки, проверяем важные записи и разрешение имён через используемые клиентами DNS-серверы.
- Где уходит время: поиск копии, запуск зоны, проверка делегирования и пересылки, влияние клиентских кешей и TTL.
- Когда закончено: в 10:25 согласованные критичные имена разрешаются, связанные рабочие операции доступны. Отсутствующая новая запись отмечена как потерянное изменение.
Расчёт: возврат состояния на 2 часа назад не укладывается в учебный RPO 30 минут. Время 25 минут укладывается в RTO 30 минут для указанного набора операций.
Важная деталь: если новая запись тоже обязательна для приёмки, на 10:25 восстановление ещё не закончено. Для AD-интегрированной зоны порядок другой: она хранится в AD DS, и состояние каталога и репликации нужно учитывать. Запущенная служба DNS не подтверждает восстановление зоны.
Коммутатор: конфигурация есть, запасного устройства нет рядом
Ситуация: в 14:30 отказал коммутатор доступа. Внешняя копия конфигурации на 14:20 включает последнее согласованное изменение. Совместимый запасной аппарат пришлось привезти.
- Что делаем: сверяем модель и прошивку, готовим замену, переносим настройки подходящим способом и подключаем линии по схеме портов.
- Где уходит время: доставка, консольный доступ, соответствие интерфейсов, VLAN и транков, проверка PoE и восходящих соединений.
- Когда закончено: в 15:50 рабочие места в нужных VLAN достигают шлюзов и сервисов; ограничения сегментов и нужное оборудование проверены.
Расчёт: состояние конфигурации отстаёт на 10 минут, но возврат работы занял 80 минут. Учебный RPO 15 минут выполнен, RTO 60 минут превышен на 20 минут.
Важная деталь: здесь RPO относится к настройкам, а не к восстановлению потерянных сетевых пакетов. Копия на самом сломанном устройстве может оказаться недоступной. Например, бинарный backup RouterOS рассчитан прежде всего на исходное устройство; перенос на замену требует отдельной проверки, а не слепой загрузки файла.
Техническая основа примеров: PostgreSQL 17: базовая копия, WAL и PITR, Windows Server: выбор места восстановления и ACL, Microsoft: типы и хранение DNS-зон, MikroTik: ограничения бинарного backup. Это ориентиры для подготовки процедуры, а не универсальная инструкция восстановления всех версий и устройств.
Файл скопирован, база запущена или устройство отвечает — это промежуточные этапы. Завершение определяет заранее согласованная рабочая проверка. Если обязательная операция не работает, отсчёт восстановления продолжается.
Что помогает уменьшить RPO и RTO
Для более свежих данных
- Подходящая частота пригодных точек возврата.
- Журналы СУБД и восстановление по времени, где это поддерживается.
- Контроль доставки и отставания копий.
- Проверка согласованности приложения.
Для более быстрого возврата
- Подготовленные ресурсы и конфигурация.
- Доступные инструкции и полномочия.
- Проверенный маршрут переключения.
- Понятная приёмка рабочих операций.
Расписание «каждые 15 минут» само по себе не подтверждает RPO 15 минут: задание может завершаться позже, копия — не доставляться на нужную площадку, а данные — оказаться непригодными для восстановления.
Репликация и резервное копирование дополняют друг друга. Реплика может быстро получить ошибочное удаление вслед за основной системой; для возврата к прошлому состоянию нужна соответствующая история. Различия разобраны в объяснении Microsoft о резервировании, репликации и копиях. Нужный набор выбирают под риск, а не по названию технологии.
Из чего складывается время восстановления
В учебном примере 80 минут можно разложить на этапы. Это условный последовательный маршрут; при реальном восстановлении некоторые работы идут параллельно, а итог определяется зависимостями.
- Обнаружить и подтвердить остановку — 10 минут.
- Принять решение и подключить ответственных — 10 минут.
- Подготовить среду и доступы — 15 минут.
- Вернуть данные — 30 минут.
- Запустить приложение и связи — 10 минут.
- Проверить рабочую операцию — 5 минут.
Ускорение чтения копии не устранит ожидание согласования или отсутствие доступа. Оптимизируйте этапы по измеренным задержкам.
Если цель отсчитывается от прерывания сервиса, нельзя начинать секундомер только после прибытия инженера. Зафиксируйте начало и конец отсчёта. Частичное восстановление отмечайте отдельно от полного; критерий ограниченного режима согласуйте заранее.
Зависимости, которые легко забыть
- Учётные записи: доступ к копиям, ключам шифрования и панели управления.
- Инфраструктура: сеть, DNS, время, место для восстановления и производительность хранилища.
- Приложение: версии, настройки, сертификаты и необходимые компоненты.
- Связанные системы: обмены, очереди, внешние сервисы и порядок их запуска.
- Люди: исполнитель, замещение, согласование и подтверждение результата.
Восстановленная виртуальная машина не означает восстановленный бизнес-процесс. Например, 1С может открываться, но обмен с соседней системой — ещё не работать. Восстановление связанных данных на разные моменты требует отдельной проверки согласованности.
Для зависимостей нужен свой порядок восстановления. Процедура не должна опираться исключительно на недоступный основной сервис: инструкция и контакты должны оставаться доступны участникам аварийных работ.
Как проверить, что цели достижимы
- Опишите сценарий: что недоступно и какие исходные ресурсы сохраняются.
- Подготовьте испытание: согласуйте среду, границы воздействия, данные и способ возврата.
- Пройдите процедуру: используйте реальные инструкции и фиксируйте этапы, ожидания и отклонения.
- Проверьте данные: установите фактический момент пригодного состояния, а не дату файла.
- Проверьте работу: выполните согласованные операции и получите подтверждение ответственного.
- Сравните с целями: оформите ограничения и действия по устранению разрыва.
Проверку процедуры и сопоставление с RTO/RPO рекомендует AWS Well-Architected. Испытание в изолированной среде полезно, но его ограничения нужно указать: оно может не охватывать реальные переключения сети, нагрузку или участие внешнего поставщика.
Объём данных, конфигурация и связи меняются. Возвращайтесь к проверке после существенных изменений и по согласованному плану. Предыдущий успешный результат относится к условиям того испытания. Практическое продолжение серии — руководство по проверке восстановления.
Что не следует обещать без проверки
- «В облаке всё восстановится само». Ответственность за ресурсы, приложение и данные нужно разделить явно.
- «RAID заменяет копии». Устойчивость к отказу диска не означает возврат к состоянию до удаления или повреждения.
- «Нулевая потеря при любой аварии». Даже строгая схема имеет границы по событиям и зависимостям.
- «Высокая доступность равна нужному RTO». Процент доступности и восстановление после конкретной аварии оценивают разные стороны работы.
Более строгие цели обычно требуют дополнительных ресурсов и организации работы, но выбирать их нужно по последствиям остановки. Обсуждайте варианты: текущая схема, усиление отдельных этапов, подготовленная резервная среда. Подтверждённые условия фиксируют отдельно; RTO и RPO не заменяют все положения SLA.
Два материала для согласования и проверки
Карточка целей RTO/RPO
Сервис, сценарий, допустимые потери, зависимости, критерии работы и ответственные.
Скачать карточку · TXTПротокол восстановления
Временные отметки этапов, пригодная точка данных, результат и отклонения от цели.
Скачать протокол · TXTФормы предназначены для подготовки решения и проверки. Заполненные цифры без испытания не подтверждают достижимость восстановления.
От целей бизнеса к работающей схеме восстановления
ИТ-аутсорсинг: подготовить и проверить
- Собрать сервисы и зависимости.
- Обсудить цели с владельцами процессов.
- Разобрать копирование и порядок действий.
- Запланировать проверку восстановления.
Состав сопровождения и ответственности согласуем под вашу инфраструктуру.
Обсудить восстановлениеОблачные ресурсы: оценить резервную среду
- Определить нужные мощности и связи.
- Обсудить размещение копий и доступы.
- Оценить подготовку и запуск резерва.
- Уточнить границы поддержки приложения.
Конфигурация, доступность ресурсов и условия аренды подтверждаются отдельно.
Обсудить облачный резервВопросы о RTO и RPO
RPO — это время восстановления?
Нет. RPO связано с допустимой глубиной возврата данных. Время от остановки до восстановления согласованной работы оценивают относительно RTO.
Кто определяет RTO и RPO?
Бизнес формулирует допустимое влияние на процессы, а технические специалисты проверяют варианты реализации, ограничения и затраты. Цели согласуют для конкретного сервиса и сценария.
Достаточно запускать копирование с интервалом, равным RPO?
Нужно проверить, какие точки действительно пригодны и доступны при выбранном отказе. Важны завершение задания, доставка копии, согласованность данных и возможность их восстановления.
Можно выполнить RPO, но не выполнить RTO?
Да. В учебном примере удалось вернуть достаточно свежие данные, но восстановление работы заняло больше допустимого времени. Обратная ситуация тоже возможна.
Репликация заменяет резервные копии?
Репликация помогает поддерживать дополнительное состояние, но может перенести ошибочное изменение. Для возврата к прошлой пригодной точке нужны соответствующие средства истории и восстановления.
Если тест прошёл успешно, цель гарантирована навсегда?
Результат подтверждает конкретные условия испытания. Изменения объёма, конфигурации, нагрузки и зависимостей требуют пересмотра. Границы обязательств и порядок проверки согласуют отдельно.