Перенос сайта Битрикс на другой хостинг

Сегодня научимся грамотно переносить сайт, сделанный на Битрикс с одного хостинга на другой хостинг или VPS/VDS.
Вообще, без разницы куда переносить, предварительные настройки сделать все равно придется в обоих случаях.

Итак, имеем рабочий сайт на Битрикс и готовый купленный хостинг, куда переносить сайт, доступы к новому хостингу имеются, остается только перенести сайт.

Реально существует ЧЕТЫРЕ способа переноса сайта на другой хостинг:

  1. Создание локальной резервной копии сайта и перенос на новый хостинг с помощью WinSCP.
  2. Восстановление резервной копии сайта на новом хостинге из облака "1С-Битрикс".
  3. Создание локальной резервной копии сайта и перенос на новый хостинг с помощью консольной программы в Linux для загрузки файлов "wget".
  4. Синхронизация сайта на другой хостинг с помощью консольной программы в Linux для синхронизации файлов и каталогов "rsync".

Предварительное тестирование сервера/хостинга

Перед тем, как переносить сайт, место назначения (Сервер/Хостинг) необходимо протестировать готовым для Битрикс скриптом bitrix_server_test
Все выявленные проблемы скрипт подсветит красным цветом, зеленым цветом будут подсвечены корректные настройки, которые не требуют вмешательства, а вот красные надо исправлять.
Вообще, вы можете восстановить как-нибудь Битрикс с некорректными настройками сервера, но велика вероятность, что будут потом проблемы всплывать или что-то будет работать неправильно на сайте, лучше исправить, особенно если кодировка сервера отличается от кодировки сайта.

Если хостинг/сервер позволяет изменять настройки PHP в файле php.ini, то я всегда в самом конце этого файла добавляю эти настройки, они просто перезапишут эти же настройки выше, изменять в файле больше ничего не нужно.

Настройки php.ini для Битрикс в кодировке UTF-8

[PHP]
;error_reporting = E_ALL
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
;log_errors = On
;error_log = "/var/log/php/PHP_errors.log"
short_open_tag = On
max_execution_time = 60
max_input_vars = 10000
max_input_nesting_level=100000
memory_limit = 300M
session.use_trans_sid = 0
display_errors = On
post_max_size = 200M
upload_max_filesize = 200M
max_file_uploads = 30
output_buffering = 4096
default_socket_timeout = 60
allow_url_fopen = Off
session.gc_probability = 1
realpath_cache_size=4096k
mbstring.internal_encoding = UTF-8
mbstring.func_overload = 2
zlib.output_compression = Off
zlib.output_compression_level = -1
zend.enable_gc = On
expose_php = Off
report_memleaks = On
session.entropy_file = /dev/urandom
session.entropy_length = 128
date.timezone = Europe/Moscow
;date.timezone = "Asia/Novosibirsk"

[MySQL]
mysql.allow_persistent = Off

Настройки php.ini для Битрикс в кодировке Windows-1251

// Все настройки как и выше, но надо заменить UTF-8 на cp1251
mbstring.internal_encoding cp1251
mbstring.func_overload = 0

Если нет возможности самому изменять настройки php.ini:

  • либо скиньте все настройки хостеру и попросите его это сделать;
  • либо пробуйте задавать их в  в секции mod_php5 файла .htaccess, который в корне сайта.

<IfModule mod_php5.c>
    php_flag allow_call_time_pass_reference on
    php_flag session.use_trans_sid off
    php_value mbstring.func_overload 2
    php_value mbstring.internal_encoding UTF-8
</IfModule>

Все настройки описывать не хочу, попробуйте догадаться опытным путем:
  • если значение опции число или строка - php_value
  • если значение опции флаг On или Off -  php_flag
Обратите внимание! Если сайт будет работать в кодировке UTF-8, то перед восстановлением сайта обязательно надо настроить в php.ini настройки mbstring, иначе сайт не восстановите, т.к. через .htaccess данные настройки не изменить.

