RTO отвечает на вопрос за сколько времени сервис нужно вернуть в работу. RPO отвечает на вопрос сколько данных допустимо потерять. Для малого бизнеса эти две цифры важнее, чем название backup-системы: именно они задают частоту копий, способ хранения и бюджет восстановления.
Разница на простом примере
Если у компании не работает 1С, RTO может быть 4 часа: дольше простой уже мешает отгрузкам и бухгалтерии. RPO может быть 1 час: потеря операций за день неприемлема, а потеря данных за несколько минут может быть слишком дорогой для текущего масштаба. Эти значения не универсальны, их задает бизнес-процесс.
| Термин | Простой смысл | Какой вопрос задать |
|---|---|---|
| RTO | Допустимое время простоя | Через сколько часов отсутствие сервиса станет проблемой для денег, клиентов или сроков? |
| RPO | Допустимая потеря данных | За какой период данные можно восстановить вручную без большого ущерба? |
Как выбрать значения
Начинать лучше не с оборудования, а со списка процессов. Для каждого процесса нужно понять, кто страдает при остановке, как быстро возникает ущерб и можно ли временно работать обходным способом.
| Процесс | Пример RTO | Пример RPO | Комментарий |
|---|---|---|---|
| 1С и складские операции | 2-4 часа | 15-60 минут | Зависит от количества документов и возможности ручного учета |
| Файловый сервер отдела | 4-8 часов | 1 рабочий день или меньше | Важна версия файлов и понятная точка восстановления |
| Почта | 4-24 часа | Зависит от провайдера и архива | Часть переписки может оставаться у получателей, но вложения и история важны |
| Сайт-визитка | 1-2 дня | После последнего изменения | Если сайт не принимает заказы, требования обычно мягче |
| CRM с заявками | 1-4 часа | 15-60 минут | Потеря новых лидов часто дороже простоя интерфейса |
Что меняется после выбора RTO/RPO
Чем меньше RTO и RPO, тем дороже и сложнее решение. Частые копии, быстрый запасной сервер, контроль репликации, регулярные тесты восстановления и хранение копий вне основной площадки требуют дисциплины. Поэтому одинаковый режим backup для всех систем обычно либо слишком дорогой, либо слишком слабый.
- Короткое RPO требует частых точек восстановления.
- Короткое RTO требует заранее подготовленного сценария запуска, а не только архива с файлами.
- Критичные сервисы нужно проверять восстановлением, иначе цифры остаются предположением.
- Для некритичных сервисов допустим более дешевый режим, если это осознанное решение.
Типичные ошибки
Первая ошибка - считать, что наличие резервной копии автоматически решает RTO. Копия может быть целой, но восстановление займет день из-за отсутствия свободного сервера, медленного канала или непонятной последовательности действий. Вторая ошибка - задавать RPO по удобству IT, а не по цене потерянных данных. Третья ошибка - не согласовывать цели с владельцем процесса.
Практический минимум
- Составьте список сервисов: 1С, файлы, почта, CRM, сайт, телефония, рабочие места.
- Для каждого сервиса назначьте владельца со стороны бизнеса.
- Определите допустимый простой и допустимую потерю данных.
- Сравните эти цели с реальным backup-процессом.
- Проведите тест восстановления хотя бы для самых критичных систем.
В услуге резервного копирования RTO и RPO должны быть зафиксированы до аварии. Иначе после сбоя выясняется не техническая, а управленческая проблема: ожидания бизнеса и возможности инфраструктуры не совпадали.