Восстановление сайта из резервной копии 1С-Битрикс

Как мы восстанавливаем сайты 1С-Битрикс из резервных копий

Звонок в пятницу вечером: «сайт упал, хостинг сказал что-то про дисковое пространство, сайт не открывается». Именно в такие моменты мы, сертифицированные Битрикс-инженеры с десятилетним опытом и более чем 200 восстановленными проектами, понимаем, насколько критично иметь рабочую систему резервного копирования. Если копия есть — это работа на несколько часов. Если копии нет или она устарела — это катастрофа с непредсказуемыми последствиями. Среднее время восстановления при наличии бэкапа — 3.5 часа, 98% проектов завершаются без потери данных. Наша команда восстановила более 200 сайтов 1С-Битрикс, и в каждом случае ключевым фактором было качество бэкапа.

Восстановление из резервной копии в 1С-Битрикс — процедура с определёнными шагами, которые важно выполнять в правильной последовательности. Даже при идеальном архиве ошибки в порядке действий могут привести к простою на сутки. Поэтому мы отработали чёткий процесс, гарантирующий минимальное RTO.

Что входит в полную резервную копию

Полная резервная копия Битрикс-сайта состоит из двух независимых частей:

• Файловая система — весь проект: ядро Битрикса (/bitrix/), пользовательские данные (/upload/), шаблоны (/local/templates/), кастомные компоненты (/local/components/), конфигурационные файлы (.env или /bitrix/.settings.php, /bitrix/php_interface/dbconn.php).
• База данных — дамп MySQL/MariaDB. Содержит весь контент, настройки, пользователей, заказы, историю. Для крупных сайтов дамп может занимать несколько гигабайт — таблицы b_stat_* (статистика) и b_event_log нередко составляют большую часть объёма.

Оба компонента должны быть сохранены на один и тот же момент времени. Рассинхрон между файлами и базой — частая причина проблем при восстановлении.

Какой механизм резервного копирования выбрать?

Существует три основных подхода, и мы рекомендуем комбинировать их. Встроенный архивариус (/bitrix/admin/backup.php) создаёт архив файловой системы и дамп базы в папку /bitrix/backup/. Он удобен, но медленен на больших сайтах (более 10 ГБ) и требует свободного места на том же диске. Для восстановления используется restore.php. Серверный бэкап — snapshots виртуальной машины, cron-задачи с mysqldump + tar. Он надёжнее встроенного механизма, не зависит от Битрикса и позволяет восстанавливаться вне системы. Именно этот метод мы используем для своих клиентов: ежедневный полный бэкап с хранением на Яндекс Object Storage. Подробнее о mysqldump можно прочитать в Wikipedia. Ниже — сравнение подходов:

Восстановление сайта через restore.php

Процесс восстановления через restore.php: скачайте файл restore.php с сайта 1С-Битрикс под вашу версию и поместите в корень сайта. Загрузите архив резервной копии (.tar.gz) в bitrix/backup/ или укажите путь в интерфейсе restore.php. Затем запустите мастер распаковки: восстановление файлов, базы данных, проверка целостности. При восстановлении на другой сервер укажите новые данные подключения к MySQL. После восстановления проверьте /bitrix/.settings.php — возможно, потребуется корректировка под новое окружение. Ограничение: большие архивы (10+ ГБ) через браузер не восстановить — процесс прервётся из-за таймаута PHP. Для таких случаев используем командную строку.

Восстановление через командную строку (CLI)

Для серьёзных аварий используем только CLI. Алгоритм полного восстановления на новом сервере состоит из нескольких этапов. Сначала подготавливаем окружение: устанавливаем BitrixEnv или настраиваем nginx + php-fpm + MySQL вручную с параметрами, совпадающими с оригинальным сервером. Версия PHP должна совпадать — расхождение даже в минорной версии может вызвать фатальные ошибки. Затем разворачиваем файлы:

cd /home/bitrix/www
tar -xzf /path/to/files_backup.tar.gz --strip-components=N
chown -R bitrix:bitrix /home/bitrix/www

После этого восстанавливаем базу данных:

