Как развернуть бэкап битрикс

Нюансы восстановления резервной копии сайта на «Битрикс»

Приступая к животрепещущей теме резервного копирования на «Битрикс», прежде всего хотелось бы поблагодарить разработчиков, реализовавших автоматическое резервное копирование в облачное хранилище в версии 12.0.8 и более поздних. В ранних версиях эта возможность не предусматривалась и резервное копирование сайта требовало непосредственного управления администратора или же довольно сложных ухищрений для автоматизации процесса своими силами. Мы обязательно вернемся к этому замечательному функционалу в будущем, а сейчас обсудим некоторые детали восстановления резервной копии сайта.

1. Совместимость формата *.tar.gz

Формат архива резервной копии *.tar.gz предназначен для распаковки файлом restore.php и корректно распаковывается только с его помощью. Распаковывать другими архиваторами целесообразно только для познавательных нужд или получения отдельных файлов скриптов и изображений, по какой-то причине утерянных. Делать собственные сборки и модификации резервной копии при помощи архиваторов rar, zip, 7z нецелесообразно, такой архив не будет распакован файлом restore.php.

2. Пошаговое восстановление резервной копии

А) Подготовьте окружение и архив

На хостинге или локальной машине с полностью новой базой данных, или установленным заново веб-окружением помещаем в папку www файл restore.php. Актуальную версию restore.php скачайте на сайте «Битрикс». Загрузите также в папку www архив резервной копии с расширением .tar.gz

Б) Запустите восстановление

Сделайте это командой http://ваш_сайт:6448/restore.php

В) Действия на Первом шаге

Choose the language: [RU] – выберите язык

Archive name: [200906031441_b2c12992.tar.gz] — выберите имя архива

Step (sec.): [30] – укажите длительность шага распаковки

Restore – перейдите ко Второму шагу

Г) Действия на Втором шаге

Database dump file: [200906031441_b2c12992.sql] — выберите имя архива базы данных

User Name: [‘’] — не заполняйте

Password: [‘’] — не заполняйте

Database Name: [ ] — не заполняйте

Database Host: [localhost:31006] – допустимы только имена localhost:31006 или localhost:3 6448 . Таковы настройки базы данных по умолчанию.

Create database [ ] – не ставьте флаг (галочку).

Резервное копирование и бэкап веб-сайта

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

1. Локальная резервная копия сайта без многосайтовости

В 1С-Битрикс резервное копирование уже почти совершенно, как и кэширование, есть целый раздел настроек для резервирования сайта, для этого переходим в:
Настройки — Инструменты — Резервное копирование — Создание резервной копии

Тут выбираем Размещение резервной копии — в папке сайта

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

Далее рассмотрим все заданные настройки детально по пунктам.

1.1. Архивировать БД (Базу данных)

Обязательно в архив отправляем БД и исключаем статистику, поисковый индекс и журнал событий, т.к. это все может занимать большой объем данных, чем больше БД, тем больше это будет занимать места

1.2. Архивировать ядро

Обязательно архивируем ядро (движок Битрикса, систему) иначе как его потом восстановить

1.3. Архивировать публичную часть

Обязательно архивируем публичную часть, это все, что видят посетители вашего сайта, внешняя его часть, открытая для просмотра, шаблон, файлы и разделы и т.д.

1.4. Исключить из архива файлы и директории по маске

Исключаем из архива файлы и директории по маске до версии Битрикс 12, в старших версиях типа Битрикс 16 в этом нет смысла, сейчас резервное копирование хорошо доработано, все эти папки он исключает сам, но все же есть нюансы, о них расскажу ниже.

Если Битрикс младше 12 версии, что надо исключить 100%:

/bitrix/backup — в старых версиях в бэкап летят все прошлые бэкапы и архив сайта бесконечно может расти, в итоге израсходовать все дисковое пространство сервера, наглядно можно заметить, когда например, кроном прилетят сообщения об ошибках, что невозможно что-то сделать или на сайте перестает работать ресайз изображений и все картинки расползаются по дизайну, шаблон сайта внешне просто разлетается.
Но все равно эта папка в архиве будет, т.к. в нее скрипт размещает дамп БД, для дальнейшего восстановления сайта, но прошлых бэкапов там уже не будет.

