Вариантов перенести сайт на другой сервер несколько. Рассмотрим все по порядку, со своими подводными камнями.
1. Бэкапирование средствами Битрикса
Самый простой вариант. Подходит для небольших проектов и требует много места на сервере. Этим способом можно бэкапироваться даже на обычном виртуальном хостинге.
Действуем стандартно. Заходим в админку в раздел Настройки - Инструменты - Резервное копирование - Создание резервной копии. Оставляем всё по умолчанию и делаем бэкап на наш сервер (можно и в облако Битрикса). В зависимости от размера сайта процесс может занять от 3 минут. Далее получаем ссылку на переноса и используем ее в restore.php на новом сервере.
Тут важно, чтобы у вас и на текущем и на новом сервере было достаточно места на архив и полную его распаковку. Обычно это х4 к размеру полного архива.
2. Бэкапирование средствами Битрикса + перенос файлов с сервера на сервер
Для реализации этого пункта потребуется SSH доступ.
Воспользуемся пунктом 1 и немного внесем правки:
- 1 - включаем экспертные настройки
- 2 - включаем бэкап базы данных
- 3 - исключаем из базы ненужные таблички
- 4,5 - архивируем ядро и публичную часть
- 6 - исключаем upload как самую "весомую" папку на сервере
- 7 - ставим размер части архива. В зависимости от настроек сервера можно использовать от 100 до 500 Мб. На моем опыте при установке больших значений повышается вероятность ошибки.
Далее создаем резервную копию, восстанавливаем ее на новом сервере и вручную переносим папку upload с помощью rsync через ssh доступ. Команда следующая (запускаем на новом(!) сервере):
rsync -avz --rsh='ssh -p22' --ignore-existing user_remote@1.1.1.1:/home/bitrix/www/upload/ /home/bitrix/www/upload/user_remote и 1.1.1.1 - это данные старого сервера (с которого переносим данные). После ввода команды нужно будет ввести пароль пользователя user_remote
Параметр --ignore-existing позволяет игнорировать существующие файлы. При первоначальном переносе он не имеет смысла, но при возможной докачке сильно выручает.
Аплоад может загружаться несколько часов в зависимости от его размера.
3. Полный серверный бэкап
В этом случае бэкап базы делаем серверными командами, а файлы переносим вручную с помощью rsync, как в примере выше. Там мы переносили только upload, а тут будем переносить все папки.
Делаем бэкап базы данных командой
mysqldump -u root -pпароль имя_базы > database_backup.sqlПотом копируем себе бэкап на всякий случай и заливаем его на новый сервер. После чего запускаем команду восстановления
mysql -u root -pпароль имя_базы < фал_выгрузки.sqlПосле успешного восстановления базы переходим к копированию файлов. После копирования нужно в dbconn.php записать данные по новой базе данных.
Данный способ отлично выручает, когда на текущем сервере мало места, его не хватает на файловый архив средствами Битрикса.
4. Клон виртуального сервера
С этим способом не работали, иногда хостинг провайдер делает это в рамках поддержки. Но на больших проектах могут быть неочевидные проблемы из-за различия в конфигурациях.
Нестандартные ситуации при переезде на другой сервер
Ошибка дампа базы данных
Столкнулись с историей, когда на старом сервере mysqldump выдавал ошибку. Решили с помощью микросубд и бэкапом через нее.
После восстановления отличаются ID файлов в iblock_element
При переезде одного большого проекта с помощью Битриксового бэкапа базы данных и восстановления ее через restore.php столкнулись с изменением привязок к файлам (ID картинок в элементах после восстановления не соответствовали). Соответственно, на сайте не показывались картинки - они были битыми. Ситуацию решили через бэкап по варианту 3, полностью исключив битриксовые скрипты из процесса.
[будет дополняться по мере возникновения новых нештатных ситуаций]
Больше полезных материалов в нашем Telegram канале. Вступайте и будем на связи! https://t.me/bf_conversion
