Восстановление сайта из резервной копии 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 лет, и мы несём ответственность за результат. Свяжитесь с нами для оценки вашего проекта — мы проанализируем текущую систему бэкапов и предложим оптимальную стратегию. Получите консультацию уже сегодня.

Безопасность сайта на 1С-Битрикс: аудит, защита, мониторинг

Последний серьёзный массовый взлом Битриксов — через уязвимость в модуле vote (BDU:2022-05127). Через неё заливали веб-шеллы пачками. Причина? Владельцы не обновляли ядро по полгода, а модуль голосований стоял «на всякий случай». С тех пор мало что изменилось в подходе: Битрикс выпускает патч, а его ставят через три месяца. Мы выстраиваем комплексную безопасность сайта так, чтобы между выходом патча и его применением проходили дни, а не месяцы. И чтобы даже без патча сайт не лёг от типовой атаки.

Закажите аудит безопасности сайта — получите отчёт с приоритетами и план закрытия уязвимостей за 1-2 дня.

Модуль «Проактивная защита» — мощный, но не из коробки

Модуль security установлен почти на каждом Битриксе, но настроен правильно — от силы на каждом пятом. Что конкретно нужно включить и подкрутить:

• WAF (Веб-антивирус) — фильтрует SQL-инъекции, XSS, CSRF, path traversal на уровне OnPageStart. Ключевая настройка — режим «Активная реакция»: не просто логировать, а блокировать. В /bitrix/admin/security_filter.php проверяем, что все типы атак включены, а исключения — минимальны.
• Контроль активности (/bitrix/admin/security_iprule.php) — лимиты на количество запросов с одного IP. По умолчанию 100 запросов в минуту. Для API-эндпоинтов, куда стучат мобильные приложения, нужны исключения — иначе заблокируете своих же пользователей.
• 2FA — OTP через Google Authenticator. Включается в настройках пользователя. Для группы «Администраторы» делаем обязательным через OnAfterUserAuthorize — без второго фактора в админку не пускаем.
• Контроль целостности (/bitrix/admin/security_file_verifier.php) — хэши системных файлов. Если кто-то изменил файл в /bitrix/modules/ — система заметит. Запускаем проверку по cron ежедневно через агент CSecurityFileVerifier::Verify().
• Стоп-лист — b_security_filter_stoplist. Автоматическая блокировка IP при срабатывании WAF. Ручное добавление подсетей — когда видим сканеры.
• Журнал безопасности — b_event_log. Кто, когда и что менял в админке. Хранение минимум 90 дней. При расследовании инцидента — бесценно.

Что включает аудит безопасности сайта Битрикс?

Серверный уровень — тут чаще всего и дыры:

• phpinfo() доступен по /info.php или /phpinfo.php — встречается на каждом третьем проекте. Атакующий получает версию PHP, пути, модули, конфигурацию. Удаляем.
• display_errors = On на продакшне — стектрейсы с путями к файлам и именами таблиц улетают пользователю в браузер.
• PHP-функции exec, system, passthru, proc_open не отключены в php.ini. Если веб-шелл всё-таки зальют — с этими функциями он получит полный контроль над сервером.
• Версия PHP < 8.1 — без security-апдейтов. PHP 7.4 больше не поддерживается, но до сих пор живёт на четверти проектов.

Уровень приложения:

