Резервное копирование и перенос MODX: живой разбор

Перенос MODX-сайта на другой сервер обычно выглядит просто: скачать файлы, выгрузить базу, поменять настройки и открыть новый домен. На практике сайт может отдать ошибку подключения к MySQL, потерять изображения, продолжить писать заказы в старую базу или показать пустую админку. Ниже — рабочий сценарий для MODX Revolution 2.8.x: сначала соберём резервную копию, затем развернём её на тестовом адресе и только после проверки переключим домен.

Что переносим и какой подход выбираем

В MODX сайт состоит из двух связанных частей: файлов и базы данных. В файлах находятся ядро, дополнения, шаблоны, чанки, сниппеты, изображения и пользовательские настройки. В базе — ресурсы, системные настройки, пользователи, права, содержимое и данные компонентов. Архив только папки assets не является резервной копией сайта.

Для примера возьмём типичный проект на MODX Revolution 2.8.x, который переносится с одного VPS или хостинга на другой. Версию MODX, PHP, MySQL или MariaDB и веб-сервер на целевой площадке заранее сверяют с исходной средой. Сначала лучше повторить окружение максимально близко, а обновление MODX выполнять отдельным этапом.

Главная проверка резервной копии — не наличие файла с расширением .sql, а возможность развернуть его на чистом окружении.

Бэкап¹ — копия данных, из которой можно восстановить сайт. Архив исходных файлов без проверенной базы и инструкции по возврату — только часть такой копии.

Сценарий переноса по шагам

1. Зафиксируйте исходную среду

Запишите версию MODX из панели управления, версию PHP, тип и версию СУБД, веб-сервер, путь к корню сайта и адреса панели управления. Отдельно составьте список дополнений, которые установлены через менеджер пакетов, и проверьте, нет ли локальных изменений в ядре.

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

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

2. Сделайте копию базы

Если доступен SSH, используйте штатную утилиту MySQL или MariaDB. Команда попросит пароль интерактивно, поэтому секрет не попадёт в историю команд:

mysqldump --single-transaction --default-character-set=utf8mb4 -u DB_USER -p DB_NAME > modx_backup.sql

Замените DB_USER и DB_NAME на реальные значения. Если сервер не принимает параметр --single-transaction или в базе есть таблицы с другим типом хранения, уточните совместимые параметры у провайдера. Не удаляйте старую базу после экспорта.

Проверьте размер файла, дату изменения и возможность прочитать его начало. Файл размером в несколько байт при большой базе обычно означает ошибку команды или отсутствие прав, а не успешный экспорт.

Проверка: команда завершилась без сообщения об ошибке, файл modx_backup.sql существует и заметно больше пустого файла.

3. Сохраните файлы сайта

Архивируйте корень MODX целиком, включая скрытый файл .htaccess, папку core, assets, менеджер и установленные дополнения. Для Linux можно использовать:

tar -czf modx_files.tar.gz -C /path/to/site .

Путь /path/to/site замените на фактический корень проекта. Архив не должен включать родительскую директорию целиком: иначе после распаковки сайт может оказаться в лишнем вложенном каталоге. Не исключайте core: там находится конфигурация и часть данных дополнений.

Проверка: внутри архива на верхнем уровне видны файлы и каталоги MODX, а не единственная папка с названием старого проекта.

4. Подготовьте чистый целевой сервер

Создайте виртуальный хост, назначьте ему корень сайта и установите ту же версию PHP, с которой работает исходный проект. Проверьте расширения PHP, права на запись в каталоги кэша и загрузки, а также правила Apache или Nginx для ЧПУ.

Не запускайте установщик MODX поверх уже подготовленной копии. Он создаст новую структуру и может записать собственные реквизиты базы. В этом сценарии задача — восстановить существующий сайт, а не установить второй проект.

Проверка: тестовый домен указывает в нужный каталог, PHP выполняется, а пустой каталог не выдаёт ошибку конфигурации веб-сервера.

5. Распакуйте файлы и импортируйте базу

Распакуйте архив в корень целевого виртуального хоста. Затем импортируйте дамп в созданную пустую базу:

mysql -u DB_USER -p DB_NAME < modx_backup.sql

Если импорт выполняется через панель, выберите именно пустую базу и дождитесь сообщения об успешной загрузке всех таблиц. При ошибке «table already exists» сначала проверьте, не запускали ли импорт ранее частично. Не повторяйте его вслепую: сначала выясните состояние базы.

Проверка: в базе появились таблицы MODX с исходным префиксом, а импорт завершился без ошибок синтаксиса и кодировки.

6. Исправьте конфигурацию MODX

В файле core/config/config.inc.php проверьте адрес сервера базы, имя базы, пользователя, пароль и префикс таблиц. На новом сервере также должен совпадать абсолютный путь к core. Если путь изменился, MODX может показать белую страницу или ошибку о невозможности загрузить конфигурацию.

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

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

7. Очистите кэш и проверьте сайт

После восстановления удалите содержимое кэша MODX через менеджер или файловый доступ, оставив сами каталоги. Кэш содержит сгенерированные данные старого окружения: пути, ссылки и результаты работы дополнений. Не удаляйте весь каталог core и не трогайте файлы конфигурации.

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

Проверка: страницы открываются без 500, изображения загружаются, изменения в тестовом ресурсе сохраняются, а в журнале MODX нет новых фатальных ошибок.

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

• Ошибка подключения к базе. Проверьте имя базы, пользователя, пароль, хост и права пользователя на целевую базу. На некоторых хостингах имя базы автоматически получает префикс аккаунта.
• Белая страница или ошибка 500. Сверьте версию PHP, права на запись и журнал PHP. Старое дополнение может не работать с новой версией PHP, даже если сама копия MODX восстановлена правильно.
• ЧПУ возвращают 404. Проверьте, что перенесён .htaccess, включена поддержка rewrite и веб-сервер использует правильный корень сайта. Для Nginx правила из .htaccess автоматически не применяются.
• Менеджер открывается, но сайт показывает старые ссылки. Очистите кэш и проверьте системные настройки домена. Глобальная замена домена внутри SQL опасна: она может повредить сериализованные значения дополнений.
• Формы или письма не работают. Проверьте настройки почты, адрес отправителя, SMTP и ограничения хостинга. Сам факт успешного переноса файлов не доказывает, что исходящий SMTP доступен на новом сервере.

Где подход ломается и как сделать перенос без потери заказов

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

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

Если меняется домен, отдельный этап — проверка абсолютных ссылок, canonical, robots.txt, интеграций и вебхуков. Перенос домена и обновление версии MODX лучше не совмещать: иначе при ошибке будет трудно понять, что именно её вызвало.

Что делать после переноса

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

Следующий полезный шаг — не новый архив, а пробное восстановление по инструкции на отдельном тестовом домене. Засеките время, за которое команда может вернуть сайт, и запишите точные версии MODX, PHP, СУБД и дополнений. Такой сценарий ценнее бэкапа, который существует только на диске старого сервера.