Резервное копирование: стратегия, которая спасёт проект

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

От чего защищает резервная копия

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

• Человеческая ошибка. Сотрудник удалил категорию вместе с товарами, перезаписал описания неправильным файлом импорта, изменил настройки, которые невозможно вспомнить.
• Неудачное обновление. После установки новой версии движка или модуля сайт перестал открываться или разъехалась вёрстка.
• Сбой оборудования. Выход из строя диска на сервере, авария у хостинг-провайдера, блокировка аккаунта.
• Взлом и заражение. Вредоносный код внедрён в файлы или в базу данных.
• Ошибка при переезде или доработке. Разработчик что-то сломал, и нужно вернуть как было.
• Спорные ситуации. Нужно посмотреть, как выглядела страница или какими были цены на определённый момент.

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

Что именно нужно копировать

Сайт состоит из нескольких частей, и копировать нужно каждую из них. Типичная ошибка: сохранить только файлы или только базу, а потом выяснить, что по отдельности они бесполезны.

Файлы сайта

Сюда входят код движка, шаблон оформления, установленные модули, настройки и загруженные материалы: изображения товаров, документы, видео. Загруженные материалы часто занимают больше всего места и меняются чаще всего, поэтому именно с ними возникают сложности.

База данных

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

Конфигурация окружения

Менее очевидная часть: версии программного обеспечения на сервере, настройки веб-сервера, задания по расписанию, правила перенаправлений, настройки почты и сертификатов. Без этих сведений восстановление на новом сервере превращается в долгое выяснение, как всё было устроено. Достаточно вести краткий документ с перечнем настроек и актуальными версиями.

Сопутствующие данные

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

Правило, которое стоит запомнить

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

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

Самая распространённая ловушка: копии создаёт сам хостинг и хранит на том же сервере. Это удобно для быстрой отмены ошибки, но не спасает при проблемах с аккаунтом или с самим сервером. Автоматические копии хостинга хороши как дополнение, но не как единственная защита.

Как часто копировать и как долго хранить

Частота зависит от того, как быстро меняются данные и сколько работы вы готовы потерять. Ключевой вопрос такой: за сколько времени вы можете позволить себе потерять данные? Если магазин принимает десятки заказов в день, потеря суток равна десяткам потерянных заказов. Для сайта-визитки, который не меняется месяцами, достаточно гораздо более редкого копирования.

Многоуровневое хранение

Хранить только последнюю копию опасно. Если проблема возникла три дня назад, а вы заметили её сегодня, свежая копия уже содержит ошибку. Разумная схема: последние ежедневные копии за одну-две недели, еженедельные за пару месяцев, ежемесячные за полгода или больше. Так вы можете отмотать назад на разную глубину, при этом не храня бесконечный архив.

Полные и инкрементальные копии

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

Главное: копия, которую не проверяли, не считается копией

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

Чтобы этого избежать, проверяйте:

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

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

Процедура восстановления: пишем заранее

В момент аварии голова работает хуже, а времени мало. Поэтому порядок действий должен быть записан заранее и храниться не только на самом сайте. Ниже типовой план, который мы адаптируем под каждый проект.

Где хранить копии и как их защитить

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

• Не оставляйте архивы в открытых папках сайта и не называйте их предсказуемо: такие файлы находят автоматические сканеры.
• Защитите доступ к хранилищу паролем и вторым фактором.
• По возможности шифруйте архивы, особенно если храните их у стороннего провайдера.
• Разделите доступы: тот, кто пишет копии, не обязательно должен иметь право их удалять. Это защищает от ситуации, когда злоумышленник или вирус удаляет и сайт, и все копии одновременно.
• Если у вас есть данные о покупателях, учитывайте требования законодательства к их хранению и срокам. Подробнее в нашей статье о персональных данных.

Типичные ошибки

• Положились на копии хостинга. Они не гарантируются в каждом тарифе, хранятся недолго и пропадают вместе с аккаунтом.
• Копируют только по требованию. Вручную копию делают тогда, когда вспомнят, то есть нерегулярно. Автоматизируйте процесс.
• Не проверяют восстановление. Узнают о проблеме в момент аварии.
• Нет отдельной копии перед обновлениями. Откатиться оказывается не к чему.
• Забывают про изображения. Базу сохранили, а папка с фотографиями товаров осталась без копии, и в магазине появляются пустые карточки.
• Никто не отвечает. Все думают, что копированием занимается кто-то другой, и в итоге этим не занимается никто.

Чек-лист стратегии резервного копирования

• Копируются и файлы, и база данных, и список настроек окружения.
• Автоматические копии создаются по расписанию, подходящему вашему бизнесу.
• Минимум одна копия хранится вне основного сервера и вне аккаунта хостинга.
• Используется многоуровневое хранение: ежедневные, еженедельные, ежемесячные.
• Настроены уведомления об ошибках копирования.
• Раз в квартал проводится пробное восстановление.
• Есть письменная инструкция по восстановлению и понятно, кто ею занимается.
• Доступ к архивам защищён, а сами архивы зашифрованы.

Частые вопросы

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