/bitrix/cache — исключаем неуправляемый кэш;

/bitrix/managed_cache — исключаем управляемый кэш;

/bitrix/stack_cache — исключаем файлы кэша с «вытеснением»;

/upload/resize_cache — исключаем файлы кэша ресайза изображений;
Это папка для динамического ресайза изображений с помощью API Битрикс, после восстановления сайта кэш автоматически будет создаваться при открытии страниц посетителями, изображения автоматически уменьшаются и один раз создается кэш, исходные изображения хранятся в других папках и с ними ничего не случится.
Также будет полезно избавиться от множества брошенных файлов в кэше, от неиспользуемого мусора.

Это были самые необходимые папки для исключения из бэкапа, что еще можно исключить?
Есть еще одна папка в которой хранятся всякие мастера и демо-решения

Это будет прилично занимать места в каждом бэкапе, в моем случае это базовая установка 1С-Битрикс редакция Бизнес размер папки 67 Мегабайт, но у вас может быть и больше, если установлены другие мастера.

Но если исключить всю папку, то вы можете потерять такой полезный мастер, как Местоположения 2.0, если вы разработчик, сможете вручную залить мастер взяв с другого сайта, когда понадобится, т.е. он может быть понадобится, а может быть и нет, всяко бывает, поэтому, если вы не разработчик, наверно самым правильным решением будет удалить ненужные мастера через админку, а нужные оставить для дальнейшего использования, вдруг понадобятся, удаляются мастера и решения в двух местах:

1.4.1. Сначала в списке установленных решений в разделе Marketplace необходимо Удалить, потом Стереть ненужные решения, у меня их четыре.

1.4.2. Далее чистим список мастеров от ненужных, в моем случае всего два мастера будут мусором, все остальное может пригодиться, в том числе и Мастер настройки Интернет-магазина

1.5. Исключаем из архива файлы определенного размера

Это вам пригодится для исключения из бэкапа больших файлов загруженных на сайт, те же архивы, видео и т.д, но если оно действительно не понадобится при восстановлении сайта.
Я всегда оставляю как есть, т.е. 0 кб, не приходилось ничего исключать.

1.6. Пропускать символические ссылки на директории

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

Далее идут настройки из раздела Режим архивации, которыми можно регулировать нагрузку на процессор и в целом на веб-сервер при создании бэкапа.

1.7. Шифровать данные резервной копии

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

1.8. Проверить целостность архива после завершения

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

1.9. Отключить компрессию архива

Отключив сжатие бэкапа мы снижаем нагрузку на процессор, но увеличиваем размер бэкапа на диске.
У меня железки мощные, поэтому я опцию не включаю.

1.10. Длительность шага и Интервал

Этими настройками также можно регулировать нагрузку на веб-сервер, но об этом расскажу ниже.
На большинстве хостингах важно установить Длительность шага не больше 29 сек. и Интервал не меньше 1 сек.

Опция напрямую зависит от настроек PHP вашего хостинга, по умолчанию у многих установлено в 30 сек.
max_execution_time = 30

Поэтому можете наблюдать такую ошибку, когда заданное вами время явно превышает допустимое на веб-сервере

При установленном значении в «0» архивация будет выполнена за один шаг.

Как проверить разрешенное сервером время выполнения php-скрипта?
— Можно опытным путем проверить, попробуйте установить Длительность шага 60 сек., если появится ошибка, пробуйте 31 сек, если есть ошибка, пробуйте 29 сек, если нет ошибки, значит 30 сек. ограничение.

— Можно в админке Битрикс узнать здесь:
Настройки — Инструменты — Диагностика — Настройки PHP

На этой странице увидим стандартную страницу настроек php.ini на веб-сервере

