Резервная копия магазина OpenCart: разбор на живом примере

У магазина на OpenCart 3.0.x есть как минимум две части, которые нужно сохранить вместе: файлы сайта и база данных. Если забрать только одну, после сбоя вы можете получить страницу без заказов, каталог без изображений или вообще неработающий сайт. На примере условного магазина покажем три способа сделать копию и проверить её, не придумывая замеры и не полагаясь на кнопку, которая просто сообщает об успехе.

Пример: что именно сохраняем

Представим магазин на OpenCart 3.0.x: файлы лежат в каталоге сайта на Linux-хостинге, база данных — в MySQL или MariaDB. Это иллюстративный пример, а не описание конкретного магазина. Пути, доступные команды и ограничения зависят от хостинга.

Для восстановления нужны обе части:

• Файлы OpenCart: код, изображения, загруженные документы, темы и сторонние расширения. В копию попадает и конфигурация, но она содержит доступы к базе — архив нужно хранить как секретный файл.
• База данных: товары, категории, заказы, клиенты, настройки и другие записи магазина. При обновлении заказа данные меняются именно здесь.

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

Резервная копия — это не архив с зелёной галочкой. Это файлы и база, из которых вы уже проверили восстановление.

Три способа сделать копию

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

Панель хостинга: самый прямой вариант

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

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

SSH: архивируем файлы и выгружаем базу

Если у вас есть SSH, сначала перейдите в каталог сайта и проверьте, что это нужная установка. Для MySQL или совместимой версии MariaDB дамп можно создать стандартной утилитой mysqldump. Запускайте команды из каталога, где хотите хранить временные копии; подставьте реальные пути и имя базы. Параметр -p запросит пароль интерактивно, поэтому его не нужно вписывать в команду.

mysqldump -u ИМЯ_ПОЛЬЗОВАТЕЛЯ -p ИМЯ_БАЗЫ > opencart-backup.sql
tar -czf opencart-files.tar.gz -C /ПУТЬ/К/САЙТУ .

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

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

Автоматизация: резервирование по расписанию

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

Как проверить копию до аварии

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

1. Проверьте состав. Убедитесь, что архив содержит файлы магазина и каталог загрузок, а SQL-файл создан отдельно. Результат: вы можете перечислить обе части копии и знаете, где они лежат.
2. Проверьте целостность файлов. Откройте архив программой, которая умеет проверять его содержимое. Результат: архив читается и внутри есть ожидаемые каталоги, а не только пустая оболочка.
3. Восстановите базу на тестовом окружении. Используйте отдельную базу и подходящие для неё учётные данные. Результат: импорт завершается без ошибки, а таблицы и записи доступны.
4. Подключите восстановленные файлы к тестовой базе. Укажите тестовые пути и настройки, не копируя конфигурацию поверх рабочего магазина. Результат: тестовый сайт открывается, отображает каталог и позволяет проверить данные заказа без проведения реальной оплаты.
5. Зафиксируйте, сколько заняло восстановление. Результат: вы знаете не только дату копии, но и примерное время возвращения магазина в работу. Повторяйте проверку после крупных обновлений и изменений структуры хранения.

Что чаще всего ломается

• Сохранили базу, забыли изображения. Товарные записи восстановились, но ссылки на файлы ведут в пустоту. Проверьте каталог загрузок и путь к нему в конфигурации.
• Архивировали только публичную папку. Каталог хранения может находиться рядом с корнем сайта, а не внутри него. Сверьте фактический путь до запуска резервирования.
• Дамп создался не полностью. Прерывание SSH-сессии, ограничение панели или нехватка места могут оставить неполный файл. Смотрите журнал задания и проверяйте дамп импортом в тестовую базу.
• Копия лежит на том же сервере. При сбое диска или блокировке аккаунта архив может пропасть вместе с магазином. Храните дополнительную копию отдельно и ограничивайте к ней доступ.
• Восстанавливают поверх рабочего магазина без проверки. Это может затереть новые заказы и изменения. Сначала тестовая среда, затем согласованный план переключения.

Что настроить после первой проверки

Выберите способ, который можете регулярно выполнять и контролировать: для небольшого проекта подойдёт панель хостинга, для доступа по SSH — архив файлов и дамп базы, для постоянного резервирования — расписание с проверкой результата. Затем запишите, где лежит копия, кто имеет к ней доступ и как восстановить магазин на тестовой площадке.

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

Термин: дамп базы — файл с SQL-командами и данными, из которого можно восстановить структуру и содержимое базы данных.