Перенос сайтов на основе CMS Bitrix является той ещё проблемой, из-за большого объёма и количества файлов и каталогов, большого размера базы данных, сложностей и особенностей конфигурации web-сервера, и многих других нюансов.
Поэтому, зачастую, перенос сайта Битрикс к другому хостеру или на другой сервер штатными методами и средствами (с помощью резервной копии и скрипта восстановления restore.php) не работает.
Ну как, зачастую… у меня не сработал ни разу, и причин была масса: то разбитая на много частей резервная копия не хочет загружаться или собираться на удалённом сервере в один архив, то ошибки архивирования при создании резервной копии, которые выясняются не при создании, а уже при восстановлении, то ошибки самого скрипта restore.php… И так далее, до бесконечности.
Наличие скрытых файлов в корневом каталоге сайта не позволяет их скопировать вместе с основным массивом данных, а копирование по ftp с сервера на сервер по-файлово длится так долго, из-за бесконечного количества этих файлов, что нет никакой гарантии, что такое копирование не прервётся или закончится без ошибки.
Разбивку резервной копии на несколько десятков архивов я считаю особым идиотизмом: как-то раз один сайт при создании резервной копии выдал боле ста (!!!) частей архива, при чём, при загрузке предложил скачать их все одновременно, и в браузере одновременно всплыли сто окон для загрузки (рука-лицо).
Но самой главной проблемой является то, что скрипт восстановления restore.php рассчитан на развёртывание копии сайта исключительно для web-сервера Apache2, который уже давно стал рудиментом и уходит в прошлое, и даже в случае удачного восстановления резервной копии на новом сервере всё равно приходится прописывать конфигурацию вручную.
Итак, перенос сайта Bitrix на новый сервер или хостинг сводится к трём основным этапам, разбитым на подзадачи, перенос на другой домен я упомяну в самом конце:
- Подготовка серверной среды/окружения, куда будет осуществляться перенос: выбор хостера/датацентра, подбор тарифа с оптимальными параметрами, настройка VPS сервера, установка серверного ПО, настройка конфигурации web-сервера, и прочие сопутствующие мелочи;
- Непосредственно, сам перенос файлов сайта и базы данных на новое серверное окружение: создание архивов на старом хостинге, быстрое их копирование на новый сервер, развёртывание архивов в новом окружении;
- Окончательная настройка и конфигурация для достижения работоспособности и правильной работы: конфигурация web-сервера, настройка DNS-записей, подключение базы данных, настройка рассылки почтовых сообщений от имени сайта, бэкапирование, и прочие рутинные задачи;
Выбор хостера или дата-центра, подбор оптимального тарифа, установка/настройка VPS-сервера, подготовка к переносу.
Виртуальный хостинг для размещения на нём сайта Bitrix я не рассматриваю в принципе, т.к. двигло Битрикса капризное и весьма требовательно к ресурсам, в то время, как на виртуальном хосте могут висеть одновременно несколько десятков и даже сотен сайтов, жрущих ресурсы виртуального сервера, и при отладке невозможно угадать, в чём причина тормозов и сбоев – то ли от собственного сайта, то ли от чужих сайтов.
Поэтому, имеет смысл рассматривать лишь размещение на выделенном VPS сервере, все ресурсы которого будут безраздельно принадлежать вам.
Рекомендую очень серьёзно отнестись к подбору дата-центра и выбору тарифа, а также конфигурации и настройке окружения, потому как от этого будет напрямую зависеть работоспособность сайта и его устойчивость к нагрузкам.
Первый этап разбиваем на следующие подзадачи:
- Выбор дата-центра – настоятельно рекомендую OVH.COM, почему именно его – описывал вот в этой статье – Оптимальные параметры выделенного сервера – наилучшее сочетание цены/качества и технических характеристик.
- Подбор оптимального тарифа – рекомендую минимальный с такими параметрами: одно ядро процессора, 2GB оперативной памяти, 40GB SSD NVMe дискового пространства в массиве RAID10, сетевой интерфейс 250 Mbps с защитой от DDoS, и всё это всего лишь за 2.99 евро в месяц, т.е. меньше 300 рублей, при оплате сразу за год или два – дисконт до 20%. Подробнее о подборе тарифа для VPS я писал в своей статье – ссылка.
- При покупке и оплате тарифа выбираем дистрибутив операционной системы – Ubuntu Server 20.04 LTS, серверная операционная система на базе Linux, без графического интерфейса и прочего мусора, быстрая, лёгкая, идеально для WEB, и не только. После оплаты нам на почту прилетает письмо с подтверждением и данные для доступа: ip-адрес, логин-пароль для подключения по SSH, и домен третьего уровня, привязанный к ip.
- Первичное подключение к VPS и его настройка, конфигурация: первым делом, настраиваем SSH и защищаем от взлома и подбора пароля, описывал здесь – Защита SSH на VPS-сервере; настройка сетевого интерфейса; настройка локали (язык локализации) и часового пояса;
- Установка серверного ПО и утилит – хостинг-панели, web-сервера, PHP-обработчика, базы данных, наиболее предпочтительная конфигурация с точки зрения скорости и быстродействия – Nginx/PHP-FPM/MySQL, при чём, процессы должны между собой взаимодействовать через отдельный файл сокета, а не чрез общий unix-socket. Более подробно настройку сервера описывал здесь – Предварительная удалённая настройка выделенного VPS сервера.
После того, как мы убедились, что web-сервер работает, а php-обработчик обрабатывает скрипты – можно приступать к непосредственному переносу сайта Bitrix.
Этап второй – перенос файлов сайта и базы данных Битрикс 1С на новое настроенное окружение.
- Создание сжатых архивов файлов сайта Bitrix и его базы данных;
- Перенос файлов архивов на новый сервер;
- Развёртывание файлов сайта и экспорт дампа БД в базу данных;
Для этого подключаемся по SSH в консоли к старому хостингу или серверу, где находится сайт – любой хостер предоставляет такую возможность, выдавая логин/пароль для доступа.
Создаём архивы с каталогом сайта и дампом базы данных. ВНИМАНИЕ! Архивировать нужно целый каталог полностью, обычно это public_html, он может называться и по-другому, в зависимости от типа дистрибутива ОС и настроек.
Каталог архивируется в файл архива командой tar -zcvf archive.tar.gz path/to/files/, имя каталога указывается со-слешем на конце. Скопировать отдельно файлы внутри каталога, без обёртки, методом path/to/files/* – не получится, т.к. в этом случае НЕ СКОПИРУЮТСЯ скрытые файлы, имя которых начинается с точки, без которых сайт на новом сервере работать просто не будет.
Наличие скрытых файлов в движке Bitrix я иначе как – диверсией от разработчиков – назвать не могу. Кстати, копирование по шаблону cp …/* в другой каталог тоже не копирует скрытые файлы и каталоги.
Создаём архив с дампом базы данных – для этого используем команду mysqldump -u USER -p DATABASE | gzip > database.sql.gz , где подставляем собственные имена пользователя и БД, а так же своё имя архива (по желанию), при запросе от MySQL указываем пароль пользователя, которому принадлежит БД. Все эти данные можно найти в файле конфигурации Bitrix, если они не записаны у вас отдельно.
Копируем оба файла архива на новый сервер: для этого подключаемся по ssh к новому серверу, и посредством команды scp в консоли (защищённое копирование через ssh) - scp user@virtualhost.ru:~/archive.tar.gz ~/ - сливаем файлы на новый сервер.
Это гораздо быстрее – в десятки раз!!!, чем копировать по ftp файлы отдельно. К тому же безопасно, т.к. копирование происходит в зашифрованном виде.
Внимание! Копировать файлы нужно предварительно подключившись по ssh к новому настроенному серверу, и из его кнсоли! Т.е. команду копирования вводим в консоли нового сервера, чтобы скопировать на него архивы со старого сервера или хостинга. В обратном порядке это работать не будет, связано с особенностью прав на чтение/запись.
После того, как файлы скопированы на новый сервер, разворачиваем их там: разархивируем каталог с файлами сайта - tar -zxvf archive.tar.gz -C path/to/dir, указываем своё имя архива и путь распаковки, если надо – по окончании переименовываем сам распакованный каталог, согласно конфигурации web-сервера.
Разархивируем и сразу же экспортируем дамп с данными БД в базу данных на новом сервере - gunzip < database.sql.gz | mysql -u USER -p DATABASE, при этом, новый пользователь и сама БД там должны быть уже созданы! Если пользователь, имя БД и пароль на новом сервере отличаются – то их надо откорректировать в файле конфигурации сайта Bitrix.
На этом непосредственный перенос файлов и БД сайта Битрикс завершён, но для работы сайта этого недостаточно, необходима ещё настройка web-сервера и конфигурация виртуального хоста, редактирование DNS-записей, для его полноценной работы.
Более подробно процесс архивации, копирования, и извлечения данных из архивов с экспортом в БД подробно описан в отдельной статье на моём сайте – Оперативный перенос сайтов и баз данных с виртуального хостинга на VPS-сервер.
Третий этап – конфигурация хоста и web-окружения.
- Настройка записей DNS;
- Создание нового виртуального хоста
- Настройка файла конфигурации виртуального хоста
Самым первым делом, идём в DNS-редактор вашего регистратора доменов, или сервиса, которому вы делегировали управление доменом, и изменяем A-запись, прописывая в ней НОВЫЙ ip вашего сайта на новом сервере.
ВНИМАНИЕ! Категорически рекомендую докупить новый ip для сайта у хостера, разделив таким образом управление сервером – с одного ip, который идёт в комплекте с VPS, а доступ к сайту – с другого ip, с которого недоступен ssh, хостинг-панель и прочие сервисы управления, типа php-myadmin. Это необходимо с точки зрения распределения нагрузки и безопасности. Стоить это будет всего лишь 2 евро (у OVH.COM) и платить надо лишь один раз, выделенный ip предоставляется вам бессрочно.
Следующий шаг – настройка нового виртуального хоста, который желательно создать ещё ДО переноса сайта – создаётся новый отдельный каталог по имени домена, и в него уже копируются данные из архива, так же – создаётся новый файл виртуального хоста для web-сервера Nginx, который надо настроить. Впрочем, виртуальных хост можно создать и после копирования архивов на новый сервер, и уже копировать из архива данные в новый созданный каталог сайта.
Самый важный этап: непосредственно, конфигурация файла виртуального хоста для сайта, после каждого внесения изменений его необходимо проверять на валидность и наличие ошибок, командой nginx –t, с правами sudo.
При некорректно настроенном файле конфигурации, или наличии ошибок в нём, сайт не будет работать. В приведённом ниже коде описана минимальная работоспособная конфигурация для сайта Bitrix на веб-сервере Nginx. Полную настройку веб-сервера мы здесь не рассматриваем, ибо это уже выходит за рамки данной статьи.
Содержимое файла конфигурации виртуального хоста Bitrix для веб-сервера Nginx:
server {
listen 146.59.181.71:80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://$host$request_uri;
}
server {
listen 146.59.181.71:443 ssl http2;
server_name yourdomain.com www.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
root /home/admin/web/yourdomain.com/public_html;
index index.php index.html index.htm;
access_log /var/log/nginx/domains/yourdomain.com.log combined;
access_log /var/log/nginx/domains/yourdomain.com.bytes bytes;
error_log /var/log/nginx/domains/yourdomain.com.error.log error;
location = / {
index index.php index.html;
}
location / {
try_files $uri $uri/ @bitrix;
}
location ~ \.php$ {
try_files $uri @bitrix;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9002;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
}
location @bitrix {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9002;
fastcgi_param SCRIPT_FILENAME $document_root/bitrix/urlrewrite.php;
}
location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ {
expires max;
}
error_page 403 /error/404.html;
error_page 404 /error/404.html;
error_page 500 502 503 504 /error/50x.html;
location ~* "/\.(htaccess|htpasswd)$" {
deny all;
return 404;
}
}
В первом блоке кода прописан 301 редирект с 80 на 443 порт, т.е. с незащищённого на защищённое соединение. Далее, указываем, какой ip слушать, на каком порту, шифрование, тип протокола – HTTP2, имя домена (заменить на ваше), SSL-сертификаты – должны быть сгенерированы и установлены, корневую директорию сайта (где лежат скопированные файлы сайта), файлы логов доступа и ошибок, блок обработки php, блок кеширования, страницы ошибок, и запрет на доступ к скрытым файлам и файлам настроек.
ВНИМАНИЕ! Никогда бездумно не копируйте чужой код, если не понимаете, что в нём!
Приведённой выше конфигурации хоста в 90% случаев вполне хватает для нормальной работы сайта на Bitrix, но – не всегда. Иногда дополнительно необходимо прописать переменные окружения php, в частности – адреса каталогов, где расположены рабочие агенты Bitrix.
Такие случаи весьма уникальны и индивидуальны, невозможно рассмотреть каждый из них, поэтому ограничимся основной конфигурацией. Для точной настройки виртуального хоста необходимо изучение файлов конфигурации httpd.conf и .htaccess на предыдущем сервере, их анализ и вычленение основных директив настройки.
Кстати, при восстановлении из резервной копии, скрипт restore.php тупо создаёт новый дефолтный файл .htaccess, предназначенный для веб-сервера Apache2. Естественно, он совершенно не применим, если на новом сервере стоит связка Nginx+PHP-FPM, старый же файл .htaccess (с предыдущего хостинга или сервера) тупо переименовывается в htaccess.restore, и находится в одном каталоге с файлами сайта.
После всех вышеперечисленных действий, в подавляющем большинстве случаев сайт Bitrix будет работоспособен после переноса, и все страницы будут грузиться в штатном режиме.
Есть частая проблема, когда после копирования или переноса при загрузке главной страницы выскакивает форма авторизации. Проблема заключается как-раз в потере при переносе скрытых файлов из корневого каталога сайта, начинающихся с точки.
Казалось бы, сайт перенесён, страницы загружаются, всё в порядке. Но это ещё не всё, очень важным моментом является взаимодействие с посетителями и администратором посредством отправки сообщений электронной почты, которые по умолчанию в Bitrix не настроены.
В таком виде, письма просто не будете доходить до пользователей и администратора (о регистрации, новых заказах, обновлениях, письма рассылок, и т.д.), т.к. будут попросту отметаться почтовыми службами, как спам.
Необходима настройка домена – как отправителя, достигается редактированием или написанием новых DNS-записей в редакторе, а так же – настройка SMTP сервера, который будет отправлять сообщения от движка Bitrix.
Я обычно для этих целей использую серверную утилиту MSMTP, которая перехватывает отправку php-функцией mail(), используемой по умолчанию движком сайта, если не установлено никаких дополнительных модулей отправки.
И только после всех вышеперечисленных манипуляций с переносом, и настроек, сайт Bitrix сможет полноценно функционировать.
Ну и напоследок:
Перенос сайта Bitrix на новый домен
Если вы хотите сменить доменное имя своего сайта, тот в этом случае ничего никуда переносить не нужно, вполне достаточно сменить А-запись в DNS-редакторе домена, в которой указать просто новое имя сайта.
Так-же, необходимо прописать новый домен в админке сайта, в основных настройках.
Если же вы дочитали до конца, но не всё поняли, или вообще ничего не поняли, но вам срочно надо перенести сайт 1С Битрикс на новый сервер (или настроить новый VPS сервер) – вы можете воспользоваться моими услугами, оставив заявку здесь – Оперативный перенос сайтов, или здесь - Настройка и администрирование выделенных VPS серверов.
При обращении вы гарантированно получите бесплатную консультацию, а при указании промокода BITRIX в сообщении - скидку 20% на услуги настройки, администрирования или переноса сайта.
Приветствуются всяческие вопросы)