Находим опцию поиском браузера, в Firefox это Ctrl + F, но тут опять возникают вопросы, видим два столбца с разными значениями, куда смотреть, что действует?

Local Value — показывает настройки хоста (сайта) в котором вы просматриваете настройки, эти значения локальные в рамках сайта, они могут задаваться в самом Битрикс в файлах
/bitrix/php_interface/dbconn.php
.htaccess

Master Value — эти значения задаются в настройках сервера в файле php.ini в зависимости от окружения на вашем сервере, это может быть:
/etc/php5/apache2/php.ini
/etc/php5/fpm/php.ini
/etc/php5/cgi/php.ini
/etc/php5/cli/php.ini

А также данные значения также можно изменять и в конфигах для конкретного хоста на сервере, но пути к настройкам хоста в разных панелях управления сервером разные, для панели VESTA это:
/home/*user*/conf/web/apache2.conf
/home/*user*/conf/web/nginx.conf

где *user* — имя пользователя на сервере в котором запущен данный сайт, т.е. у вас может быть любой пользователь.

В панели управления сервером ISP Manager это может быть:
/etc/apache2/apache2.conf
/etc/apache2/conf.d/site.ru.conf

Но это еще не все места, зависит от администратора сервера, это самые основные.

Что я хотел этим сказать, чтобы вы не задавали в Local Value, значение в Master Value будет приоритетным и ограничивать настройку Local Value максимально разреженным значением.
Например, в Local Value = 60, а в Master Value = 30 , все равно через 30 сек работа скрипта будет прервана, а вот если в Local Value = 10, а в Master Value = 30 то скрипт будет прерван через 10 сек.

1.11. Максимальный размер несжатых данных в одной части архива

Системные ограничения php не позволяют делать размер одной части архива более 2 Гб, очень удобно хранить архивы в одном файле, но неудобно скачивать/закачивать такие большие файлы на сервер при медленном интернете и FTP-сервером вроде бы может быть наложено ограничение на загрузку больших файлов на сервер, возможно скачать получится, но с закачкой бэкапа на сервер возможен облом.

В этом случае рекомендую выбрать среднее значение в 700 — 1000 Мб, не сильно много будет файлов и небольшой размер.

2. Локальная резервная копия сайта при многосайтовости

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

а) Если архивировать полностью все сайты, то создается одна полная резервная копия сайта включая общую БД для всех сайтов в списке и две папки /bitrix и /upload а публичная часть остальных сайтов сохраняется в архиве в папке типа /bitrix/backup/sites/ID_сайта

Для восстановления всех сайтов разработчик должен вручную перенести папки публичной части сайтов в соответствующие папки на сервере с созданием соответствующих символьных ссылок на сайты, а полностью восстанавливается скриптом restore.php только один главный сайт, который первый в списке.

Но это уже отдельная тема, я расскажу вам о ней позже, а выглядит в архиве это вот так

б) Если архивировать все сайты раздельно, тогда у не главных сайтов создается архив только публичной части этого сайта + полный бекап БД, а папки /bitrix и /upload будут только у главного сайта в архиве.

Обратите внимание в этом случае на размеры сайтов в архиве, на каждый сайт отдельный бэкап, при этом только в одном главном сайте полностью все данные кроме других сайтов, которые будут отдельно.

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

3. Резервное копирование сайта в облако 1С-Битрикс

Данный вид резервного копирования доступен если:

• Сайт на активной лицензии 1С-Битркс
• Установлен модуль Облако 1С-Битрикс (bitrixcloud)
• Доступен на сервере php-модуль mcrypt

Если модуль облачных сервисов 1С-Битрикс не установлен, вы увидите такую надпись

Если здесь что-то не работает, можете проверить активность лицензии сайта, она должна быть активна, проверяется на странице Обновление платформы, в строке Обновления доступны вы увидите дату окончания активности лицензии, тогда и следует продлить ее.
Marketplace — Обновление платформы

Но если лицензия уже закончилась, то вы увидите такое сообщение на этой странице, в этом случае воспользоваться облаком вы уже не сможете, только локальная резервная копия остается.

