Как обновить CMS на старой версии без потери данных сайта

Кнопка «Обновить» в админке CMS — самая обманчивая кнопка на сайте. Один клик, минута ожидания — и либо всё работает, либо сайт лежит с белым экраном, а восстановить его без резервной копии невозможно. Мы регулярно обновляем CMS на старых версиях без потери данных и по опыту знаем: безопасное обновление — это не одно действие, а последовательность из пяти шагов, каждый из которых снижает риск потерять сайт.

Ниже — пошаговый план, которым мы пользуемся сами. Он подходит для 1С-Битрикс, WordPress, MODX, OpenCart и большинства других CMS: логика обновления везде одна, различаются только технические детали.

Почему «обновить в один клик» — плохая идея для рабочего сайта

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

• Новое ядро может требовать более свежую версию PHP, а на хостинге стоит старая — сайт перестаёт запускаться.
• Тема или шаблон писались под старый API — после обновления часть блоков и стилей «рассыпается».
• Плагины и модули, которые никто не обновлял годами, конфликтуют с новым ядром или вовсе перестают работать.
• Если предыдущий разработчик правил файлы ядра напрямую (а не через компоненты, хуки или события), обновление затирает эти правки без предупреждения.

Чем дольше сайт не обновлялся, тем больше таких несовместимостей накопилось. Поэтому чем старше версия, тем менее уместна кнопка «обновить сейчас» и тем важнее подготовка перед обновлением.

Шаг 1. Аудит: что на самом деле стоит на сайте

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

1. Зафиксировать версию CMS, версию PHP и версию базы данных.
2. Составить список установленных модулей, плагинов и тем с их версиями.
3. Проверить, есть ли в проекте правки, внесённые напрямую в файлы ядра, — их придётся переносить вручную, обновление их не сохранит.
4. Сверить список модулей с целевой версией CMS: какие имеют совместимые обновления, какие придётся заменить аналогами, а какие давно заброшены разработчиком.

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

Шаг 2. Резервная копия, которую реально можно развернуть

Резервная копия — это не файл «на всякий случай», а рабочий инструмент отката. Правило простое: копия, которую ни разу не разворачивали, не считается резервной копией — вы просто не знаете, работает ли она.

• Копируется всё: файлы сайта целиком (включая загруженные изображения, документы и кастомные шаблоны) и полный дамп базы данных.
• Копия делается непосредственно перед началом работ, а не берётся из архива недельной давности.
• Копия проверяется разворачиванием — хотя бы на локальном сервере или в отдельной папке хостинга. Если база не восстанавливается или в архиве не хватает части файлов, вы узнаёте об этом сейчас, а не в момент, когда обновление уже пошло не так.
• Копия хранится отдельно от исходного сервера — в облаке или на локальном диске. Резервная копия на том же диске, что и рабочий сайт, не спасает при сбое хостинга.

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

Шаг 3. Тестовая среда: репетиция обновления до того, как её увидят посетители

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

1. Развернуть тестовую копию из проверенной резервной копии — файлы плюс база данных.
2. Провести обновление CMS, модулей и, если нужно, версии PHP именно на этой копии.
3. Зафиксировать, что сломалось: какие модули оказались несовместимы, какие блоки шаблона выпали, какие ошибки появились в логах.
4. Исправить или заменить проблемные модули и участки кода на тестовой копии, добиться, чтобы сайт полностью работал в новой версии.

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

Шаг 4. Поэтапное обновление и проверка после каждого шага

Обновление на несколько мажорных версий вперёд одним действием — частая причина необратимых сбоев. Более надёжная схема — двигаться пошагово, проверяя работоспособность после каждого этапа:

• Сначала обновляются модули и плагины до последних версий, совместимых с текущим ядром, — это снимает часть будущих конфликтов заранее.
• Затем ядро CMS обновляется через промежуточные версии, а не сразу до последней, если разрыв большой (например, Битрикс с версии многолетней давности или MODX с ветки 2.x на 3.x).
• После каждого промежуточного шага сайт на тестовой копии проверяется: открываются ключевые страницы, отправляются тестовые формы, проверяется корзина и админка.
• Версия PHP поднимается отдельным шагом, после того как код адаптирован под неё, — совмещать обновление ядра и скачок PHP в одном действии рискованно вдвойне.

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

Отдельно стоит период наблюдения — несколько дней после обновления, когда команда следит за логами ошибок и обращениями клиентов. Часть проблем проявляется не сразу, а при первом обращении к редко используемому разделу сайта, поэтому наблюдение так же важно, как и сама процедура обновления.

Практический вывод

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

Если хотя бы на один вопрос ответ «нет», кнопку «обновить» лучше не нажимать. Это не про перестраховку — это про то, что откат без бэкапа невозможен, а найти причину сбоя на сайте, обновлённом сразу на несколько версий вперёд, в разы дольше и дороже, чем провести обновление поэтапно с самого начала. Для сайтов, где давно не менялась версия CMS или PHP, разумнее заранее провести аудит и подготовить схему обновления, чем действовать по факту сбоя.