Відновлення сайту 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 років, і ми несемо відповідальність за результат. Зв'яжіться з нами для оцінки вашого проєкту — ми проаналізуємо поточну систему бекапів і запропонуємо оптимальну стратегію. Отримайте консультацію вже сьогодні.

Що робити, якщо сайт на Бітріксі вже зламали?

Серйозний масовий злам Бітріксів — через вразливість у модулі vote (BDU:XXXX-05127). Через неї заливали веб-шели пачками. Причина? Власники не оновлювали ядро по півроку, а модуль голосувань стояв «про всяк випадок». Сертифіковані фахівці з 10-річним досвідом вибудовують комплексну безпеку сайту так, щоб між випуском патча та його застосуванням минали дні, а не місяці. І щоб навіть без патча сайт не ліг від типової атаки.

Ми гарантуємо: критичні вразливості закриваємо протягом доби, а повний аудит — за 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 → «Запросити перевірку», Яндекс.Вебмастер → «Я все виправив».

Профілактичний аудит обходиться у 10 разів дешевше, ніж ліквідація наслідків зламу. Один з клієнтів зазначив: після аудиту ми спимо спокійно, знаючи, що сайт захищений.

Як захистити сайт на Бітріксі від 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. Потрапляння = втрата трафіку.

Чому важливий захист персональних даних?

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

Що входить у роботу (deliverables)

Строки

Працюємо разово та на абоненті з фіксованим SLA. Для абонентських клієнтів — виділений інженер, який знає проєкт. Наша компанія має понад 10 років досвіду з Бітрікс та понад 100 успішних проєктів. Зв'яжіться з нами — оцінимо ризики та складемо кошторис за 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. Комплексна безпека сайту на Бітрікс — це не разова акція, а безперервний процес. Замовте повний аудит безпеки сайту сьогодні, щоб завтра не витрачати бюджет на екстрене відновлення. Отримайте консультацію — ми відповімо на будь-які запитання.