Резервная копия, из которой нельзя восстановить сайт, — это просто архив на диске. Объясняем, как построить стратегию бэкапов, которая выручит при сбое, взломе или ошибке сотрудника, и как её регулярно проверять.
Когда бэкап внезапно становится самым ценным активом
О резервном копировании вспоминают в двух случаях: когда настраивают сайт и когда уже поздно. Между этими моментами может пройти несколько лет, и всё это время компания уверена, что «бэкапы у хостера есть». А потом выясняется, что хостер хранит копии только семь дней, заражение произошло три недели назад, а все доступные версии уже содержат вредоносный код.
Реальные сценарии, в которых нас просили восстановить сайт:
- контент-менеджер удалил раздел каталога с 1 400 товарами, перепутав кнопки массовых действий;
- обновление модуля сломало структуру базы данных, откатить изменения штатно не удалось;
- на сервере вышел из строя диск, а копии хранились на том же сервере;
- сайт взломали, и злоумышленник зашифровал файлы с требованием выкупа;
- подрядчик, у которого был единственный доступ к серверу, перестал выходить на связь, а хостинг заблокировали за неоплату.
В каждой из этих историй исход определяла не техническая квалификация тех, кто восстанавливал, а то, была ли заранее продумана стратегия копирования.
Правило 3-2-1 и его современная версия
Классический принцип, проверенный десятилетиями: три копии данных, на двух разных типах носителей, одна из которых находится вне основной площадки. Для сайта это можно перевести так: рабочий сервер, копия у хостинг-провайдера и копия в независимом хранилище у другого провайдера.
Современная версия добавляет ещё два пункта — правило 3-2-1-1-0:
- Одна копия неизменяемая или отключённая от сети. Её невозможно удалить или зашифровать, даже получив доступ к основному серверу. Многие объектные хранилища поддерживают режим блокировки объектов на заданный срок.
- Ноль ошибок при проверке восстановления. Копии регулярно проверяются на то, что из них действительно можно поднять рабочий сайт.
Звучит как избыточная предосторожность для корпоративного сайта, но стоимость хранения нескольких десятков гигабайт в объектном хранилище несопоставима со стоимостью потери каталога или истории заказов.
Что именно копировать
Сайт — это не одна папка. Чтобы восстановление было полным, копировать нужно несколько составляющих, и у каждой свой ритм изменений.
| Компонент | Что включает | Как часто меняется | Рекомендуемая частота копирования |
|---|---|---|---|
| База данных | Страницы, товары, заказы, пользователи, настройки | Постоянно | От ежедневно до каждого часа |
| Загруженные файлы | Изображения, документы, прайс-листы | Ежедневно | Ежедневно, инкрементально |
| Код сайта | Шаблоны, модули, доработки | При релизах | Система контроля версий плюс копия при каждом релизе |
| Конфигурация сервера | Настройки веб-сервера, PHP, крон-задачи, SSL | Редко | После каждого изменения |
| Почта и DNS-записи | Почтовые ящики на домене, записи зоны | Редко | Экспорт раз в квартал и при изменениях |
Частота копирования базы данных зависит от того, сколько данных вы готовы потерять. Для корпоративного сайта, где новости публикуются пару раз в неделю, ежедневной копии достаточно. Для интернет-магазина или B2B-портала, где каждый час приходят заказы, потеря суток — это потерянные деньги и испорченные отношения с клиентами. Здесь нужна копия минимум каждый час или непрерывная репликация базы.
Два показателя, от которых строится стратегия
В профессиональной среде стратегию резервного копирования описывают двумя метриками. Их стоит обсудить с руководством и зафиксировать письменно.
RPO — допустимая потеря данных
Recovery Point Objective — за какой период вы готовы потерять изменения. Если RPO равно 24 часам, достаточно ежедневной копии. Если 1 часу — копировать надо каждый час. Чем меньше RPO, тем дороже и сложнее инфраструктура.
RTO — допустимое время восстановления
Recovery Time Objective — как долго сайт может быть недоступен. Восстановить корпоративный сайт на 20 ГБ из копии в удалённом хранилище — это несколько часов: скачать архив, развернуть, проверить. Если бизнес допускает не более 30 минут простоя, нужен резервный сервер в режиме ожидания с актуальной репликой данных.
Типичные ориентиры, которые мы используем в проектах:
- Корпоративный сайт, лендинг: RPO 24 часа, RTO 4–8 часов.
- Сайт-каталог с обменом с учётной системой: RPO 12–24 часа, RTO 2–4 часа.
- Интернет-магазин, B2B-портал: RPO 1 час и меньше, RTO 1–2 часа.
Где хранить копии
Главная ошибка — хранить резервные копии на том же сервере, что и сайт. При отказе диска, взломе или блокировке аккаунта вы теряете и сайт, и копии одновременно.
- Локальные копии на сервере — только для быстрого отката при неудачном обновлении. Хранятся 2–3 дня.
- Копии у хостинг-провайдера — удобно, но зависит от одного поставщика. Уточните глубину хранения и стоимость восстановления.
- Независимое внешнее хранилище — объектное хранилище у другого провайдера. Основная страховка. Доступ к нему должен быть только на запись с сервера, без права удаления.
- Архив на стороне компании — ежемесячная полная копия, скачанная на корпоративное хранилище. Защита от ситуации, когда проблемы возникли со всеми внешними поставщиками одновременно.
Глубина хранения тоже важна. Мы рекомендуем схему «дед — отец — сын»: ежедневные копии хранятся 14 дней, еженедельные — 2 месяца, ежемесячные — год. Это позволяет откатиться к состоянию до заражения, даже если его обнаружили через несколько недель.
Совет студии: шифруйте резервные копии перед отправкой во внешнее хранилище и храните ключ шифрования отдельно от копий. В базе сайта лежат персональные данные клиентов, и утечка бэкапа ничем не лучше утечки с самого сайта.
Проверка восстановления: шаг, который пропускают все
Резервная копия, из которой ни разу не восстанавливались, — это гипотеза, а не страховка. За годы практики мы встречали всё: архивы нулевого размера из-за закончившегося места на диске, дампы базы, обрывающиеся на середине, копии без загруженных файлов, потому что скрипт исключал «слишком большие» папки, и копии, для восстановления которых нужна версия СУБД, которой уже нет.
Как организовать проверку:
- Автоматический контроль после каждого копирования: размер архива не меньше ожидаемого, архив распаковывается, дамп базы читается без ошибок. При отклонении — уведомление ответственному.
- Ежемесячное тестовое восстановление на отдельном сервере: развернуть сайт из копии, открыть ключевые страницы, войти в админ-панель, проверить последние записи в базе.
- Ежегодные «учения» с замером реального времени восстановления и сравнением с целевым RTO.
- Документированная инструкция по восстановлению, по которой может действовать человек, не участвовавший в настройке.
Пример из практики: на сайте производителя бытовой химии мы при первом тестовом восстановлении обнаружили, что копии базы полгода создавались в кодировке, из-за которой вся кириллица превращалась в нечитаемые символы. Формально бэкапы делались каждую ночь, по факту восстановить из них сайт было невозможно. Проблему исправили за час — но только потому, что её нашли на учениях, а не во время аварии.
Кто за это отвечает
Резервное копирование часто оказывается «ничьей» задачей: хостер думает, что за это отвечает подрядчик, подрядчик — что хостер, а компания уверена, что всё настроено. Закрепите ответственность письменно: кто настраивает копирование, кто получает уведомления об ошибках, кто и как часто проверяет восстановление, у кого хранятся доступы к внешнему хранилищу. Если у вас нет собственного администратора, эти обязанности можно включить в договор поддержки сайта с ежемесячным отчётом о проверках.
Чек-лист стратегии резервного копирования
- Зафиксированы целевые RPO и RTO для вашего сайта.
- Копируются база данных, файлы, код, конфигурация сервера и DNS-записи.
- Частота копирования базы соответствует RPO.
- Минимум одна копия хранится у другого провайдера, вне основного сервера.
- Одна копия защищена от удаления и изменения.
- Настроена ротация: ежедневные, еженедельные и ежемесячные копии.
- Копии зашифрованы, ключ хранится отдельно.
- После каждого копирования автоматически проверяется целостность архива.
- Раз в месяц проводится тестовое восстановление.
- Есть письменная инструкция по восстановлению и назначен ответственный.
Хорошая стратегия резервного копирования незаметна годами, но в день аварии она окупает себя полностью.
