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

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

Звонок в пятницу вечером: «сайт упал, хостинг сказал что-то про дисковое пространство, сайт не открывается». Именно в такие моменты становится понятно, насколько хорошо была организована система резервного копирования. Если копия есть — это работа на несколько часов. Если копии нет или она устарела — это катастрофа с непредсказуемыми последствиями.

Восстановление из резервной копии в 1С-Битрикс — процедура с определёнными шагами, которые важно выполнять в правильной последовательности.

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

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

Файловая система — весь проект: ядро Битрикса (/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/. Удобен, но медленен на больших сайтах и требует свободного места на том же диске. Для восстановления используется restore.php.

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

Серверный бэкап — snapshots виртуальной машины, cron-задачи с mysqldump + tar. Надёжнее встроенного механизма, не зависит от Битрикса. Восстановление происходит вне Битрикса.

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

Процедура восстановления через встроенный restore.php

1. Загрузка restore.php на сервер. Файл скачивается с сайта 1С-Битрикс под конкретную версию. Его нужно положить в корень сайта — туда, где будет развёртываться бэкап.

2. Загрузка архива. Архив резервной копии (.tar.gz) загружается в bitrix/backup/ или указывается путь к нему в интерфейсе restore.php.

3. Запуск распаковки. restore.php предлагает пошаговый мастер: распаковка файлов, восстановление базы данных, проверка целостности.

4. Настройка подключения к БД. При восстановлении на другой сервер — вводим новые данные подключения к MySQL.

5. Пересоздание конфигурации. После восстановления проверяем /bitrix/.settings.php — подключение к БД, кеш, сессии. Возможно, нужна корректировка под новое окружение.

Восстановление через серверные инструменты

Если сайт восстанавливается из серверного бэкапа (не через restore.php):

1. Восстановление файлов — распаковка архива в нужную директорию.
2. Создание БД — создаём базу, назначаем пользователя.
3. Восстановление дампа — mysql -u user -p dbname < dump.sql.
4. Корректировка конфигурации — /bitrix/.settings.php с новыми параметрами подключения.
5. Сброс кеша — удаляем /bitrix/cache/ и /bitrix/managed_cache/.
6. Проверка прав — директория /upload/ должна быть доступна для записи веб-серверу.

Кейс: аварийное восстановление после взлома

Клиент — интернет-магазин одежды. Сайт был заражён: в PHP-файлы добавлен вредоносный код, Google начал показывать предупреждение «Сайт может быть опасен». Хостинг отключил сайт.

Задача: восстановить чистую версию сайта и обеспечить, чтобы заражение не повторилось.

Исходная ситуация: резервная копия от предыдущего дня на хостинге (встроенный архивариус), копия двухнедельной давности на удалённом хранилище.

Работа:

День 1. Диагностика: определение масштаба заражения. Сканирование сайта утилитой AI-Bolit — обнаружено 847 изменённых файлов, заражение произошло примерно 5 дней назад. Это значит, что копия «от вчера» тоже заражена. Берём копию двухнедельной давности.

День 1 (продолжение). Восстановление из чистой копии. Файлы — из двухнедельного бэкапа. База данных — от вчерашнего дня (данные о заказах за две недели важнее, в базе вируса нет, он был в PHP-файлах). Это разные даты — проверяем совместимость: версия Битрикса в файлах и в базе должна совпадать.

День 2. Укрепление после восстановления:

• Смена паролей: база данных, FTP, административная панель Битрикса, хостинг.
• Включение модуля «Веб-антивирус» в Битриксе.
• Настройка автоматического серверного бэкапа (ранее бэкапы делались только через Битрикс, без копии на внешний сервер).
• Настройка мониторинга целостности файлов через модуль security.

Сайт восстановлен за 1,5 рабочих дня. Потери: заказы за последние 2 недели в базе сохранены (брали БД от вчера), контент за эти же 2 недели пришлось восстановить вручную.

Восстановление части данных

Иногда нужно не полное восстановление, а только конкретные данные: «верните удалённый раздел каталога», «восстановите содержимое статьи». В этом случае:

1. Разворачиваем резервную копию на тестовой среде.
2. Находим нужные данные.
3. Переносим точечно через административную панель или SQL-запросами.

Это менее рискованно, чем полное восстановление на продакшне, и позволяет не затрагивать актуальные данные.

Сроки

Восстановление из готовой резервной копии (файлы + БД) на тот же сервер — 2–6 часов в зависимости от объёма. Восстановление на новый сервер с настройкой окружения — 4–12 часов. Аварийное восстановление после взлома с анализом и укреплением — 1–3 рабочих дня.

Телефонный звонок «сайт не работает» в пятницу вечером — знакомая ситуация. Причины разные: случайное удаление данных, неудачное обновление, взлом, отказ диска, «кто-то что-то задел». Скорость восстановления зависит от двух вещей: есть ли актуальная резервная копия и насколько чётко понятен процесс восстановления. Импровизировать в момент аварии — худший сценарий.

Типы аварий и подходы к восстановлению

Перед восстановлением важно понять: что именно случилось. От этого зависит способ восстановления.

Повреждение или удаление файлов. Откат файлов из архива без восстановления базы — если данные в БД не затронуты. Быстро.

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

Полная потеря сервера. Разворачивание на новом сервере с нуля: ОС + веб-сервер + PHP + MySQL + Битрикс + файлы + дамп БД. Самый долгий сценарий.

Взлом (дефейс или вредоносный код). Восстановление из копии плюс анализ вектора атаки и устранение уязвимости. Восстановить без анализа — значит вернуть уязвимость обратно.

Процесс восстановления: штатный инструмент

Встроенный восстановитель в 1С-Битрикс — /bitrix/admin/backup.php. Если архив создан через модуль bitrix.backup, можно восстановить через тот же интерфейс.

Ограничения: тот же PHP-timeout. Большие архивы (10+ ГБ) через браузер не восстановить — процесс прервётся.

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

Для серьёзных аварий — только CLI. Алгоритм для полного восстановления на новом сервере:

1. Подготовка окружения. Устанавливаем BitrixEnv (официальный образ) или настраиваем nginx + php-fpm + MySQL вручную с параметрами, совпадающими с оригинальным сервером. Версия PHP должна совпадать.

2. Разворачивание файлов.

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

3. Восстановление базы данных.

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

4. Настройка подключения к БД. Проверяем /bitrix/php_interface/dbconn.php и /bitrix/.settings.php — параметры подключения должны соответствовать новому окружению.

5. Очистка кеша. После восстановления обязательно:

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

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

Восстановление при взломе

Восстановление из архива при взломе — не просто откат. Нужно:

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

Кейс: восстановление после падения диска

Клиент — интернет-магазин стройматериалов. Пятница, 18:30: хостер сообщает об отказе дискового массива. Сайт недоступен. Последний бекап — ночью, 03:00 того же дня (потеря ~15 часов заказов).

У клиента был бекап в Яндекс Object Storage. Развернули новый VPS с BitrixEnv (20 минут), скачали архив из S3, развернули файлы и БД, поправили dbconn.php, очистили кеш.

Через 2,5 часа сайт работал на новом сервере. Потеря данных: заказы за 15 часов до падения — их восстановили частично из email-уведомлений, которые ушли клиентам.

Ключевой вывод: при настроенном offsite-бекапе и понятном процессе восстановления 2–3 часа — реалистичное RTO. Без бекапа или с бекапом только на упавшем диске — потеря сайта.

Кейс: восстановление после ошибочного обновления

Клиент обновил сторонний модуль из Marketplace. После обновления — белый экран (500 Internal Server Error), сайт недоступен. Бекап был сделан 3 дня назад.

Откатывать трёхдневный бекап — потеря данных. Решение: откат только файлов модуля из бекапа, без восстановления БД. Из архива извлекли только директорию /bitrix/modules/broken_module/, заменили на старую версию. Сайт заработал за 15 минут.

Урок: гранулярный бекап (отдельно файлы, отдельно БД) — ценнее монолитного архива.

Сроки восстановления

Реальные цифры зависят от размера сайта, скорости канала до хранилища и состояния архива.