• Устаревшие модули: vote, forum, blog — часто стоят неиспользуемые, но с активными обработчиками. Деактивируем и удаляем.
• Кастомный код: grep по $DB->Query( с конкатенацией $_REQUEST — классическая SQL-инъекция. Должны быть $DB->ForSql() или D7 ORM.
• Загрузка файлов: если CFile::CheckFile() не вызывается или проверяет только расширение без MIME-типа — через форму обратной связи зальют .php файл.
• dbconn.php и .env — должны быть закрыты правилами веб-сервера. Проверяем: curl https://site.ru/bitrix/.settings.php не должен отдавать ничего кроме 403.

SSL/TLS:

• Проверка через SSL Labs — рейтинг A или выше.
• HSTS с max-age от 31536000 (год).
• Редирект HTTP -> HTTPS на уровне Nginx, не на уровне Битрикса.

Результат аудита — отчёт с приоритетами: Critical / High / Medium / Low. Критические закрываем в первый день. Свяжитесь с нами — оценим ваш проект за 1-2 дня.

Лечение взломанных сайтов — протокол действий

Сайт уже скомпрометирован — SEO-спам, редиректы на казино, веб-шелл в /upload/. Порядок действий:

1. Изоляция — снимаем сайт, ставим заглушку. Если вредонос шифрует файлы или распространяется — каждая минута на счету.
2. Определение вектора — логи доступа (access.log), логи ошибок, b_event_log. Ищем POST-запросы к нетипичным файлам, обращения к /upload/*.php, подозрительные user-agent.
3. Поиск вредоносного кода — grep -r "eval(base64_decode" /home/bitrix/www/ — классика. Также ищем assert(, preg_replace с модификатором e, ${"_GET"}, обфусцированные переменные вида $GLOBALS['x46x65'].
4. Проверка БД — b_iblock_element_property и b_iblock_element на инъектированные скрипты и скрытые ссылки. SELECT * FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT NOT LIKE '%bitrix%'.
5. Чистка или восстановление — если заражение масштабное, проще восстановить из чистого бэкапа и накатить только контентные изменения из БД.
6. Закрытие уязвимости — обновление ядра, удаление неиспользуемых модулей, правка кастомного кода.
7. Запрос пересканирования — Google Search Console → «Запросить проверку», Яндекс.Вебмастер → «Я всё исправил».

Средняя стоимость восстановления после взлома — от 40 000 до 100 000 руб., а профилактический аудит обходится в 2-3 раза дешевле. Вложив 30 000 руб. в аудит, вы можете сэкономить до 200 000 руб. на ликвидации последствий.

Как защитить сайт на Битриксе от DDoS?

• Cloudflare / DDoS-Guard / Qrator — проксирование трафика. L3/L4 атаки фильтруются на их стороне. L7 — через правила и challenge-страницы. Важно: после подключения скрыть реальный IP сервера, иначе смысл теряется.
• Rate limiting на Nginx: limit_req_zone для /bitrix/admin/, /api/, форм. Отдельные лимиты для авторизованных и анонимных пользователей.
• CAPTCHA — \Bitrix\Main\Captcha\CaptchaManager для форм Битрикса или reCAPTCHA v3 для кастомных. v3 не раздражает пользователей — работает в фоне.
• Bot management — пропускаем Googlebot, YandexBot (проверка через reverse DNS), блокируем сканеры и скрейперы по User-Agent и поведению.

Сравнение: rate limiting на Nginx в 5 раз эффективнее стандартной защиты от перебора паролей в Битриксе, так как срезает атаку до того, как она дойдёт до PHP.

Резервное копирование — последний рубеж

• Ежедневные бэкапы: файлы через rsync + дамп PostgreSQL/MySQL через pg_dump/mysqldump.
• Хранение в изолированном S3-совместимом хранилище. Ключевое слово — изолированном. Если бэкапы лежат на том же сервере, что и сайт, взломщик удалит и их.
• Ротация: daily × 7, weekly × 4, monthly × 12.
• Тестирование восстановления — раз в квартал разворачиваем бэкап на тестовом сервере. Бэкап, из которого невозможно восстановиться, — просто файл на диске.
• Мониторинг: если бэкап не прошёл — алерт в Telegram в течение часа.

Мониторинг — обнаружить до того, как позвонит клиент

• Uptime — проверка каждые 60 секунд через UptimeRobot / Zabbix / кастомный скрипт. Алерт в Telegram + звонок при даунтайме > 5 минут.
• Файловый мониторинг — inotify (Linux) или cron + md5sum по критичным директориям. Новый .php в /upload/? Алерт немедленно.
• Сканирование на малварь — AI-BOLIT или ClamAV по расписанию. Проверка и файлов, и базы.
• SSL-сертификат — предупреждение за 30/14/7 дней до истечения. Let's Encrypt обновляется автоматически через certbot, но certbot тоже может сломаться.
• Блэклисты — проверка домена и IP в Google Safe Browsing, PhishTank, Spamhaus. Попадание = потеря трафика.

152-ФЗ и персональные данные

• HTTPS everywhere — редирект на уровне Nginx.
• Шифрование в БД: пароли через \Bitrix\Main\Security\Password::hash() (bcrypt), токены — через openssl_encrypt.
• Политика конфиденциальности + cookie-баннер (модуль main поддерживает из коробки через COption::SetOptionString("main", "cookie_agreement", "Y")).
• Журналирование доступа к ПД — кто и когда просматривал данные клиентов.

Что входит в работу (deliverables)

Сроки

Работаем разово и на абоненте с фиксированным SLA. Для абонентских клиентов — выделенный инженер, который знает проект. Получите консультацию — оценим риски и составим смету за 1-2 дня.

Чек-лист: 15 пунктов, которые проверяем на каждом проекте

1. Ядро 1С-Битрикс и модули — актуальная версия, неиспользуемые модули удалены.
2. Модуль security активен, WAF в режиме «Активная реакция».
3. 2FA включена для всех учёток с доступом к админке.
4. /bitrix/admin/ закрыт по IP или за дополнительной HTTP-авторизацией.
5. Политика паролей: от 12 символов, mixed case, цифры, спецсимволы.
6. SSL/TLS: рейтинг A+ на SSL Labs, HSTS включён.
7. Служебные файлы (dbconn.php, .settings.php, .env, бэкапы, логи) — 403 из браузера.
8. Права: 644 файлы, 755 директории. Веб-сервер не owner системных файлов.
9. Security-заголовки: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy.
10. Контроль целостности файлов — ежедневная проверка через агент.
11. Бэкапы: ежедневные, изолированное хранение, проверка восстановимости.
12. b_event_log — хранение от 90 дней, регулярный просмотр.
13. PHP 8.1+, display_errors = Off, опасные функции отключены.
14. Мониторинг uptime + алерты при изменении файлов в /upload/.
15. Reverse proxy или CDN с DDoS-защитой для высоконагруженных проектов.

Оценка уязвимостей проводится в соответствии с методологией OWASP Top 10 – Web Application Security Risks (см. Wikipedia). Комплексная безопасность сайта на Битрикс — это не разовая акция, а непрерывный процесс. Закажите полный аудит безопасности сайта сегодня, чтобы завтра не тратить бюджет на экстренное восстановление. Получите консультацию — мы ответим на любые вопросы.