Резервное копирование сайта: регламент и периодичность

Резервное копирование считается настроенным, если выполнены четыре условия: копируются и файлы, и база данных; копии хранятся вне сервера сайта; задана глубина хранения; проведено пробное восстановление. Отсутствие любого из четырёх означает, что копий фактически нет. Ниже — состав, периодичность и порядок проверки.

Что входит в состав копии

Копия состоит из трёх частей, и потеря любой делает восстановление неполным.

База данных. Заказы, товары, пользователи, тексты страниц, настройки. Это то, что меняется ежедневно и чего нет нигде больше.

Загруженные файлы. Изображения товаров, документы, вложения из заявок. Хранятся отдельно от кода и в код не попадают.

Исходный код и конфигурация. Собственно сайт и файл с переменными окружения — адресами баз, ключами платёжного сервиса, токенами. Ключи хранятся отдельно от остального архива.

Периодичность

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

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

Где хранить

Правило простое: копия не хранится там же, где сайт. Архив в соседней папке на том же сервере не является резервной копией, потому что теряется вместе с сервером и вместе с учётной записью.

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

Хранилище оформляется на владельца бизнеса. Это тот же принцип, что с доменом: платит и распоряжается одно и то же лицо.

Глубина хранения

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

Длинная глубина нужна не для аварий. Аварию замечают в тот же час. Она нужна для тихих поломок: например, при выгрузке нового прайса перезаписались описания половины карточек, и обнаружилось это, когда покупатель написал в поддержку через месяц.

В магазине «Жук и Плут» импорт с Wildberries вынесен в отдельную вкладку админки и трогает большой объём карточек за один запуск. Именно для таких операций месячная глубина оправдывает себя: восстанавливать нужно не сайт целиком, а состояние каталога на дату до запуска импорта.

Порядок проверки восстановления

Копия, которую ни разу не разворачивали, копией не является. Проверка выполняется раз в квартал в следующем порядке.

1. Выбирается копия недельной давности, а не последняя.
2. Разворачивается тестовая площадка, отдельная от рабочего сайта и закрытая от индексации.
3. Восстанавливается база данных, затем файлы, затем код.
4. Проверяется: открывается ли главная, работает ли вход в админку, на месте ли последние заказы и последние загруженные изображения.
5. Фиксируется затраченное время. Это и есть реальный срок восстановления сайта, о котором имеет смысл говорить.
6. Тестовая площадка удаляется.

Практический результат первой такой проверки почти всегда один: обнаруживается, что в копию не попадала одна из трёх частей. Чаще всего — загруженные файлы.

Чего копирование не покрывает

Резервная копия защищает от потери данных. Она не защищает от четырёх других сценариев, и их закрывают отдельно.

Взлом. Копия вернёт файлы, но не закроет вход. Если причину не найти, следующая копия будет уже с закладкой.

Утечка. Восстановление не отменяет того, что данные скопированы третьим лицом. Здесь работает не копирование, а разграничение прав и шифрование чувствительных полей.

Ошибка в логике. Если сайт три месяца неправильно считал скидку, откат вернёт вас в состояние с той же ошибкой.

Потеря доступа к домену. Домен не входит в копию. Оформленный на подрядчика домен теряется независимо от того, сколько у вас архивов.

Кто и что делает по регламенту

Ответственность разделяется на три роли, и в малом бизнесе две из них часто совмещены. Это допустимо, но фиксировать их всё равно нужно письменно.

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

Исполнитель по сопровождению. Настраивает расписание, следит за тем, что копии создаются, проводит квартальную проверку, уведомляет владельца о сбоях копирования в течение суток.

Хостинг-провайдер. Отвечает только за собственные копии в объёме своего тарифа. Его копии не заменяют внешнее хранилище и не входят в зону ответственности исполнителя.

Отдельный пункт: при смене подрядчика доступ прежнего исполнителя к хранилищу отзывается, а сами копии остаются на месте и передаются вместе с проектом. Копии, лежащие на учётной записи прежнего разработчика, при расставании пропадают чаще, чем код.

Когда всё это избыточно

Сайт-визитка из пяти страниц, который не меняется месяцами и не собирает данных, не требует отдельного регламента. Достаточно копий хостинга и хранения кода в репозитории.

Суточная периодичность на сайте, куда добавляют по одной новости в квартал, создаёт расходы на хранение и ничего не защищает. Периодичность привязывается к частоте изменений, а не к статусу проекта.

Коротко

Копия состоит из базы, файлов и кода, и хранится вне сервера сайта. Периодичность определяется допустимым объёмом потерь: для магазина это сутки, для визитки — неделя. Глубина хранения нужна не для аварий, а для ошибок, которые обнаруживают поздно. Раз в квартал копия разворачивается на тестовой площадке — до этой процедуры считать резервное копирование настроенным нельзя.