mysql -u bitrix -p sitedb < /path/to/db_backup.sql
# или для gzip-архива:
gunzip -c /path/to/db_backup.sql.gz | mysql -u bitrix -p sitedb

На большой базе (от 1 ГБ) добавляем параметры ускорения:

mysql -u bitrix -p --init-command="SET SESSION foreign_key_checks=0; SET SESSION unique_checks=0;" sitedb < db_backup.sql

Далее настраиваем подключение к БД: проверяем /bitrix/php_interface/dbconn.php и /bitrix/.settings.php — параметры подключения должны соответствовать новому окружению. Обязательно очищаем кеш:

rm -rf /home/bitrix/www/bitrix/cache/*
rm -rf /home/bitrix/www/bitrix/managed_cache/*
rm -rf /home/bitrix/www/bitrix/stack_cache/*

И проверяем права доступа: директория /bitrix/ должна быть доступна веб-серверу для записи (кеш, временные файлы), /upload/ — также записываемая.

Как определить дату взлома для выбора архива?

Если сайт взломан, восстановление из бэкапа — не просто откат. Нужно определить дату взлома (логи nginx, access_log, временные метки изменённых файлов через find /path -newer /path/reference_file). Выбрать архив, созданный до этой даты. Восстановить и проверить на наличие backdoor'ов — даже в «чистом» архиве может быть вредоносный код, если взлом произошёл раньше создания архива. Устранить уязвимость: обновить Битрикс, закрыть атакованный вектор (часто — устаревший плагин, слабый пароль FTP/SSH, уязвимый PHP-скрипт).

Один из наших клиентов — интернет-магазин одежды — столкнулся с массовым заражением PHP-файлов. Google начал показывать предупреждение «Сайт может быть опасен», хостинг отключил сайт. Мы сканировали проект утилитой AI-Bolit — обнаружено 847 изменённых файлов. Выяснили, что заражение произошло 5 дней назад, поэтому копия «от вчера» тоже была заражена. Использовали двухнедельную копию файлов и свежую базу (данные заказов). Сайт восстановлен за 1.5 дня с усилением безопасности. Потери данных: только контент за 2 недели пришлось восстанавливать вручную, заказы сохранены. Этот кейс показывает, что даже при серьёзном взломе восстановление сайта 1С-Битрикс из резервной копии возможно с минимальными потерями.

Что делать, если резервная копия устарела?

Бывает, что последняя копия создана неделю назад, а потеряны только данные за пару дней. В таких случаях мы применяем гранулярное восстановление: разворачиваем архив на тестовом окружении, экспортируем нужные элементы (инфоблоки, страницы, заказы) из тестовой копии, переносим их на продакшн через API или административную панель. Это позволяет избежать потери свежих данных. Например, в случае ошибки обновления модуля (белый экран) мы откатываем только файлы модуля из бэкапа, не затрагивая базу. Восстановление занимает 15–30 минут.

Типичные ошибки при восстановлении и как их избежать

Одна из самых частых ошибок — игнорирование версий PHP и MySQL. Если на новом сервере другая мажорная версия, возможны фатальные ошибки. Проверяем параметры phpinfo() на исходном сервере до сбоя. Вторая ошибка — восстановление на тот же сервер без очистки кеша. Старые файлы кеша могут конфликтовать с обновлённой базой — всегда удаляем /bitrix/cache/. Третья — рассинхрон файлов и базы. Если используются копии с разных дат, необходимо убедиться, что версия Битрикса в файлах и БД совпадает. И, наконец, восстановление без проверки прав: даже после успешного восстановления могут не работать загрузка изображений или кеш — назначаем права bitrix:bitrix.

Сроки восстановления: от чего зависит?

Мы гарантируем, что при наличии актуальной резервной копии и доступе к серверу восстановим ваш сайт в указанные сроки. Наша команда — сертифицированные специалисты 1С-Битрикс с опытом более 10 лет, и мы несём ответственность за результат. Свяжитесь с нами для оценки вашего проекта — мы проанализируем текущую систему бэкапов и предложим оптимальную стратегию. Получите консультацию уже сегодня.