RPO показывает, сколько последних данных бизнес готов потерять после сбоя. RTO — сколько времени допустимо потратить на восстановление работы сайта. Поэтому частоту бэкапов выбирают не «раз в сутки по привычке», а по скорости изменения данных и последствиям их потери.
Если заказы и заявки появляются постоянно, редкая копия базы оставляет слишком большой разрыв. Статичные файлы темы могут требовать другого графика. Сначала разделите данные сайта, задайте предел потери и простоя для каждой группы, а затем проверьте эти цели пробным восстановлением.
Чем RPO отличается от RTO
RPO (Recovery Point Objective) отвечает на вопрос: до какой точки во времени нужно восстановить данные. Фактически это допустимый объём изменений между последней пригодной копией и моментом сбоя.
RTO (Recovery Time Objective) отвечает на другой вопрос: за какое время сайт должен снова выполнять критические функции. В этот период входят обнаружение аварии, решение о восстановлении, подготовка среды, возврат данных и проверка результата.
Эти показатели нельзя заменять друг другом. Частые копии могут уменьшить потерю данных, но не ускорят развёртывание, если нет инструкции, доступов или свободного сервера. Быстрое переключение на реплику тоже не гарантирует сохранность: ошибочное удаление или повреждение может попасть на неё вместе с рабочими данными.
Сначала разделите данные сайта
У одного сайта редко бывает единый разумный RPO для всего содержимого. Составьте карту хотя бы из четырёх групп:
| Объект | Что меняется | Что проверить | |---|---|---| | База данных | заказы, заявки, пользователи, настройки CMS | консистентность копии, журналы транзакций, порядок восстановления | | Пользовательские файлы | изображения, документы, выгрузки | синхронизацию с базой, версии и срок хранения | | Код и конфигурация | релизы, шаблоны, правила веб-сервера | версию кода, зависимости и безопасное хранение секретов | | Внешние зависимости | DNS, CDN, почта, платёжные и другие сервисы | экспорт настроек, доступы, ответственных и порядок переключения |
Не включайте все объекты в одно правило только ради простоты. Потеря старого изображения и потеря новой заявки имеют разную цену, а значит, могут требовать разных способов защиты.
Как определить RPO для сайта
- Перечислите необратимые изменения. Отметьте данные, которые нельзя заново получить от клиента или восстановить из другого источника.
- Оцените последствия потери. Спросите владельца процесса, какой объём заказов, заявок, публикаций или настроек допустимо вводить повторно.
- Назначьте RPO каждой группе. Для базы, файлов и конфигурации цели могут отличаться.
- Сравните цель с реальной схемой. Учитывайте не только расписание, но и длительность копирования, задержку передачи, проверку целостности и возможный пропуск задания.
- Проверьте последнюю восстанавливаемую точку. Важна не дата создания архива, а самая свежая копия, из которой действительно можно вернуть согласованное состояние.
Если требуемый RPO короче интервала полных копий, рассмотрите инкрементальные копии или журналы транзакций. Конкретный вариант зависит от СУБД и хостинга. Репликация может помочь с доступностью, но не должна быть единственной защитой от удаления, повреждения или ошибки оператора.
Как определить RTO
Разложите восстановление на весь путь, а не только на распаковку архива:
- обнаружить сбой и подтвердить, что нужен откат;
- связаться с ответственным и получить разрешение на действие;
- подготовить сервер, сеть, доступы и нужные версии программ;
- получить копию из независимого хранилища;
- восстановить базу, файлы, код и конфигурацию в правильном порядке;
- проверить вход, формы, заказы, фоновые задачи и интеграции;
- переключить трафик и убедиться, что публичный сайт работает.
RTO должен опираться на время, измеренное во время учения. Оценка «обычно восстанавливаем быстро» не учитывает загрузку большого архива, поиск доступа, DNS-кэш, ручные шаги и проверку бизнес-функций.
Как связать цели с частотой бэкапов
Для каждого объекта запишите цепочку: данные → RPO → способ копирования → интервал → срок хранения → проверка → ответственный.
Интервал между пригодными точками восстановления не должен быть больше принятого RPO. При этом одного свежего архива мало: хранение нескольких версий защищает от ситуации, когда повреждение обнаружили не сразу, а отдельное хранилище снижает риск потерять оригинал и копию из-за одной аварии.
Частота не определяет RTO напрямую. На него влияют размер данных, пропускная способность, готовность резервной среды, совместимость версий, полнота инструкции и число ручных операций. Если сумма этих этапов не укладывается в цель, ускоряйте сам процесс восстановления, а не только расписание копий.
Минимальная карточка плана
Для каждой группы данных заполните короткую карточку:
- владелец данных и ответственный за восстановление;
- согласованные RPO и RTO;
- источник и место хранения копии;
- способ создания и проверки;
- срок хранения и число версий;
- необходимые доступы и зависимости;
- признаки, при которых запускают восстановление;
- дата последнего успешного учения и найденные ограничения.
Храните инструкцию отдельно от восстанавливаемого сервера. Если она исчезнет вместе с сайтом, план окажется недоступен именно в момент аварии.
Проверьте план пробным восстановлением
Разверните копию в изолированной среде, где тестовый сайт не отправит реальные письма, заявки или платежи. Зафиксируйте начало работ, ручные шаги, ошибки и момент, когда критические функции снова стали доступны.
Сравните фактическую точку данных с RPO, а полное время — с RTO. Проверьте не только главную страницу, но и авторизацию, формы, фоновые задания, загрузку файлов и важные интеграции. Подробный порядок есть в материале «Как проверить бэкап сайта пробным восстановлением».
После теста обновите инструкцию и устраните самый долгий или ненадёжный этап. Следующее учение должно подтвердить, что исправление сработало, а не просто повторить прежний сценарий.
Где помогает мониторинг, а где нет
Web-Puls может заметить внешнюю недоступность публичного URL и помочь зафиксировать начало и окончание инцидента. Мониторинг не видит содержимое резервной копии, не подтверждает целостность заказов и не заменяет пробное восстановление.
Начните с карты данных и одного изолированного теста. Если нужно спроектировать схему копирования или разобрать восстановление после сбоя, оставьте заявку на профессиональную поддержку: укажите публичный адрес сайта, затронутые данные и уже известные ограничения без паролей и закрытых ссылок.