Restore базы MySQL: чеклист без паники

На проекте понадобилось откатить базу — не из катастрофы, а после кривого обновления модуля. Ниже — порядок действий и скрипт, который не дропает прод сам по себе.

Серия

  1. Ежедневный dump
  2. Проверка дампа
  3. Этот гайд — restore

Чеклист до команды

  1. Выбрать файл: дата/время в имени, ls -lt, сверить размер с «обычным».
  2. gzip -t на выбранном файле — иначе дальше бессмысленно.
  3. Решить: лить в ту же БД или в временную bitrix_restore и переключить конфиг.
  4. STOP / maintenance сайта (nginx return 503, Bitrix maintenance, остановить php-fpm воркеры — как принято у вас).
  5. Снять ещё один свежий dump «на всякий» до отката — если прод ещё читается.
Скрипт требует I_UNDERSTAND=YES. Это защита от случайного запуска из истории shell, не от вашей ошибки в TARGET_DB. Имя БД перепроверяйте дважды.

Скрипт

Скачать mysql-restore.sh →

sudo curl -fsSL -o /usr/local/sbin/mysql-restore.sh \
  https://mediops.ru/tools/scripts/mysql-restore.sh
sudo chmod 750 /usr/local/sbin/mysql-restore.sh

Вариант A — в отдельную БД (безопаснее)

TARGET_DB=bitrix_restore \
DUMP_FILE=/var/backups/mysql/bitrix_20260730_031500.sql.gz \
CREATE_DB=1 \
I_UNDERSTAND=YES \
DEFAULTS_FILE=/root/.my.cnf \
  /usr/local/sbin/mysql-restore.sh

Потом в .settings.php / dbconn.php временно указать bitrix_restore, проверить сайт, вернуть или переименовать БД.

Вариант B — в ту же БД (осторожно)

Обычно сначала:

# пример — только если сознательно перезаписываете прод
mysql -e "DROP DATABASE bitrix; CREATE DATABASE bitrix CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Затем тот же restore с TARGET_DB=bitrix и CREATE_DB=0 (БД уже создана). Права пользователя сайта на БД — вернуть GRANT, если дропали.

После заливки

  • Логин в админку / главная / карточка товара — смоук.
  • Кэш Bitrix / nginx / Redis — сбросить по регламенту проекта.
  • Cron агентов Bitrix — убедиться, что не бьёт старыми очередями.
  • Снова verify на свежем dump после стабилизации.

Связка с диском

Если единственная копия дампа лежала на том же SSD, что и MySQL — restore может быть уже неоткуда брать. См. бэкапы на том же диске.

Честно про Mediops

Restore делаете вы. Mediops в инциденте поможет косвенно: алерт «сайт недоступен», метрики VDS, site-check снаружи — чтобы не гадать «у меня или у всех».

Пока сайт в maintenance — контроль снаружи

site-check и алерты доступности: бесплатный старт за пару минут.