Измеренный RTO, регулярный тестовый restore и проходящий ТиИ
Рекомендация
Рекомендация
Заголовок раздела «Рекомендация»Для боевых баз должен быть измеренный RTO восстановления из бэкапа, регулярный тестовый restore и согласованный приемлемый простой. ТиИ (тестирование и исправление) выполняется по регламенту, а не «когда-нибудь».
- Зафиксировать целевой RTO и приемлемый простой; измерить фактический (размер/тип бэкапа, этапы, узкие места по диску/CPU/сети/PostgreSQL).
- Регулярный тестовый restore — иначе RTO неизвестен до реального инцидента.
- Безопасный сценарий ТиИ + регламент обслуживания PostgreSQL/1С; узкие места ТиИ раскладывать на отдельные задачи оптимизации.
Реальный инцидент: PSQL-бэкап БП разворачивается более 7 часов — при серьёзном сбое пользователи теряют почти рабочий день только на ожидании. ТиИ не проводилось более двух лет, потому что не проходит: частичный прогон занимает выходные, полный не завершается. Проблема связана с долгими запросами по субконто.
Правильно
Заголовок раздела «Правильно»Минимальный регламент, который закрывает рекомендацию (значения — согласовать с бизнесом по каждой базе):
| Параметр | Что фиксируем | Ориентир |
|---|---|---|
| Целевой RTO | Согласованный с бизнесом допустимый простой при инциденте | Например, ≤ 2 ч для БП |
| Фактический RTO | Хронометраж полного restore по этапам: копирование бэкапа → restore СУБД → подключение ИБ → проверка входа | Замеряется при каждом тестовом restore |
| Тестовый restore | Периодичность, стенд, ответственный; результат — запись с фактическим временем | Ежемесячно |
| ТиИ | Безопасный сценарий (на копии либо в согласованное окно), состав проверок | Ежеквартально |
| Узкие места | Этапы, не укладывающиеся в целевой RTO / окно ТиИ | Отдельные задачи оптимизации |
Когда не применять
Заголовок раздела «Когда не применять»Для тестовых/временных баз без требований к доступности формальный RTO избыточен. Рекомендация касается боевых баз с обязательствами по восстановлению.