Как выше было сказано, есть проблема: с версии PHP 5.2.8 значение опции mbstring.func_overload через .htaccess сайта изменить нельзя!
Воздействовать на нее можно только в настройках хоста апача (на VPS) или в конфиге php, можно написать хостеру, чтобы он именно для вашего домена установил эти настройки.

Также замечено. Вам  хостер отписался, что, вроде как, все сделал, но на самом деле, он ничего не сделал, он просто сделал вид, мол, что-то сделал, а иногда даже сделал, но все неправильно или как попало, часть настроек установил, часть нет, такие случаи тоже бывают, особые случаи, имейте это в виду, все проверяйте.
Все рекомендуемые для Битрикс требования есть в мануале Bitrix Framework и хостинг, обязательно прочитайте.

Все, все необходимые настройки сервера для Битрикс установили, протестировали, ошибок нет при тестировании, переходим к переносу сайта на новый хостинг и его восстановлению.

Перенос сайта

1. Создание локальной резервной копии сайта Битрикс и перенос на новый хостинг с помощью WinSCP.

Если проблем нет с конфигурацией сервера, можно непосредственно приступать к переносу сайта, алгоритм переноса следующий:

  1. Через админку сайта создаем полную локальную резервную копию (файлы и БД).
    О том, как создать полную резервную копию сайта для переноса читайте в статье  Резервное копирование в битрикс;

  2. Закачиваем архив сайта на новый сервер/хостинг.
    Переносить файлы между сервером/хостингом можно с помощью программы WinSCP и PuTTY, как их установить и настроить Вы можете прочитать в статье  Установка и настройка WinSCP и PuTTY;

  3. Закачиваем файл restore.php на сервер, с его помощью и будем восстанавливать сайт;

    Обратите внимание! В момент восстановления сайта через данный файл в корне сайта либо не должно быть файла .htaccess, либо закомментируйте или удалите его, иначе будут проблемы.

  4. В адресной строке браузера наберите http://ваш_сайт/restore.php и нажмите кнопку Далее.

  5. Дальше все пойдет пошагово, сначала распакуйте архив с файлами на сервер, потом укажите доступы к БД на новом сервере (если нет БД, ее необходимо создать) и все на этом, сайт должен восстановиться полностью, жмите кнопку "Перейти на сайт";

  6. Но это еще не все, сайт уже работает, но есть еще один важный момент.
    После восстановления сайта создается новый файл .htaccess, а старый переименовывается в .htaccess.restore, его нужно вернуть обратно, обратно .htaccess.restore в .htaccess, т.к. в нем могут быть всякие 301 редиректы и прочие конфиги сервера, иначе вы можете убить все продвижение сайта, последствия будут неприятные.

  7. Но и это еще не все, далее Вам необходимо авторизоваться на сайте, который мы перенесли и еще раз протестировать хостинг штатными инструментами тестирования в Битрикс, еще может много чего всплыть, это :
    Панель производительности

    Рабочий стол -> Настройки -> Производительность -> Панель производительности

    Сканер безопасности

    Рабочий стол -> Настройки -> Проактивная защита -> Сканер безопасности


Здесь я из своего опыта хочу добавить:
- В "Панели производительности" ошибок быть не должно точно, крайне редко что-то там будет красным;
- В "Сканере безопасности" всех ошибок не исправить на хостинге точно, которые относятся к настройкам apache2, nginx и т.д., но на VPS/VDS можно исправить и даже нужно!

Вот и весь перенос сайта Битрикс с одного хостинга на другой, на все 30-60 минут, если без плясок. 

Все остальные способы опишу чуть позже.

2. Восстановление резервной копии сайта на новом хостинге из облака "1С-Битрикс".

3. Создание локальной резервной копии сайта и перенос на новый хостинг с помощью консольной программы в Linux для загрузки файлов "wget".