В моем случае лицензия была активна, но не установлен модуль облачного резервного копирования, устанавливаются родные и встроенные Битрикс модули здесь по кнопке Установить
Настройки — Настройки продукта — Модули

Далее возвращаемся к созданию резервной копии и без всяких настроек создаем выбираем размещение резервной копии в облаке 1С-Битрикс и нажимаем Создать резервную копию

Далее вводим пароль для шифрования архива, обязательно его запомните или где-то запишите, если забудете, восстановить бэкап будет невозможно без пароля.
Пароль рекомендуется не менее 6 знаков длинной с использованием спецсимволов.

В облаке будет храниться только 3 последних бэкапа.
Если место в облаке ограничено, то для сохранения последней копии удалятся все предыдущие.
Если не хватает места для сохранения единственной копии, то будет выведено предупреждение.

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

При создании резервной копии в облако настройки немного изменятся

• Шифровать данные резервной копии = ВКЛ
• Исключить из базы данных статистику, ПИ, ЖС = ВЫКЛ
  
• Максимальный размер несжатых данных в одной части архива = 100Мб
• А также в архив будет включена резервная копия БД, ядро и публичная часть, т.е. полный бэкап будет резервироваться в облаке.

После создания резервной копии в облаке вы можете в этом убедиться перезагрузив страницу и открыв Экспертные настройки, они будут такими

Вот столько маленьких файлов будет загружаться в облако в пределах 100 Мегабайт

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

Обратите внимание!
а) Резервную копию сайта из облачного хранилища 1С-Битрикс можно только восстановить.

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

4. Рекомендации по снижению нагрузки на сервер при резервном копировании сайта на 1С-Битрикс

Как я выше говорил, регулировать нагрузку на сервере при создании резервных копий служит вот этот раздел настроек

Данные на скрине настройки подойдут для более мощных серверов, если ваш сайт запущен на хостинге с ограничениями или просто слабое железо, то регулировать настройки и снижать нагрузку на сервер рекомендую таким образом:

4.1. Сначала уменьшаем Максимальный размер несжатых данных в одной части архива примерно до 700 Мб.
4.2. Потом уменьшаем Длительность шага примерно на 10 сек, т.е. до 20 сек.
4.3. Потом увеличиваем время Интервала до 2-3 сек и далее при необходимости.

Остальные настройки пока не трогаем, выглядеть это будет так:

Если этого еще много и бэкап по прежнему сильно нагружает сервер, еще увеливаем интервал и еще уменьшаем Длительность шага, вот так:

Если все еще не поняли логику, объясняю:

Длительность шага, сек. — чем меньше, тем меньшее время запущен скрипт, но чаще будет запускаться, например, за 30 сек. он может запуститься всего один раз и успеть сделать бэкап, а при 10 сек. он может сделать бэкап за три запуска, что уменьшит длительность нагрузки на процессор и общую нагрузку.

Я не рекомендую ставить больше 29 сек., потому что при 30сек. скрипт уже может умереть, это будет создавать очень большую нагрузку на сервер вплоть до падения MySQL, а также в это время посетители вашего сайта будут очень долго ждать отклика страницы, т.к. при сильной нагрузке на сервер сильно проседает его время отклика.

Интервал, сек. — интервал ожидания следующего запуска скрипта, т.е. если скрипт не успел создать бэкап при первом запуске, он подождет указанное время 5 сек. и опять запустится на 10 сек., и так пока не завершит создание резервной копии.

Если оптимизации выше еще не помогают, хостинг следует менять, но что поделать, не хочется менять и тратиться на переезд, есть еще возможность снизить нагрузку на сервер:

4.4. Пробуем еще Отключить компрессию архива.
Операция накладная, отключение сжатия позволяет снизить нагрузку на процессор, но при этом увеличивается размер архива и соответственно расходуем больше дискового пространства на сервере.

4.5. Ну и последней каплей будет отключение Проверить целостность архива после завершения
Если это не помогает, однозначно меняйте хостинг.

