Суть в 2 строках:
- RPO — сколько данных вы готовы потерять (в минутах/часах).
- RTO — сколько времени сайт может быть недоступен (в минутах/часах).
Если эти два числа не определены, «у нас есть бэкап» — это не стратегия, а надежда.
Почему «бэкап есть» часто не спасает
Типовая картина при аварии: сайт лежит, владелец просит «восстановите быстро», а дальше выясняется, что:
- копия делалась раз в сутки (а бизнес живёт по минутам);
- копия хранится на том же сервере или в том же аккаунте;
- восстановление никто никогда не тестировал;
- нет понимания, что важнее: данные или время простоя.
RPO/RTO нужны, чтобы заранее согласовать ожидания и техническую схему, а не спорить в момент инцидента.
Термины на человеческом языке
RPO (Recovery Point Objective) — «точка отката по данным»
Это максимально допустимая потеря данных по времени.
Пример: RPO = 30 минут. Если авария случилась в 12:00, то в худшем случае вы откатитесь к данным на 11:30 и потеряете всё, что было с 11:30 до 12:00:
RTO (Recovery Time Objective) — «время возврата в строй»
Это время, за которое сервис должен снова работать после инцидента.
Важно: «сервер подняли» не равно «сайт работает как бизнес». Обычно нужно проверить, что:
- сайт открывается;
- формы отправляются;
- админка доступна;
- интеграции не ломают заказы (оплаты/доставка/CRM);
- данные не повреждены.
Быстрая таблица последствий
| Параметр | Значение | Что это означает в реальности |
| RPO | 15 минут | Максимум потеряете данные за 15 минут работы |
| RPO | 1 час | Потеря часа заявок/заказов/изменений — это «нормально по договору» |
| RPO | 24 часа | Потеря суток — подходит только для нетранзакционных проектов |
| RTO | 30 минут | Нужна отлаженная процедура восстановления и часто отдельная инфраструктура |
| RTO | 4 часа | Реалистично для большинства бизнес-сайтов при грамотных бэкапах |
| RTO | 24 часа | Это не аварийное восстановление, а «когда руки дойдут» |
Какие инциденты закрывают бэкапы (и какие — нет)
Бэкапы помогают, когда:
- удалили/исказили контент или товары;
- обновление CMS/модуля сломало сайт;
- база данных повредилась;
- хостинг «упал»;
- файлы или таблицы зашифровали (если копии хранятся правильно).
Бэкапы не заменяют:
- защиту (обновления, доступы, WAF, антибот);
- мониторинг (чтобы узнать о проблеме сразу);
- отказоустойчивость (когда нужен RTO в считанные минуты).
Если нужен RTO «почти ноль», одними бэкапами не обойтись: потребуется кластер/репликация/горячий резерв — и всё равно бэкапы остаются обязательными (репликация размножает и ошибки тоже).
От бизнеса к цифрам: как поставить RPO/RTO без «пальцем в небо»
Шаг 1. Сколько стоит час простоя
Считайте по простому: реклама продолжает крутиться (или останавливается с задержкой), заявки/заказы не приходят, поддержка получает шквал сообщений, падает доверие.
Практическая оценка: стоимость простоя ≈ маржинальная прибыль/час + рекламный бюджет/час + стоимость «пожара» (люди/нервы/репутация).
Шаг 2. Сколько стоит потеря данных
Потеря данных — это не только «заявки пропали». Обычно следом идут ручной разбор по почте/мессенджерам, расхождения в оплатах и статусах, претензии клиентов, повторные отгрузки и возвраты.
Шаг 3. 7 вопросов, которые превращают «хочу надёжно» в требования
- Есть ли онлайн-оплаты?
- Сколько заказов/лидов в час?
- Что критичнее: данные или время?
- Есть ли дубль данных (CRM, почта, коллтрекинг)?
- Как часто меняется контент/цены/остатки?
- Какие интеграции нельзя просто «откатить» (оплаты/доставка/1С)?
- Кто конкретно восстанавливает и где инструкция?
Типовые ориентиры RPO/RTO по проектам
Это не «закон», а стартовая точка для разговора о рисках и бюджете.
| Тип проекта | Разумный RPO | Разумный RTO | Комментарий |
| Контент-сайт/витрина | 24 часа | 4–12 часов | Если нет критичных заявок и частых правок |
| Корпоративный сайт с лидами | 1–6 часов | 2–6 часов | Заявки важнее, чем кажется |
| Интернет-магазин | 15–60 минут | 1–4 часа | Иначе потери и хаос в заказах |
| Личный кабинет/портал | 5–30 минут | 30–120 минут | Там уже сервис, а не просто сайт |
Что именно бэкапить: чек-лист объектов
Частая ошибка: сохраняют «файлы сайта», а теряют бизнес-данные. Минимальный набор:
- база данных;
- uploads / пользовательские файлы (изображения, документы, медиа);
- конфигурация (веб-сервер, cron/агенты, переменные окружения);
- ключи и секреты (хранить отдельно и безопасно: токены, API-ключи, доступы);
- служебные данные по ситуации: очереди, поисковые индексы, кеши.
Если проект на CMS (например, 1C-Битрикс), чаще всего критично: база + upload + корректная процедура восстановления окружения.
Схемы резервного копирования: что выбрать
- «Раз в сутки на хостинге»
- Кому подходит: простой контент-сайт без постоянных заявок/оплат.
- Риски: RPO почти всегда сутки, RTO часто непредсказуем (особенно если восстановление вручную).
- Частые бэкапы базы + регулярные копии файлов
- Кому подходит: лидогенерация, магазины, сервисы.
- Логика: база меняется постоянно — её копируем чаще. Файлы меняются реже — можно реже, но стабильно.
- 3-2-1 — рабочая классика
- 3 копии (включая прод), 2 разных носителя/среды, 1 — вне площадки.
- Ключевое: «вне площадки» — не «в другом каталоге на том же сервере», а другая площадка/облако или хотя бы отдельный аккаунт и права.
- Offsite + неизменяемость (immutability) — защита от шифровальщиков
- Если злоумышленник может удалять копии, offsite без защиты — слабое место.
- Неизменяемость означает: копии нельзя удалить/перезаписать в течение заданного времени (policy).
- Репликация/кластер/горячий резерв — это не бэкап
- Это про доступность (RTO), а не про «вернуться к чистому состоянию».
- Репликация легко размножает ошибки, повреждение данных и шифрование — поэтому она дополняет, а не заменяет бэкапы.
Как выбрать схему: практическая матрица решений
| Условия | Рекомендация по схеме |
| Сайт-витрина, правки редкие | 1 раз/сутки + хранение 14–30 дней + 1 копия вне площадки |
| Есть лиды/формы, но без оплат | База каждые 1–6 часов + файлы 1 раз/сутки + offsite |
| Интернет-магазин, заказы постоянно | База каждые 15–60 минут + файлы 1–6 часов + offsite + защита от удаления |
| Нужен RTO < 1 часа | Добавить отказоустойчивость/горячий резерв + строгий регламент + регулярные тесты |
| Требования к защите от взлома высокие | Offsite + неизменяемые копии + раздельные доступы + аудит действий |
Частота, хранение, доступы: минимум, который реально работает
Частота:
- База: от 15 минут до 6 часов — в зависимости от RPO.
- Файлы: от 1 часа до 24 часов — в зависимости от активности загрузок/контента.
- Важно: частоту выбирают не «как удобно», а чтобы она попадала в RPO.
Хранение (retention):
Практичный вариант для большинства проектов:
- ежедневные — 7–14 дней;
- недельные — 4–8 недель;
- месячные — 3–6 месяцев (если нужно для разборов/регуляторики).
Доступы и безопасность:
- отдельные учётные записи/ключи для хранилища;
- минимальные права (не всем — удаление);
- 2FA, аудит действий;
- отдельное хранение секретов (чтобы восстановление не упёрлось в «где токен оплаты?»).
Тест восстановления: единственный честный способ узнать свой RTO
Бэкап считается рабочим только если вы восстановились на тестовом окружении и проверили контрольные точки.
Как тестировать без риска
- Поднять стенд (копию окружения).
- Восстановить базу и файлы из выбранной копии.
- Пройти чек-лист проверки: сайт, админка, формы, заказы (тест), критичные интеграции, целостность данных.
- Зафиксировать фактическое время восстановления и проблемы.
Как часто
- Минимум раз в квартал.
- Обязательно после крупных обновлений, миграций, смены хостинга, внедрения интеграций.
Что делать при аварии: короткий регламент (runbook)
- Фиксация: время, симптомы, что менялось перед падением.
- Стоп изменений: заморозить деплой и ручные правки, ограничить доступы при подозрении на взлом.
- Классификация: ошибка обновления / сбой хостинга / подозрение на взлом / повреждение базы.
- Решение: откат релиза / восстановление из копии / перенос на резерв.
- Проверка бизнеса: формы, корзина/заказ, оплаты (статусы), доставка, CRM/1С/почта.
- Пост-инцидент: выводы, изменение схемы бэкапов и доступов, обновление инструкции восстановления.
Типовые ошибки, из-за которых бэкапы не спасают
- копии хранятся на том же сервере или в том же аккаунте;
- бэкап есть, но никто не знает, как восстановить;
- копируют только файлы без базы (или наоборот);
- не копируют uploads, теряют изображения/документы;
- нет защиты от удаления/шифрования копий;
- «RTO на словах», а по факту восстановление занимает сутки;
- нет мониторинга бэкапов (копирование тихо падает неделями).
Чек-лист «минимально нормально»
- RPO и RTO зафиксированы (хотя бы ориентиры).
- Бэкапится база + uploads + конфиги для восстановления.
- Есть копия вне площадки.
- Доступ к хранилищу ограничен, включена 2FA.
- Понятна частота и срок хранения копий.
- Есть инструкция восстановления (короткая, пошаговая).
- Назначен ответственный (поимённо).
- Есть регулярный тест восстановления и протокол результата.
- Есть мониторинг успешности бэкапов и уведомления о сбоях.
- После релизов/интеграций — внеплановый тест.
FAQ: короткие ответы
Что важнее — RPO или RTO?
Зависит от бизнеса: магазину часто важны оба; витрине обычно важнее RTO; сервису/личному кабинету чаще критичны оба.
Если у меня репликация, бэкапы не нужны?
Нужны. Репликация повышает доступность, но может размножить ошибки и шифрование. Бэкапы нужны, чтобы вернуться к чистому состоянию.
Можно ли просто откатиться после взлома?
Только если копии защищены от удаления/шифрования и хранение отделено от прод-доступов. Иначе злоумышленник часто уничтожает копии.
Как часто делать бэкап базы интернет-магазина?
Обычно каждые 15–60 минут. Если заказов мало — можно реже, но это решение должно вытекать из RPO.
Сколько хранить бэкапы?
Минимум 14–30 дней для ежедневных, плюс недельные/месячные по необходимости. Дольше — если есть юридические причины или длинные расследования.
Что бэкапить в первую очередь: файлы или базу?
Для бизнеса почти всегда база критичнее (заказы, заявки, пользователи). Но без uploads восстановление может быть «формально успешным», а по факту сайт будет без контента.
Как понять, что мои бэкапы реально работают?
Сделать тест восстановления на стенде и измерить фактический RTO.
Вывод
Правильные бэкапы — это система: цели (RPO/RTO), схема хранения (включая offsite и защиту), регламент восстановления и регулярные тесты. Если один из элементов отсутствует, риск «не восстановиться вовремя» остаётся высоким.
