Копирование сайта на платформе 1С-Битрикс требует точного соблюдения алгоритма для сохранения функциональности и структуры. Прямое копирование файлов без учета базы данных и настроек приведет к сбоям в работе, ошибкам и потере данных.
Для корректного переноса важно сначала экспортировать базу данных с помощью утилиты phpMyAdmin или консольных инструментов, а затем перенести все файлы проекта, включая скрытые системные папки .settings и bitrix. Пропуск любого элемента приводит к неполной сборке сайта и нарушению работы модулей.
Особое внимание уделяется конфигурации .settings.php, где прописаны параметры подключения к базе данных и пути к важным ресурсам. Некорректная настройка этого файла – частая причина ошибок после копирования.
Подготовка среды для копирования сайта на Битрикс
1. Проверка версии PHP и необходимых расширений
Битрикс требует строго определённых версий PHP. Уточните версию, поддерживаемую вашей сборкой (обычно 7.4 или 8.0), и убедитесь, что на сервере установлены необходимые расширения: mbstring, zip, json, xml, curl, mysqli, openssl, zlib.
2. Настройка сервера
Для корректной работы используйте Apache с модулем mod_rewrite или Nginx с соответствующим конфигом. Убедитесь, что директива AllowOverride включена для поддержки .htaccess. На Nginx настройте редиректы и обработку index.php через try_files.
3. Создание новой базы данных
Заранее создайте чистую базу данных в MySQL или MariaDB с кодировкой utf8mb4_general_ci. Убедитесь, что у пользователя базы есть полный доступ: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX.
4. Подготовка каталога для проекта
Создайте отдельную директорию с правами на запись для пользователя веб-сервера. Проверьте, чтобы пути не содержали кириллицы или пробелов. Рекомендуемый путь – /var/www/bitrix_clone или аналогичный.
5. Настройка прав доступа
Все файлы проекта должны принадлежать пользователю веб-сервера (например, www-data). Примените команду: chown -R www-data:www-data /var/www/bitrix_clone. Права: директории – 755, файлы – 644. Исключения: bitrix/php_interface, upload, local – 775, если используется загрузка через браузер.
6. Подготовка архивов и дампа
Перед копированием создайте полный архив сайта (исключая кеш-папки) и дамп базы данных через mysqldump с флагами —routines —triggers —single-transaction. Убедитесь, что дамп корректно импортируется вручную на тестовой машине.
7. Проверка конфигурации PHP
Установите следующие параметры в php.ini:
memory_limit=512M, max_execution_time=300, post_max_size=128M, upload_max_filesize=128M. Эти значения критичны при восстановлении больших архивов.
Создание резервной копии и экспорт базы данных
Перед копированием сайта на Битрикс необходимо создать полную резервную копию файловой структуры и базы данных. Для этого подключитесь к серверу через SSH или используйте файловый менеджер хостинга. Скопируйте весь каталог сайта, включая скрытые файлы, такие как .htaccess
и .settings.php
.
Для экспорта базы данных используйте утилиту mysqldump
. Введите команду:
mysqldump -u [пользователь] -p [база_данных] > backup.sql
Убедитесь, что экспорт производится в кодировке UTF-8, иначе возможны проблемы с отображением кириллицы. При использовании phpMyAdmin активируйте опцию «Добавить DROP TABLE» для предотвращения конфликтов при последующем импорте.
Проверьте, что файл dump.sql
содержит все таблицы, включая служебные Битрикс (например, b_user
, b_option
). Если используется модуль «Проактивная защита», экспортируйте также таблицы b_sec_*
.
Для гарантии целостности создайте контрольную сумму файла базы данных с помощью md5sum
или sha256sum
. Это позволит убедиться, что данные не были повреждены при передаче.
Не храните резервную копию в корне сайта. Переместите её в отдельный каталог вне веб-доступа или скачайте на локальный диск.
Перенос файлов сайта и настройка прав доступа
Сначала выполните архивирование корневой директории сайта. Используйте tar или zip с сохранением прав на файлы: tar -czpf site.tar.gz /var/www/site
. Убедитесь, что включены все подкаталоги, включая bitrix
, upload
, local
, 404.php
, .htaccess
и urlrewrite.php
.
Загрузите архив на новый сервер через SCP или SFTP. Пример команды SCP: scp site.tar.gz user@new-server:/var/www/
. Распакуйте архив в целевой директории, например: tar -xzpf site.tar.gz -C /var/www/site
.
Проверьте владельца файлов и папок. Для веб-сервера Apache это обычно www-data
, для Nginx с PHP-FPM – пользователь из конфигурации пула. Установите владельца: chown -R www-data:www-data /var/www/site
.
Задайте права доступа: директории – 755
, файлы – 644
. Это минимально необходимые права для корректной работы без лишних рисков безопасности. Примеры команд: find /var/www/site -type d -exec chmod 755 {} \;
и find /var/www/site -type f -exec chmod 644 {} \;
.
Папки upload
, bitrix/cache
, bitrix/tmp
, local/php_interface
и local/cache
должны быть доступны на запись. Назначьте для них права 775
или 777
временно на этапе настройки: chmod -R 775 /var/www/site/upload
.
Проверьте наличие и содержимое файла .htaccess
. Убедитесь, что в нем заданы актуальные правила для ЧПУ и настроен корректный RewriteBase
, особенно при переносе в подкаталог. В urlrewrite.php
проверьте пути к компонентам – они должны соответствовать новой структуре сайта.
Завершив перенос, удалите архив с сервера: rm site.tar.gz
, и проверьте логи веб-сервера на наличие ошибок доступа или отсутствующих файлов.
Импорт базы данных и исправление кодировок
Перед импортом убедитесь, что дамп базы данных сохранён в формате совместимом с MySQL или MariaDB и не содержит ошибок экспорта. Рекомендуется использовать утилиту mysqldump
с параметрами --default-character-set=utf8
для предотвращения проблем с кодировками.
- Создайте чистую базу данных на новом сервере. Убедитесь, что используется кодировка
utf8mb4
и сопоставлениеutf8mb4_unicode_ci
. - Перед импортом откройте дамп в текстовом редакторе и проверьте директиву
SET NAMES
. Если указаноlatin1
или другая кодировка, замените наutf8mb4
. - Импортируйте базу с помощью команды:
mysql -u USER -p DBNAME < dump.sql
- После импорта выполните проверку:
SHOW TABLE STATUS WHERE Collation NOT LIKE 'utf8mb4%';
Если найдены таблицы с другой кодировкой – используйте
ALTER TABLE
для изменения:ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
- Проверьте поля типа
TEXT
,VARCHAR
,CHAR
на соответствие новой кодировке. Пример:SHOW FULL COLUMNS FROM table_name;
После смены кодировки выполните очистку кеша в Битрикс и проверьте корректность отображения текста на сайте. Часто проблемы возникают в модулях с собственными таблицами – вручную проверьте их кодировку.
- Если сайт использует старую кодировку (cp1251), сконвертируйте весь дамп в UTF-8 с помощью
iconv
:iconv -f cp1251 -t utf8 dump.sql -o dump_utf8.sql
- Проверьте наличие символов «�» – они указывают на повреждение данных при неверной конверсии. Используйте оригинальный дамп и повторите экспорт с корректной кодировкой.
Настройка конфигурационных файлов и подключений
'connections' => array(
'value' => array(
'default' => array(
'host' => 'localhost',
'database' => 'new_db_name',
'login' => 'db_user',
'password' => 'db_pass',
'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
),
),
),
Проверьте, что файл bitrix/php_interface/dbconn.php
не содержит устаревших параметров. Если файл существует, его содержание должно соответствовать следующим условиям:
- Нет дублирующих настроек подключения, если используется
.settings.php
- Константа
DBPersistent
установлена вfalse
для предотвращения ошибок с постоянными соединениями
В файле bitrix/.settings_extra.php
, при наличии, проверьте кастомные параметры, связанные с кэшированием, путями или специфическими модулями. Несоответствие окружения может вызвать ошибки выполнения.
Убедитесь в актуальности пути к логам и временным файлам:
'tmp_dir' => '/home/bitrix/tmp',
'log_dir' => '/home/bitrix/logs',
При использовании SSL, проверьте настройки веб-сервера и файла .htaccess
. В нем не должно быть директив, указывающих на старые домены или пути, например:
RewriteCond %{HTTP_HOST} ^old-domain\.ru [NC]
RewriteRule ^(.*)$ http://new-domain.ru/$1 [L,R=301]
После всех изменений выполните команду php -f bitrix/modules/main/tools.php
для проверки структуры и корректности подключений. Ошибки отображаются в логах bitrix/updates/update_err.log
.
Проверка работоспособности и устранение типичных ошибок
1. Проверка конфигурации окружения
Убедитесь, что версии PHP и MySQL на новом сервере соответствуют требованиям проекта. Для Битрикс критично использовать рекомендуемые версии – например, PHP 7.4 или 8.0 и MySQL 5.7 или 8.0. Проверьте наличие обязательных PHP-расширений: mbstring, zip, curl, pdo_mysql, gd. Отсутствие хотя бы одного модуля может привести к падению сайта.
2. Корректность путей и прав доступа
После копирования проверьте абсолютные пути в файлах bitrix/.settings.php и dbconn.php. Права на папки upload, bitrix/cache и bitrix/tmp должны быть установлены как минимум на 755, а файлы – на 644. Ошибки прав доступа часто проявляются в виде проблем с загрузкой изображений или кэшем.
3. Синхронизация базы данных
Проверьте, что структура таблиц и кодировка (UTF-8 без BOM) остались неизменными. Особое внимание уделите таблицам b_lang, b_option и b_file – сбои в них приводят к отсутствию настроек, языков интерфейса и файлов. Используйте встроенную проверку целостности в административном разделе: Настройки > Инструменты > Проверка структуры базы данных.
4. Поведение компонентов и модулей
Проверьте, работают ли все установленные модули, особенно сторонние. Некоторые из них могут быть привязаны к домену или IP. Убедитесь, что кеш компонентов обновляется корректно. Очистите кеш вручную через /bitrix/admin/cache.php и перегенерируйте композитный кеш, если он используется.