Резервная копия нужна до изменения, а не после ошибки
Когда интернет-магазин уже работает, любое серьезное изменение затрагивает не пустой сайт. В нем есть товары, настройки, изображения, заказы, модули и данные, которые могли накапливаться месяцами. Если обновление или правка пройдет неудачно, восстанавливать все вручную может быть намного сложнее, чем заранее сохранить рабочую версию.
Особенно важно сделать копию перед обновлением CMS, установкой нового модуля, сменой версии PHP, изменением базы данных, большим импортом товаров или переносом интернет-магазина на другой хостинг.
Что должно входить в резервную копию интернет-магазина
Файлы сайта
CMS, тема оформления, модули, изображения, конфигурационные файлы, robots.txt, .htaccess и другие файлы проекта.
База данных
Товары, категории, настройки, заказы и другая информация, которая хранится в базе, а не в папках сайта.
Настройки окружения
Версия PHP, нужные расширения, задачи cron и важные параметры сервера полезно записать отдельно, если от них зависит работа магазина.
Дата и назначение копии
Из названия должно быть понятно, когда копия создана и перед каким изменением. Это помогает не восстановить случайно старую версию.
Почему архива с файлами недостаточно
У многих CMS основная часть данных магазина находится в базе. Если сохранить только папку сайта, после восстановления можно получить старые файлы с пустой или поврежденной базой. Товары, заказы и настройки из нее сами не вернутся.
Обратная ситуация тоже возможна. Один дамп базы не восстановит тему, изображения, установленные модули и изменения в файлах. Для полноценной копии обычно нужны обе части: файлы и база данных.
Копия на том же сервере не защищает от всех проблем
Архив внутри того же аккаунта помогает быстро откатить отдельную правку. Но если проблема затронет сам хостинг, диск или доступ к аккаунту, такая копия может оказаться недоступной вместе с сайтом.
Перед серьезными работами разумно иметь отдельную копию вне рабочей папки магазина. Это может быть локальный компьютер или другое защищенное хранилище, к которому есть доступ независимо от текущего сервера.
Как понять, что резервная копия действительно рабочая
Сам факт наличия ZIP и SQL-файла еще не гарантирует восстановление. Архив должен открываться без ошибки, а дамп базы не должен быть пустым или обрываться в середине. Для важных проектов копию лучше хотя бы выборочно проверить.
Самая надежная проверка - развернуть копию в отдельном тестовом месте и убедиться, что сайт запускается. Это особенно важно перед крупным обновлением, после которого откат должен быть быстрым.
Резервная копия и автоматический бэкап - не одно и то же
Автоматическое копирование по расписанию полезно для работающего магазина. Но перед конкретной технической работой все равно нужна свежая точка восстановления, созданная непосредственно перед изменением. Тогда понятно, к какой версии нужно вернуться.
Когда лучше делать копии
Частота зависит от того, как быстро меняются данные. Магазин без новых заказов и редких изменений можно копировать реже. Если ежедневно появляются заказы, меняются остатки и добавляются товары, слишком старая база уже не отражает текущее состояние.
Отдельная копия нужна непосредственно перед доработкой интернет-магазина, обновлением CMS, изменением шаблона, установкой модуля, массовым импортом и другими операциями, которые могут затронуть несколько частей сайта.
Что делать с новыми заказами во время больших работ
Если магазин продолжает принимать заказы, нужно учитывать момент создания копии. Например, резервная база сделана утром, а перенос завершен вечером. За это время могли появиться новые заказы, которые нельзя потерять.
Для таких работ заранее определяется момент финальной синхронизации базы. Иногда на короткое время ограничивают изменения, иногда переносят только свежие данные перед переключением. Схема зависит от CMS и того, какие данные менялись во время работ.
Восстановление должно возвращать одну согласованную версию
Если файлы сохранены в один день, а база - в другой, после восстановления версии могут не совпасть. Новый модуль может ожидать уже измененную структуру базы, а старая база этих изменений еще не содержит.
Лучше хранить файлы и базу как одну точку восстановления. После отката нужно проверить не только главную страницу, но и каталог, карточки товаров, корзину, оформление заказа и административную часть.
Перед обновлением полезно зафиксировать текущее состояние
Кроме копии, полезно записать текущую версию CMS, PHP и основных модулей. Если после обновления появится ошибка, будет проще понять, что именно изменилось и к какой версии можно вернуться.
На проектах с ручными доработками особенно важно знать, какие файлы менялись отдельно. Обычное обновление поверх такой системы может затереть внесенные раньше изменения. Такие работы лучше проводить в рамках технической поддержки интернет-магазина с проверкой после каждого этапа.
Что проверить после восстановления
После отката сайт должен не только открываться. Нужно проверить важные функции: категории, поиск, карточки товаров, изображения, авторизацию, корзину, оформление заказа, письма и административную часть.
Если восстановление выполнялось после серверного изменения, дополнительно проверяются HTTPS, версия PHP, права на файлы, задачи cron и подключение к базе данных. Для магазина с интеграциями также проверяются внешние сервисы.
Когда резервное копирование стоит настроить отдельно
Если сайт регулярно обновляется или получает новые заказы, имеет смысл настроить автоматическое создание копий и понятный срок их хранения. При этом важно заранее знать, где находятся архивы и как из них вернуть сайт.
Схему копирования лучше подбирать под конкретный проект. Большой каталог с тысячами изображений и небольшая витрина требуют разного объема места и времени на создание архива.
Нужно безопасно обновить или доработать магазин?
Пришлите адрес сайта и опишите, что планируется изменить. Перед технической работой можно проверить текущую систему, сделать резервную копию и определить способ восстановления. Telegram / MAX: +7 (977) 090-37-89.
