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