5. Заключение

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

Еще раз хочу подчеркнуть, кто не полностью прочитал статью, в последних версиях Битрикс 16 исключать из архива временные файлы и директории по маске не нужно, в нем это предусмотрено, т.е. даже вот так все будет в порядке

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

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

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

Материалы по теме

• Администратор. Базовый. Резервное копирование
• 1C-Битрикс: Управление сайтом. Резервное копирование

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

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

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

Перенос Битрикс на хостинг — создание резервной копии

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

Рабочий стол -> Настройки -> Инструменты -> Резервное копирование -> Создание резервной копии

Создать резервную копию можно двумя способами:

• Загрузить ее в облако «1С-Битрикс» (если активна лицензия Битрикс)
• Загрузить локально в каталог /bitrix/backup

После выбора способа нажимаем кнопку Создать резервную копию и ждем окончания процесса.

Перенос резервной копии Битрикс на новый хостинг

После успешного создания бекапа настала очередь перенести bitrix на новый хостинг. Самый быстрый способ — это воспользоваться скриптом переноса restore.php от команды 1С-Битрикс.

Скачать скрипт можно по адресу:

Данный скрипт необходимо загрузить в корневой каталог сайта, в нашем случае это будет:

Проще всего закачать restore.php через

Панель управления https://my.jehost.ru — WWW-домены — Каталог — Закачать

Выбираем тип файла URL файла на другом сервере и в поле вводим ссылку на скрипт http://www.1c-bitrix.ru/download/scripts/restore.php и нажимаем ОК.

В итоге файл restore.php окажется у Вас в корневом каталоге сайта и с его помощью можно начать процедуру переноса сайта Битрикс на хостинг.

Перенос Битрикс на хостинг — завершающий этап

Для этого в адресной строке браузера введите адрес http://сайт.ру/restore.php, а если Вы используете технический домен, то адрес будет вида http://логин.jhtest.ru/restore.php. После чего у Вас запустится скрипт восстановления сайта Битрикс из резервной копии.

Далее выбираете нужный способ восстановления и нажмите кнопку Далее.

Если резервная копия 1С-Битрикс создавалась с помощью облака, то далее Вам понадобится номер лицензии Битрикс и пароль на архив, который Вы вводили при создании бекапа.

Если бекап создавался локально, то нужно скопировать на него ссылку из меню Получить ссылку для переноса

Рабочий стол -> Настройки -> Инструменты -> Резервное копирование -> Список резервных копий

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

Панель управления https://my.jehost.ru — Базы данных — Создать

После ввода данные на подключение к базе нажмите Далее и дождитесь окончания установки. В итоге Вы восстановите сайт на хостинге. Если вместо сайта у Вас появится страница-заглушка, то просто удалите (или переименуйте) файл index.html в корне сайта.

Если Вы не хотите тратить время на перенос bitrix на хостинг, то напишите нам и мы сделаем бесплатный перенос сайта, а также все необходимые настройки, в т.ч. выполнение агентов на Cron.

Как перенести сайт на Битриксе на другой хостинг: 2 способа

Как перенести сайт на Битриксе на другой хостинг – один из популярных вопросов специалистам техподдержки и поиску Google.

Мы рассмотрим два способа «переезда» сайта на Битрикс и Битрикс24 с одного хостинга на другой. Их в равной степени можно применять и для миграций с виртуального хостинга на VPS или виртуальные машины, а также к переносу Битрикса с сервера на сервер.

Если вы являетесь клиентом Maxiplace или хотите протестировать наш хостинг, напишите в поддержку, и мы бесплатно поможем перенести ваш сайт на быстрые облачные сервера.

Первый способ. Перенос с помощью бэкапа Битрикс

Первый способ – это штатный вариант переноса, предусмотренный как в «1С-Битрикс: Управление сайтом», так и в коробочной версии «Битрикс24».

Алгоритм переноса простой: бэкап создается на исходном хостинге и с помощью специальной ссылки разворачивается на новом. При этом на новом хостинге в корневой директории веб-сервера должен быть залит скрипт восстановления restore.php.