4. Синхронизация сайта на другой хостинг с помощью консольной программы в Linux для синхронизации файлов и каталогов "rsync".

Заключение

Свои сайты переносить можно не боясь, настроили хостинг для Битрикс, восстановили сайт из резервной копии, все, процесс завершен.

А вот, если вы работаете в веб-студии, которая готова бездумно перенести все сайты на планете на самые дешевые хостинги, да по 10 штук на аккаунт, то тут вы столкнетесь с очень серьезными проблемами, часто даже не решаемыми, и что делать?

- Первая ситуация:
Вы перенесли сайт, все ок, забыли уже про него, через 1-2 недели приходит от клиента весточка, мол: "Не работает загрузка файлов в статьи", и кто будет решать проблему?
Конечно Вы ее будет решать, вы же переносили сайт, Вам нужно будет найти проблему и исправить ее, если хватит знаний и опыта, если не хватит, Вы плохой переносчик сайтов, а если загрузчик на flash, ой... вей...

- Вторая ситуация:
Вы перенесли сайт, все ок, забыли уже про него, через 1-2 недели приходит от клиента весточка, мол: "У нас была на сайте панель добавления товара, вторая админка, в одной админке мы добавляем статьи, страницы, а в другой админке у нас магазин, там каталог отдельно наполняется", ну так получилось, две админки у одного сайта, и кто будет решать проблему?
Конечно Вы ее будет решать, вы же переносили сайт, Вам нужно будет найти проблему и исправить ее. А когда Вы начали разбираться, оказалось, что где-то там в папке /admin/engine/controller/ была символьная ссылка с папки "catalog" на папку, внимание "/var/www/user/some_dir_name", ок, тут вы понимаете, что админка вообще где-то в другом месте сервера лежит, подключаетесь к старому серверу и тут Вас ждет очень неприятный сюрприз, аккаунт уже удален за неуплату, все данные потеряны, продолжать не вижу смысла...

- Третья ситуация:
По файлам на сервере видно, что сайт вроде как один, но БД почему-то 4шт., клиент не в курсе, ок, все сделали, восстановили сайт, пробежались по первым страничкам, вроде все работает. Потом оказалось, что те 3 базы данных просто старые, ненужные, ок, а в чем подвох?
Вы перенесли сайт, все ок, забыли уже про него, старый аккаунт также был удален, через 1-2 недели приходит от клиента весточка, мол: "У нас весь сайт отображается нормально, но в некоторых разделах все кракозябрами, все статьи и новости", вы понимаете, что бэкап был кривой, ок, каким-то чудом БД осталась жива на компе, открываете ее и понимаете, что Ваш скрипт, который делал бэкап сайта не учел, что часть таблиц БД в разных кодировках (я про самописку), и сделал экспорт БД в одной кодировке, соответственно и кракозябры у этих таблиц, что делать? комментарии излишни...

Вывод

В общем, свои сайты переносите смело, если делали их грамотно без привязки к серверу, всегда будете в плюсе.

С переносом других сайтов будьте осторожны, а лучше этого не делать по возможности, т.к. таких проблем можете заработать, особенно это перенос самописок, их могут написать так, что аж служебные/админские папки раскидывают везде по серверу, или несколько панелей к одному сайту может быть в разных местах, даже на разных аккаунтах, я и такое встречал, кто на что горазд, так и делает.
Т.е. так сайт разработают, что на другой сервер он уже либо не переедет совсем, либо его перенос будет стоить дороже разработки, т.к. собирать его придется по всему серверу и конфигурировать VPS/VDS под этот сайт.
Вы никак про это все не узнаете при переносе, только когда все вылазить начнет со временем у клиента, а старый сервер уже будет отключен и стерт с лица Земли.

Успехов Вам, не дайте себя обмануть!

Обновлено: 11.08.2015 21:00:00
Установка модуля