Перенос сайта на другой сервер - через восстановление и вручную
Переносим сайт на другой сервер: штатным восстановлением или руками, если оно не справляется.
Решение
Восстанавливаем штатным скриптом:
# кладём скрипт восстановления в пустой корень нового сайта и открываем в браузереcurl -o /home/bitrix/www/restore.php https://www.1c-bitrix.ru/download/scripts/restore.phpchown bitrix:bitrix /home/bitrix/www/restore.php# после разворота скрипт удаляют: он даёт доступ к сайту любому, кто его найдётСкрипт скачивает архив копии и разворачивает файлы с базой сам. Он рассчитан на копии, сделанные штатным резервным копированием, и на сайты в несколько гигабайтов; на больших проектах он упирается во время выполнения.
Переносим руками, когда штатный путь не проходит:
# файлы: сохраняем права и владельца, иначе веб-сервер их не прочитаетrsync -az --delete /home/bitrix/www/ new-server:/home/bitrix/www/# база: дамп с сжатием, без блокировки таблиц на боевом сервереmysqldump --single-transaction --quick sitedb | gzip > /tmp/sitedb.sql.gz# файлы и база должны быть снимком одного момента времениРучной перенос предсказуемее на больших сайтах: каждый шаг виден и повторяем. Файлы и база едут отдельно, и порядок между ними не важен - важно, чтобы они были одного момента времени.
Правим настройки подключения к базе:
// /bitrix/.settings.php и /bitrix/php_interface/dbconn.php'host' => 'localhost','database' => 'sitedb','login' => 'sitedb_user','password' => $newPassword,Доступ к базе прописан в файлах, а не в админке. Пока эти файлы указывают на старый сервер, сайт на новом месте не поднимется вовсе - ни публичная часть, ни админка.
Проверяем сайт после переезда:
# права на файлы: их теряют чаще всего при копировании от рутаchown -R bitrix:bitrix /home/bitrix/wwwfind /home/bitrix/www/bitrix/cache -type d -delete 2>/dev/null # сбрасываем кэшtail -30 /var/log/php-fpm/error.log# после переноса сверяют владельца файлов и права на каталоги# и отдельно проверяют задания по расписанию: они переносятся не всегдаКэш переезжает вместе с файлами и хранит внутри пути старого сервера. Его сбрасывают первым же делом, иначе разбор сбоев превращается в гадание по чужим ошибкам с прежней машины.
Адрес сайта в настройках продукта меняют отдельным действием. Пока там остаётся старый домен, письма и служебные переадресации продолжают вести на прежний сервер, и посетитель об этом никак не догадывается.
Порядок переезда всегда один: новый сервер с окружением, потом файлы и база, потом настройки подключения, и только в конце переключение домена. Обратный порядок оставляет посетителей на сайте, который ещё не готов их принять.
Лицензия привязана не к серверу, а к домену и редакции. Перенос сам по себе её не ломает, но копия боевого сайта на тестовом домене требует отдельного ключа или работы в режиме ограниченной функциональности.
Типичные проблемы
Восстановление зависает на середине.
Скрипт упирается во время выполнения или в память на большом архиве. На таких сайтах переносят файлы и базу руками.
Сайт открывается белой страницей.
Настройки подключения к базе указывают на старый сервер. Их правят в файлах настроек, а не в админке.
Часть страниц отдаёт ошибки после переезда.
Переехал кэш со старыми путями. Его удаляют целиком после переноса.
Веб-сервер не читает файлы сайта.
Копирование выполнялось от имени администратора, и владельцем файлов стал он. Владельца возвращают пользователю веб-сервера.
Письма уходят со ссылками на старый домен.
В настройках сайта остался прежний адрес. Он задаётся отдельно от адреса в строке браузера.
Частые вопросы
Можно ли перенести сайт без остановки?
Полностью без простоя - нет: между копией базы и переключением домена всегда есть окно. Его сокращают, перенося файлы заранее и снимая дамп базы в последний момент.
Что делать, если архив не скачивается на новый сервер?
Скопировать его руками любым способом и указать скрипту локальный файл. Скачивание с чужого сервера ломается на закрытых портах и на медленном канале.
Нужно ли переносить кэш и временные файлы?
Нет, они пересобираются сами. Их исключение из переноса заметно сокращает объём и время.
Как проверить, что перенос удался?
Проверкой системы из админки, тестовой оплатой и почтой. Открывшаяся главная страница ещё ничего не доказывает.
Смежное
-
Резервные копии и перенос - оглавление подтемы
-
Не создаётся резервная копия - откуда берётся копия для переноса
-
Установка и настройка BitrixVM - подготовка нового сервера
-
Call to a member function on null: причины по убыванию частоты - ошибка после неполного копирования файлов
-
Illegal mix of collations: разные кодировки таблиц и соединения - расхождение кодировок после переезда
-
Could not start session by PHP: сессия не стартует - путь к сессиям от прежнего сервера
-
Сервер и поиск - устройство сервера целиком
-
Сайты в пуле BitrixVM: добавление, каталоги, права и доступ - подготовка места на новом сервере
-
Обновление продукта: подготовка, порядок, откат - зачем копия перед обновлением
-
Резервное копирование: расписание, состав, хранение и проверка - откуда берётся копия для переезда
-
Дубли товаров после обмена: поиск и разведение - что проверить после переезда магазина
-
Восстановление из резервной копии: порядок, отказы, проверка - разбор отказов при развороте
-
Смена домена сайта: настройки, куки, защита, редиректы - переезд на другое имя, а не сервер
-
Права на файлы и папки: файловая система и права структуры - владелец файлов после переноса
-
Выкладка на боевой: порядок, структура, откат - перенос только своих правок
-
Стенд из копии боевого: подъём, обезличивание, отрезанные связи - перенос ради стенда, а не переезда
-
Переезд крупного магазина: окно простоя, два прохода, откат - когда сайт весит сотни гигабайт
-
Восстановление из копии не проходит: разбор причин - разбор отказа при переносе через копию
-
Перевод проекта на UTF-8: файлы, база, настройки - если переезд совмещают со сменой кодировки
-
После переезда часть сайта молчит - что проверить, когда сайт открылся, а подсистемы стоят