Важно заранее выделить необходимое время для переноса. Сколько времени потребуется — зависит от конкретного проекта. Небольшие сайты в несколько гигабайт потребуют 10-20 минут, а перенос солидных площадок в сотни гигабайт может занять несколько часов.

Давайте рассмотрим перенос по шагам.

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

• Шаг 1 (необязательный). Перед переносом рекомендуется закрыть публичную часть сайта. Либо спланировать перенос на время низкого трафика – ночью или на выходных. Закрытие позволит снизить нагрузку на сайт, поскольку процедура создания бэкапа весьма ресурсоемкая, а сами резервные копии будут содержать все актуальные данные. Однако это необязательное условие. Если вам важна бесперебойная работа сайта, этот процесс можно сделать и без закрытия публичной части. Закрыть публичную часть можно в «Главном модуле»:

Шаг 2. Начинаем создавать резервную копию. Для этого необходимо следовать пути: Настройки -> Инструменты -> Резервное копирование -> Создание резервной копии.

• В облаке «1С-Битрикс»;
• В папке сайта;

• /bitrix/backup/ – очевидно, что бэкап переносить не нужно;
• /bitrix/cache/ – кэш создастся заново на новом хостинге, потому не нужно тратить время на его перенос;
• /bitrix/managed_cache/ – аналогично обычному кэшу.

1. Дамп БД и ее архивация создают большую нагрузку на сервер, сайт замедлит свою работу во время резервного копирования. Если сервер слабый, то возможны ошибки 502 и 504. В таких случаях нужно использовать другой способ переноса сайта.
2. Если сайт большого объема (сотни Гб), то использование встроенного резервного копирования – не лучшее решение для бэкапа. Особенно это актуально, если необходимо обеспечить минимальное время простоя.

Восстановление резервной копии на новом хостинге

• Шаг 1. Перед восстановлением резервной копии на другом хостинге или сервере мы рекомендуем протестировать их на соответствие с рекомендуемыми настройками для CMS Битрикс.

Сделать это можно с помощью скрипта bitrix_server_test.php (описание на сайте Битрикс ). Для этого скачайте его по ссылке , положите в корневую директорию сайта на новом хостинге и запустите в браузере http://ваш_домен_или_ip/bitrix_server_test.php.

В шаблоне Maxiplace для этого уже всё готово, и достаточно лишь перейти по адресу http://ваш_IP-адрес . После этого вы увидите стартовый экран, чтобы начать восстановление.

Второй способ. Перенос с помощью rsync и mysqldump

Перенос автоматическими средствами, что мы рассмотрели выше, – это алгоритм, на который почти невозможно повлиять. И если по каким-то причинам в ходе его работы не происходит создание или восстановление данных, то на помощь приходит второй способ.

Он подойдет тем, кто имеет доступ к shell-консоли и обладает навыками системного администрирования. Его также логично будет использовать при больших объемах сайтов, наличии множества мелких файлов, отсутствии места на сервере или медлительности исходного хостинга.

Перенос с помощью rsync и mysqldump характеризуется:

1. Большим контролем и гибкими возможностями для переноса. Синхронизация файлов происходит вручную, ошибки можно попутно замечать и исправлять.
2. Минимальным временем простоя сайта и возможностью досинхронизировать файлы. Нет ограничений и по таймингу, когда тайм-ауты веб-серверов ограничивают соединение или выполнение переноса временными рамками.
3. Снижением нагрузки на сервер. Когда Битрикс делает резервные копии, он формирует многотомный архив, в котором для больших сайтов может быть больше сотни томов. При ручном переносе создается один большой архив, который легче контролировать.

[root@server1 ~]# mysqldump -u имя_пользователя -p ИМЯ_БАЗЫ > ИМЯ_БАЗЫ.sql

И скопируем дамп через тот же rsync

[root@server1 ~]# rsync -avz ИМЯ_БАЗЫ.sql root@ip_сервера_получателя:/home/bitrix/

