У каждой студии есть история про сайт, который пришлось собирать заново. Чаще всего она начинается одинаково: «у нас же были бэкапы у хостера». А потом выясняется, что хостер хранил копии семь дней, взлом произошёл три недели назад, а вредоносный код аккуратно попал во все доступные копии. Или копии делались, но только файлов, без базы данных. Или база копировалась, но архив оказался повреждён. Резервное копирование — одна из самых скучных и при этом самых важных задач в жизни сайта. Разберём, как сделать её правильно.
Что может уничтожить сайт
Резервные копии нужны не только на случай взлома. Причин потерять данные или работоспособность сайта гораздо больше, и большинство из них никак не связаны со злым умыслом.
Взлом
Вредоносный код, подмена страниц, удаление данных, шифрование файлов с требованием выкупа.
Человеческий фактор
Сотрудник удалил раздел каталога, менеджер случайно очистил базу клиентов, разработчик выполнил запрос не на той базе.
Неудачное обновление
Обновление CMS или модуля сломало сайт, а откатить изменения без копии невозможно.
Сбой хостинга
Отказ дисков, пожар в дата-центре, блокировка аккаунта, банкротство провайдера.
Человеческий фактор, кстати, — самая частая причина обращений за восстановлением в нашей практике. Импорт прайс-листа с неправильными настройками, который перезаписал цены у 8 000 товаров. Скрипт синхронизации, удаливший заказы за неделю. Контент-менеджер, который «почистил» медиатеку и удалил изображения, используемые на сотнях страниц. Во всех этих случаях спасала только свежая резервная копия.
Что именно нужно копировать
Сайт — это не одна папка с файлами. Чтобы восстановить его полностью, нужно несколько составляющих, и отсутствие любой из них превращает восстановление в многодневный проект.
База данных
Самая ценная и самая изменчивая часть. Здесь хранятся тексты страниц, товары, цены, заказы, клиенты, настройки CMS. В интернет-магазине база меняется каждые несколько минут: новые заказы, изменения остатков, регистрации. Потеря даже суток данных может означать потерянные заказы, которые уже оплачены.
Файлы сайта
Код CMS и шаблонов, загруженные изображения, документы, файлы товаров. Код меняется редко и обычно хранится в системе контроля версий. А вот загруженные пользователями и менеджерами файлы — изображения товаров, прайсы, сертификаты — нужно копировать регулярно: их невозможно восстановить из репозитория.
Конфигурация
Настройки веб-сервера, параметры PHP, задания планировщика, переменные окружения, ключи интеграций. Про них часто забывают, а потом при переезде на новый сервер неделю выясняют, почему не работает выгрузка в 1С. Хорошая практика — хранить описание конфигурации в документации или в репозитории.
Внешние данные
DNS-записи домена, настройки почты, учётные данные сервисов. Сами по себе они не хранятся на сервере сайта, но без них восстановленный сайт не заработает. Достаточно держать актуальный экспорт DNS-зоны и список подключённых сервисов.
Правило 3-2-1 и где хранить копии
Классический принцип надёжного резервного копирования звучит так: три копии данных, на двух разных типах носителей, одна из которых хранится вне основной площадки. Для сайта это переводится примерно так: рабочие данные на сервере, локальная копия на том же сервере или в той же инфраструктуре для быстрого отката и удалённая копия в независимом облачном хранилище у другого провайдера.
Почему важна независимость? Потому что в случае взлома злоумышленник, получивший доступ к серверу, может удалить и копии, лежащие рядом. Если хостинг-аккаунт заблокирован за неоплату или по ошибке, копии внутри него тоже недоступны. Удалённое хранилище с отдельными учётными данными, к которому сервер может только записывать, но не удалять, защищает от обоих сценариев.
| Место хранения | Плюсы | Минусы |
|---|---|---|
| Копии хостинг-провайдера | Ничего не нужно настраивать, быстрое восстановление | Короткий срок хранения, зависимость от провайдера, нет контроля |
| Копии на том же сервере | Мгновенный откат после неудачного обновления | Пропадают вместе с сервером, доступны взломщику |
| Объектное облачное хранилище | Независимость, дёшево, можно запретить удаление | Нужна настройка и контроль |
| Локальный компьютер владельца | Полный контроль | Ручной процесс, легко забыть, риск утери ноутбука |
Хранение в облачном объектном хранилище стоит недорого: для типичного сайта компании или магазина среднего размера это сотни рублей в месяц. Это несопоставимо с ценой восстановления сайта с нуля.
Как часто делать копии и сколько их хранить
Частота копирования определяется простым вопросом: сколько данных вы готовы потерять? Если сайт-визитка обновляется раз в месяц, ежедневной копии более чем достаточно. Если интернет-магазин принимает 200 заказов в день, потеря суток данных означает 200 заказов, по которым нет информации, — это неприемлемо.
| Тип сайта | База данных | Файлы | Глубина хранения |
|---|---|---|---|
| Сайт-визитка, лендинг | Раз в сутки | Раз в неделю | 30 дней |
| Корпоративный сайт с блогом | Раз в сутки | Раз в сутки (только изменения) | 30–60 дней |
| Интернет-магазин | Каждые 1–4 часа | Раз в сутки | 60–90 дней |
| Магазин с большим оборотом | Непрерывно (журнал транзакций) плюс ночная полная копия | Раз в сутки | 90 дней и ежемесячные архивы |
Глубина хранения не менее важна, чем частота. Взлом часто обнаруживается не сразу: вредоносный код может тихо работать неделями, рассылая спам или перенаправляя мобильных посетителей. Если хранить копии только 7 дней, все они окажутся заражёнными. Поэтому удобна схема ротации: ежедневные копии хранятся месяц, еженедельные — три месяца, ежемесячные — год.
Перед любыми рискованными действиями — обновлением CMS, массовым импортом товаров, изменением структуры базы, переездом — делайте внеплановую копию вручную, даже если ночная была несколько часов назад. Это занимает минуты, а экономит часы.
Непроверенная копия — не копия
Это главная мысль статьи. Мы видели десятки ситуаций, когда резервное копирование формально было настроено, но в нужный момент не помогло. Архив создавался, но был пустым из-за ошибки доступа. База копировалась в неправильной кодировке, и восстановленные тексты превращались в набор символов. Скрипт копирования сломался полгода назад после обновления сервера, и никто этого не заметил, потому что уведомления об ошибках уходили на почту уволившегося сотрудника.
Единственный способ убедиться, что копии работают, — регулярно восстанавливать из них сайт на тестовом сервере. Не просто проверять, что архив существует, а развернуть его, открыть сайт, оформить тестовый заказ, зайти в административную панель.
Автоматический контроль
Каждая копия проверяется скриптом: размер архива не меньше ожидаемого, архив распаковывается, дамп базы содержит нужные таблицы. При ошибке уведомление уходит ответственному.
Ежемесячная проверка
Свежая копия разворачивается на тестовом сервере. Проверяется, что сайт открывается, каталог и последние заказы на месте, изображения загружаются.
Квартальные учения
Полное восстановление по документированной инструкции, желательно силами специалиста, который не настраивал систему. Фиксируется, сколько времени заняло восстановление.
Обновление инструкции
Все найденные проблемы и неочевидные шаги вносятся в инструкцию по восстановлению. Она должна быть понятна человеку, который видит сайт впервые.
Время восстановления — отдельный важный показатель. Для небольшого сайта это может быть 30 минут, для крупного магазина с большой базой и тысячами изображений — несколько часов. Зная эту цифру заранее, вы сможете честно оценить последствия сбоя. Подробный план действий на случай аварии мы разобрали в статье «Восстановление сайта после сбоя».
Типичные ошибки владельцев сайтов
«Хостер делает бэкапы». Делает, но обычно с короткой глубиной, без гарантий и без возможности выбрать время копирования. Копии хостера — хороший дополнительный уровень, но не единственный.
Копии только файлов. Некоторые плагины и панели по умолчанию копируют только файловую систему. Без базы данных такая копия бесполезна для любого современного сайта.
Хранение копий в публичной папке. Архив сайта, лежащий в корне веб-сервера с предсказуемым именем, может скачать кто угодно — вместе с паролями от базы данных и персональными данными клиентов. Это не просто риск взлома, а потенциальное нарушение 152-ФЗ «О персональных данных».
Нет ответственного. Резервное копирование «настроил кто-то когда-то», и никто не получает уведомлений о сбоях. Должен быть конкретный человек или подрядчик, который отвечает за копии и регулярно отчитывается об их состоянии.
Нет шифрования. Копии с данными клиентов и заказов, хранящиеся во внешнем хранилище, нужно шифровать. Иначе утечка учётных данных хранилища превращается в утечку всей клиентской базы.
Чек-лист настройки резервного копирования
- Копируются и база данных, и загруженные файлы, и конфигурация сервера
- Частота копирования базы соответствует допустимой потере данных
- Минимум одна копия хранится у независимого провайдера с отдельными доступами
- Сервер не может удалить копии из удалённого хранилища
- Копии шифруются и не лежат в публичных папках сайта
- Глубина хранения — не меньше 30 дней, есть ежемесячные архивы
- Ошибки копирования приходят ответственному сразу
- Восстановление проверяется на тестовом сервере хотя бы раз в месяц
- Есть письменная инструкция по восстановлению и известно его время
Если половина пунктов вызывает сомнения, это повод разобраться сейчас, а не в день аварии. Настройка надёжного резервного копирования входит в нашу техническую поддержку с первого месяца работы.
Итог
Резервное копирование защищает не только от взлома, но и от собственных ошибок, неудачных обновлений и проблем у провайдера. Копировать нужно базу данных, загруженные файлы и конфигурацию, хранить копии в нескольких местах, включая независимое хранилище, а частоту выбирать по тому, сколько данных бизнес готов потерять. Самое главное — регулярно проверять восстановление: копия, из которой ни разу не поднимали сайт, — это надежда, а не защита.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
