RPO и RTO (допустимая потеря данных и время восстановления)

Что такое RPO и RTO и на что они влияют

Оба термина пришли из планирования непрерывности. NIST SP 800-34 Rev. 1 определяет целевую точку восстановления (RPO) как момент времени, до которого нужно восстановить данные после сбоя, и связывает её с тем, какую потерю данных допускает бизнес-процесс. Целевое время восстановления (RTO) это максимальное время, в течение которого ресурс системы может быть недоступен, прежде чем последствия станут неприемлемыми. NIST вводит и третью величину, максимально допустимый простой (MTD), и отмечает, что RTO обычно должно быть меньше MTD.

Каждая величина определяет проектное решение. RPO задаёт, как часто делать копии или репликацию: при ночной копии вы теряете до суток изменений. RTO задаёт способ восстановления. В примерной таблице NIST системы с низким влиянием сопоставлены с простыми копиями и холодной площадкой, а системы с высоким влиянием с зеркальными системами и горячей площадкой. Варианты аварийного восстановления AWS идут от резервного копирования с восстановлением через pilot light и warm standby к схеме active/active на нескольких площадках, а стоимость и сложность растут.

Как измерить RPO и RTO тестом восстановления

Цели это решения, а тест восстановления показывает, что вы реально получаете. Восстановите данные в чистый каталог или на временный сервер и засеките время. С restic (см. руководство по резервному копированию):

# RPO: how old is the newest backup right now?
date -u
restic snapshots --json | jq -r 'max_by(.time).time'

# RTO: how long does the restore itself take?
time restic restore latest --target /srv/restore-test

Согласно документации restic по скриптам, time это момент начала копирования, поэтому более поздние изменения не учтены. Разрыв до текущего момента и есть ваша потеря в худшем случае.

Засекайте всё восстановление, а не только копирование. Условный пример, числа выдуманы: последняя копия начата в 02:00, сервер падает в 01:30 следующих суток, то есть потеряно 23,5 часа данных при цели RPO 4 часа: провал. Создание сервера 25 минут, восстановление 40, настройка 30 и проверки 15 дают 1 час 50 минут при цели RTO 4 часа: успех.

Ограничения и частые ошибки

• Зелёное задание копирования не равно RTO. Только замеренное восстановление, включая создание сервера, DNS и проверку приложения, показывает реальное время.
• Нуля не бывает. AWS отмечает, что даже при лучших практиках время восстановления и точка восстановления будут больше нуля, а при порче или удалении данных точка восстановления лежит до момента обнаружения проблемы.
• Репликация не резервная копия. Зеркало копирует удаление или шифрование за считаные мгновения. Держите копии на момент времени, лучше с одной, которую нельзя удалить с сервера, как подсказывают расширения правила 3-2-1.
• Одно число на всё. Базе данных и папке статики редко нужны одинаковые цели, поэтому задавайте их по сервисам.
• Забытые зависимости. Записи DNS, сертификаты, секреты и пароль от копии входят во время восстановления.
• Цели без бюджета. Более жёсткие цели требуют больше хранилища, резервных мощностей и усилий, поэтому запишите, за что вы решили платить.

RPO и RTO в рутине восстановления

Запишите цели по каждому сервису в короткий регламент. Расписание копирования выбирайте по RPO с запасом и настройте оповещение о пропущенном запуске: одна неудачная ночь молча удваивает реальный RPO. Способ восстановления выбирайте по RTO: скриптовая пересборка с восстановлением для часов, warm standby для минут.

Повторяйте тест восстановления по календарю, например раз в квартал и после крупных изменений инфраструктуры, и записывайте измеренное значение рядом с целью. Руководство CISA #StopRansomware также советует автономные зашифрованные копии и регулярную проверку их доступности и целостности. Измеренное RTO подсказывает, что обещать во время инцидента, а после восстановления нужно ещё доказать, что данные и сервисы в порядке, как описано в разделе восстановлено или проверено.

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

Связанные термины: Правило резервного копирования 3-2-1, Вымогатель, Восстановлено или проверено, Реагирование на инциденты, Object Lock.