[root@server2 ~]# mysql -u имя_пользователя -p
mysql > create database ИМЯ_БАЗЫ;
mysql > exit;

И далее выполните ее импорт:

Как проверить систему после переноса

После восстановления следует перейти на сайт, зайти в панель администратора и выполнить проверку системы, чтобы убедится в корректности ее работы.
Необходимо следовать пути: Рабочий стол -> Настройки -> Инструменты -> Проверка системы.

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

Важный момент: если необходимо проверить работоспособность сайта на новом хостинге, не перенаправляя туда трафик, то возможны варианты мониторинга по IP-адресу, по техническому домену, если он есть на сайте, либо по основному домену на перенесенной странице через файл host (инструкция в Базе знаний Maxiplace).

Возможные проблемы и ошибки

Проблемы из-за версий php и mysql

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

Кроме того, нужно убедиться, что установлены все обновления Битрикс. Для этого надо сначала обновить php/mysql (даже на старом хостинге), а затем установить обновления Битрикс.

Проблемы с работой старых правил/редиректов .htaccess

После переноса файл .htaccess из резервной копии сохраняется под именем .htaccess.restore, а новый файл .htaccess содержит правила по умолчанию. Можно переименовать старый файл или перенести из него необходимые правила в новый.

Проблемы с отправкой почты с сервера

Для отправки почты в CMS Битрикс используется php функция mail(). Следует через phpinfo() проверить, что параметр sendmail_path указывает путь до sendmail или на его заменитель. Выявлению большинства проблем с отправкой писем помогает лог почтового сервера, по умолчанию это файл /var/log/maillog.

В шаблоне BitrixVM для отправки почты уже всё настроено, и останется лишь задать имя отправителя “from” в файле /home/bitrix/.msmtprc

Проблемы с авторизацией пользователя

Если пропадает авторизация пользователя, то можно проверить хостинг/сервер на корректность работы сессий с помощью скрипта bitrix_server_test.php по ссылке.

Проблемы с импортом базы данных

При возникновении сложностей с импортом базы данных объемом более 1 Гб, операцию следует проводить через консоль (инструкция есть в блоге MediaGuru).

Ошибки с появлением белого экрана

Бывают случаи, когда после переноса появляется белый экран, который сигнализирует об ошибках. Чтобы понять, чем конкретно это вызвано, следует в файле bitrix/php_interface/dbconn.php включить логирование ошибок:

‘exception_handling’ => array (
‘value’ => array (
‘debug’ => true,
‘handled_errors_types’ => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_USER_NOTICE,
‘exception_errors_types’ => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_USER_WARNING & ~E_USER_NOTICE & ~E_COMPILE_WARNING & ~E_DEPRECATED,
‘ignore_silence’ => false,
‘assertion_throws_exception’ => true,
‘assertion_error_type’ => 256,
‘log’ => array (
‘settings’ => array (
‘file’ => ‘bitrix/modules/error.log’, //Файл лога, куда и будут писаться наши ошибки
‘log_size’ => 1000000,
),
),
),
‘readonly’ => false,
),

Ошибки «Mysql connect error» и «DB query error. Please try later»

В первом случае следует проверить правильность доступов к БД в файле bitrix/php_interface/dbconn.php и bitrix/.settings.php, а для решения второй ошибки в файле bitrix/php_interface/dbconn.php выставить значение $DBDebug = true, чтобы увидеть детально возникшую ошибку.

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

Перенос силами поддержки Maxiplace

Как видите, перенести сайт на Битриксе на другой хостинг можно как штатными средствами, надеясь что автоматические процессы отработают корректно, или можно сделать это вручную, через команды rsync и mysqldump, которые требуют погружения в тему или квалифицированных специалистов.

Ну и важно помнить, что у вас всегда есть третий способ. Можно обратиться в поддержку Maxiplace, и для наших клиентов мы готовы осуществить перенос быстро, бесплатно и «под ключ».

Статья добавлена 1 год назад. Автор — Eltigro