Disaster recovery: план восстановления сервиса, RTO и RPO на практике

Прямой ответ

Disaster recovery — заранее подготовленный план восстановления сервиса после потери данных или инфраструктуры. Он описывается двумя числами, и без них план невозможно ни составить, ни проверить.

RTO (Recovery Time Objective) — максимально допустимое время простоя. Отвечает на вопрос «как быстро сервис должен снова работать».

RPO (Recovery Point Objective) — максимально допустимый объём потерянных данных. Отвечает на вопрос «сколько данных можно потерять».

Пример: RTO = 4 часа, RPO = 15 минут означает, что сервис должен подняться за четыре часа, а потеря данных не должна превышать последние пятнадцать минут.

Целевые значения определяют подход:

Чем меньше RPO, тем дороже решение. Нулевой RPO требует синхронной репликации, которая влияет на задержку записи, и подходит не всем системам.

WAL-архивирование в PostgreSQL обеспечивает восстановление на момент времени (PITR):

# postgresql.conf
archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'

Полная копия создаётся через pg_basebackup, а WAL-сегменты непрерывно копируются в архив. Восстановление выполняется на полный архив с указанием целевого момента:

restore_command = 'cp /archive/%f %p'
recovery_target_time = '2026-10-21 09:30:00+03'

Ключевой принцип: непроверенная копия не является резервной. Факт создания файла не означает, что из него можно восстановить работающую базу. О стратегиях хранения копий — в статье про правило 3-2-1.

Состав плана восстановления

Работающий план — документ с командами и временем, а не описание намерений. Минимальный состав:

Область восстановления. Какие системы восстанавливаются и в каком порядке. База данных без схемы приложения и секретов не даёт работающего сервиса, поэтому порядок определяется зависимостями.

Роли и контакты. Кто выполняет восстановление, кто принимает решение о переключении, кто уведомляет пользователей. В момент инцидента поиск ответственного занимает время, которое входит в RTO.

Команды по шагам. Фактические команды с указанием узла и времени выполнения каждого шага. Описание «восстановить из копии» не выполняет восстановление.

Критерии успеха. Контрольные запросы, подтверждающие целостность данных: число записей в ключевых таблицах, дата последней транзакции, отсутствие ошибок в журнале.

Точка невозврата. Момент, после которого возврат к прежнему состоянию невозможен. Решение о переключении принимается до этой точки.

Процедура возврата. Возврат на основную площадку сложнее восстановления: он требует переноса данных, накопленных на резерве, и отдельной проверки.

Журнал проверки. Дата, длительность, результат, замечания. Журнал — единственное доказательство того, что план проверялся, а не существовал на бумаге.

Практика: составление и проверка плана восстановления

1. Зафиксируйте RTO и RPO по системам. Разные системы имеют разные требования: база заказов и внутренний справочник не могут иметь одинаковые целевые значения.

2. Выберите подход под RPO. Для минутного RPO достаточно WAL-архивирования; о механизме — в статье про PITR в PostgreSQL.

3. Опишите процедуру по шагам. Документ с командами, а не описанием. В момент инцидента времени на импровизацию нет; о формате — в статье про runbook.

4. Проверяйте восстановление регулярно. Раз в квартал восстанавливайте копию на отдельный стенд и проверяйте целостность данных.

5. Измеряйте фактическое время. Реальное время восстановления сравнивается с целевым RTO; превышение означает, что план нужно пересмотреть.

6. Автоматизируйте проверку копий. Задача, которая восстанавливает последнюю копию на временный стенд и выполняет контрольные запросы, обнаруживает повреждение до инцидента.

7. Храните копии в отдельном месте. Копия на том же диске не защищает от потери диска; о правиле — в статье про 3-2-1.

Рекомендации:

1. Не обещайте RPO = 0 без необходимости. Синхронная репликация добавляет задержку записи и стоимость, которые нужны не всем системам.
2. Учитывайте зависимости. Восстановление базы без восстановления схемы приложения и секретов не даёт работающего сервиса.
3. Проверяйте права доступа к архиву. Копия, которую не может прочитать дежурный, бесполезна в момент инцидента.
4. Ведите журнал проверок. Дата, длительность, результат, замечания — основание для оценки готовности.
5. Обновляйте план при изменении архитектуры. Новая таблица, новый сервис или новая база требуют обновления процедуры.

Практический сценарий: проверка восстановления выявила неработающий архив WAL

Контекст: план восстановления существовал в документации, а WAL-архивирование было включено полгода назад. Проверка выполнялась впервые.

1. Диагностика. При попытке восстановления на временный стенд выяснилось, что архив содержит WAL-сегменты только за последние два дня. Параметр archive_command ссылался на каталог, который очищался задачей ротации логов.
2. Причина. Архивирование было включено формально: команда выполнялась без ошибок, но файлы попадали в каталог, подлежащий очистке. Ошибок в журнале это не порождало, поскольку копирование завершалось успешно.
3. Действия. (а) Каталог архива перенесли на отдельный том, не участвующий в ротации; (б) добавили задачу, проверяющую наличие свежего сегмента в архиве и поднимающую тревогу при его отсутствии; (в) процедуру восстановления переписали с фактическими командами и временем каждого шага; (г) провели повторную проверку: восстановление заняло 2 часа 40 минут при целевом RTO 4 часа; (д) проверку внесли в календарь как ежеквартальную.
4. Результат. Фактический RPO сократился с двух дней до 15 минут, а план восстановления перестал быть документом и стал проверенной процедурой.

Вывод: включённое архивирование не означает работающее. Реальный RPO определяется тем, что фактически лежит в архиве, а готовность к инциденту — тем, сколько времени занимает восстановление на практике, а не по оценке в документации.

FAQ

Как выбрать RTO и RPO? Исходя из стоимости простоя и стоимости потери данных для бизнеса. Технические решения подбираются под выбранные значения, а не наоборот.

Достаточно ли реплики вместо резервных копий? Нет. Реплика мгновенно воспроизводит ошибочное удаление данных. Копия защищает от логических ошибок, реплика — от потери узла.

Как часто проверять восстановление? Минимум раз в квартал, а также после существенных изменений архитектуры. Проверка должна включать контрольные запросы к данным.

Что делать, если восстановление дольше целевого RTO? Пересмотреть подход: параллельное восстановление, более свежие полные копии, предварительная подготовка стенда. Увеличение целевого значения — последний вариант.

Источники: PostgreSQL docs (WAL-архивирование, pg_basebackup), Google SRE Book — ссылки в шапке.