Відновлення сайту з резервної копії 1С-Бітрікс

Відновлення сайту з резервної копії 1С-Бітрікс

Телефонний дзвінок «сайт не працює» у п'ятницю ввечері — знайома ситуація. Причини різні: випадкове видалення даних, невдале оновлення, злам, відмова диска, «хтось щось зачепив». Швидкість відновлення залежить від двох речей: є актуальна резервна копія і наскільки чітко зрозумілий процес відновлення. Імпровізувати в момент аварії — найгірший сценарій.

Типи аварій і підходи до відновлення

Перед відновленням важливо зрозуміти: що саме сталося. Від цього залежить спосіб відновлення.

Пошкодження або видалення файлів. Відкат файлів з архіву без відновлення бази — якщо дані в БД не зачеплено. Швидко.

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

Повна втрата сервера. Розгортання на новому сервері з нуля: ОС + веб-сервер + 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 хвилин.

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

Терміни відновлення

Реальні цифри залежать від розміру сайту, швидкості каналу до сховища і стану архіву.