Откат после неудачной смены CMS

Диагностика перед откатом системы

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

Проверьте логи ошибок в первую очередь

Открыть логи ошибок сайта — первый шаг диагностики проблем. На большинстве веб-серверов логи находятся в папке /var/log/ или доступны через панель управления. Здесь записано всё, что произошло в момент миграции CMS и после запуска последних обновлений.

Логи покажут точку сбоя. «Fatal error: Allowed memory size exhausted» значит, новой версии не хватает памяти для работы. «Database connection refused» указывает на ошибку подключения к базе данных. «Class not found» — ошибка в коде CMS или в модулях расширений PHP. Каждая запись ошибки — это подсказка о причине отката.

Запишите текст ошибки целиком и разберем причины. Он пригодится при диагностике проблемы после восстановления сайта и при обсуждении проекта с разработчиками.

Локализуйте все резервные копии сайта

Резервная копия сайта хранится не в одном месте. Осмотрите несколько стандартных площадок хранения:

На веб-сервере хостинга обычно лежит в /home/user/backups/ либо другой директории сайта. Проверьте через панель управления хостинга — там есть раздел «Резервные копии» или «Backups». Бэкап сайта создаётся автоматически по расписанию (часто ежедневно или еженедельно). Выпишите все доступные версии с точными датами и размерами архивов.

В облачном хранилище провайдера хостинга и в облаке — если подключен S3 AWS, Google Cloud Storage или другой источник. Копия проекта загружалась туда автоматически параллельно с локальным сохранением для безопасности. Зайдите в кабинет облачного сервиса и поищите архивы с датами действия и статусом.

В отдельной системе резервного копирования типа Backup Ninja или Bacula. Архив находится не на основном веб-сервере, а в защищённом хранилище техподдержки хостинга. Попросите техническую поддержку хостинга выдать полный список доступных версий.

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

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

Проверьте целостность и актуальность бэкапа

Не все резервные копии одинаково полезны для отката. Проверка целостности архива — критичный этап:

Размер архива должен быть реалистичным. Если проект обычно весит 500 МБ, а резервная копия — 10 МБ, файлы скопировались неполностью и произошла потеря данных. Исключайте такие варианты из кандидатов.

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

Наличие трёх ключевых элементов: архив файлов (HTML, CSS, JS, медиа), дамп базы данных (SQL-экспорт всех таблиц), конфигурационные файлы (wp-config.php для WordPress, settings.php для Drupal, .htaccess). Посмотрите содержимое архива без распаковки. Если чего-то не хватает и элементы отсутствуют, переходите к следующей резервной копии проекта.

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

Определите точное время отката для восстановления сайта

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

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

На последнюю успешную версию сайта (если есть проверенная копия, созданная за несколько часов до запуска обновления CMS). Это даст 100% работающий результат, хотя может потеряться некоторый контент и изменения, добавленные в промежуток времени.

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

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

Проверьте права доступа и полномочия

Для отката системы нужны полные права на:

Веб-сервер хостинга через SSH, FTP или панель управления. Убедитесь, что помните пароль администратора сервера или учётные данные пользователя с нужными полномочиями для восстановления данных и папок сайта.

Панель управления хостинга (cPanel, Plesk, ISPmanager и другие). Нужны логин и пароль главного администратора для управления резервными копиями проекта.

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

Директорию /var/www (или /home/user, в зависимости от хостинга) — права на распаковку архива с резервной копией сайта и перезапись текущего состояния файлов.

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

Проверьте техтребования — версия php и расширения

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

Версия PHP на веб-сервере должна подходить для восстанавливаемой версии CMS. Старая версия WordPress работает на php 5.6, но на новом хостинге может стоять php 8.0 и выше. Несоответствие версии php даст ошибки после отката на боевом сайте. Проверьте текущую версию через phpinfo(). При необходимости попросите хостинг-провайдера переключить требуемую версию.

Расширения PHP должны быть включены: mysqli (для подключения к БД), curl (для интеграции и внешних запросов), json, mbstring, gd и другие необходимые модули. Без этих расширений откатанная версия сайта не запустится. Список требуемых расширений обычно содержит документация CMS.

Конфигурационные файлы должны быть сохранены и правильно размещены — wp-config.php, settings.php, .htaccess в корне сайта с актуальными учётными данными для подключения к выбранной базе данных.

Чек-лист диагностики перед откатом

Перед запуском полного процесса восстановления пройдитесь по данному списку требуемых действий:

✓ Найдены все компоненты резервной копии сайта: полный архив файлов, полный дамп базы данных, все конфигурационные файлы.

✓ Проверена целостность бэкапа — размер в норме, архив распаковывается без критичных ошибок, внутри находятся нужные элементы.

✓ Записана точная дата, время и версия резервной копии для отката.

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

✓ Проверена совместимость версии PHP и наличие необходимых расширений для восстанавливаемой версии CMS.

✓ Перечитаны логи ошибок — четко понимаете, что вызвало сбой при миграции.

✓ Сделана свежая дополнительная копия текущего дефектного состояния сайта (на случай проблем при откате).

✓ Согласованы временные рамки с командой разработчиков — откат займёт несколько часов, в это время сайт будет недоступен для посетителей.

✓ Подготовлены скрипты восстановления и инструменты хостинга для развёртывания резервной копии.

✓ Всё готово и проверено? Можно переходить к этапу выполнения отката.