Резервная копия сайта и резервный сайт: в чём разница

Два вопроса, которые стоит задать подрядчику

Инженеры называют их RPO и RTO, но суть понятна без терминов:

• Сколько данных мы можем потерять? Если бэкап делается раз в сутки, при аварии пропадёт всё, что изменилось после последней копии, — до суток заказов, правок и заявок.
• Через сколько сайт снова откроется? Восстановление из бэкапа — это новый сервер, настройка, перенос файлов и базы, смена DNS. Реалистично — часы, иногда сутки. Резервный сайт уже развёрнут, переключение подготовленного резерва занимает до 15 минут.

Две цифры, которые решают всё: RTO и RPO

У любого способа защиты есть две характеристики, и подрядчик обязан назвать обе. RTO (recovery time objective) — через сколько сайт снова работает после сбоя. RPO (recovery point objective) — сколько данных вы теряете: всё, что изменилось после последней копии. Бэкап раз в сутки — это RPO до 24 часов. Восстановление из архива на новый сервер — это RTO в часы, а если сервер ещё надо купить и настроить — в дни. Резервный сайт даёт RTO в минуты при том же RPO; поднять RPO до часа — вопрос частоты синхронизации. Спросите у вашего подрядчика эти две цифры — и вы сразу поймёте, что у вас есть на самом деле.

Сравнение вариантов

Правило 3-2-1

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

Когда достаточно бэкапа

• Сайт-визитка, заявок с него немного.
• Реклама на сайт не ведёт.
• Час или день простоя ничего не стоит бизнесу.

Когда нужен резервный сайт

• На сайт ведёт платная реклама — каждая минута простоя оплачена.
• Заявки или заказы приходят ежедневно.
• Сайт, DNS, почта и сервисы на нём зависят от одного-двух поставщиков.
• Вы уже переживали сбой и не хотите повторения.

Как проверить, что бэкап вообще рабочий

1. Узнайте дату последней копии и где именно она лежит.
2. Убедитесь, что копируются и файлы, и база данных — по отдельности они бесполезны.
3. Хотя бы раз в квартал восстанавливайте сайт из копии на тестовом сервере.
4. Держите хотя бы одну копию не у основного хостера.

Как мы проверяем, что резерв рабочий

Копию открываем через hosts на своих машинах, проходим ключевые страницы и отправляем форму. Затем — учебное переключение в тихое время: отключаем основной сервер на тесте, фиксируем, когда мониторинг объявил сбой, когда поменялась A-запись, когда копия открылась из нескольких сетей, дошла ли заявка в Telegram, когда вернулись обратно. Эти времена попадают в протокол, который вы получаете на руки.