Найти в Дзене

Бэкапы без мифов: RPO и RTO — что это и с чем едят?

Короткий разбор для владельцев сайтов и интернет-магазинов: что реально означает «мы делаем бэкапы», почему этого может быть недостаточно и как выбрать схему резервного копирования без самообмана. Почти у каждого проекта есть фраза-оберег: «У нас настроены бэкапы». Проблема в том, что она ничего не гарантирует, пока не ответили на два вопроса: сколько данных вы готовы потерять и сколько времени готовы быть офлайн. Эти два вопроса — это RPO и RTO. • RPO (Recovery Point Objective) — допустимая потеря данных во времени. Пример: RPO=15 минут означает, что при аварии вы готовы потерять изменения, сделанные за последние 15 минут. • RTO (Recovery Time Objective) — допустимое время восстановления. Пример: RTO=2 часа означает, что бизнес должен вернуться в работу максимум через 2 часа после сбоя. Если RPO и RTO не зафиксированы, «бэкап» превращается в лотерею: копия есть, но она слишком старая; или восстановление возможно, но занимает сутки — и это уже убытки. • «Бэкап раз в сутки — нормально»
Оглавление

Короткий разбор для владельцев сайтов и интернет-магазинов: что реально означает «мы делаем бэкапы», почему этого может быть недостаточно и как выбрать схему резервного копирования без самообмана.

Почти у каждого проекта есть фраза-оберег: «У нас настроены бэкапы». Проблема в том, что она ничего не гарантирует, пока не ответили на два вопроса: сколько данных вы готовы потерять и сколько времени готовы быть офлайн.

Эти два вопроса — это RPO и RTO.

• RPO (Recovery Point Objective) — допустимая потеря данных во времени. Пример: RPO=15 минут означает, что при аварии вы готовы потерять изменения, сделанные за последние 15 минут.

• RTO (Recovery Time Objective) — допустимое время восстановления. Пример: RTO=2 часа означает, что бизнес должен вернуться в работу максимум через 2 часа после сбоя.

Если RPO и RTO не зафиксированы, «бэкап» превращается в лотерею: копия есть, но она слишком старая; или восстановление возможно, но занимает сутки — и это уже убытки.

3 мифа, которые ломают ожидания

• «Бэкап раз в сутки — нормально» — Нормально только если вы готовы терять целый день заказов/лидов/изменений. Для активного магазина это обычно неприемлемо.

• «У хостинга же есть резервные копии» — Иногда есть, иногда нет; иногда они лежат рядом с тем же сервером; иногда их нельзя быстро развернуть. Это не ваша стратегия, а чужая опция.

• «Главное — сделать архив сайта» — Архив без базы данных (или без корректной процедуры восстановления) — это иллюзия. Восстанавливается не «файл», а работающий сервис: код + БД + конфиги + доступы.

Как выбрать схему: отталкивайтесь от сценария аварии

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

• Ошибка обновления / неудачная доработка:

– нужен быстрый откат (часто — на уровне файлов и БД);

– важно иметь точки восстановления перед релизом и после него;

– полезны тестовые контуры и контроль целостности.

• Вирус / компрометация

– нужны «чистые» копии (до заражения) и понимание момента проникновения;

– важно хранить резервные копии изолированно и ограничивать доступ;

– обязательно — проверка логов/изменений, иначе восстановите уже заражённое.

• Сбой инфраструктуры (диск, сервер, дата-центр)

– нужны копии вне основного узла (другой сервер/другой DC/офлайн);

– нужна автоматизация восстановления и регламент действий;

– важно заранее измерить реальное время поднятия проекта.

Мини-чеклист перед тем, как «настроить бэкапы»

• Какие данные критичны: заказы, оплаты, обращения, склад, контент, личные кабинеты?

• Какой максимальный простой приемлем: 30 минут, 2 часа, 1 день? Это и есть ваш RTO.

• Какую потерю данных вы переживёте: 5 минут, 1 час, 1 день? Это ваш RPO.

• Где лежат копии: на том же сервере или физически отдельно?

• Кто и как восстанавливает: есть ли пошаговая инструкция и доступы?

• Проверяли ли восстановление на тесте и сколько заняло по факту?

• Есть ли мониторинг резервного копирования и уведомления о сбоях?

Полный разбор с примерами схем, типовыми настройками и логикой выбора — в основной статье.

Если нужно сделать это «под ключ»

Ниже — услуги Cetera Labs, которые напрямую связаны с резервным копированием, восстановлением и контролем работоспособности.

Резервное копирование сайтов — Проектируем схему, настраиваем копирование файлов и баз данных, проверяем восстановление и фиксируем регламент.

Мониторинг сайтов 24/7 — Ловит падения, ошибки, недоступность и аномалии до того, как их заметит клиент или поисковик.

Информационная безопасность — Комплекс мер: мониторинг, антивирусная защита, контроль логов, тесты внешних интерфейсов, резервирование вне основной площадки.

Проверка сайта на уязвимости — Разовая проверка и/или постоянный контроль уязвимостей — чтобы бэкап не стал единственным планом защиты.

Восстановление сайта — Восстановление из резервных копий/архивов, разбор причин сбоя и возврат проекта в рабочее состояние.

Поддержка сайтов на 1С-Битрикс — Обновления, безопасность, регламент релизов, контроль интеграций и быстрое реагирование при инцидентах.