Как перенести сайт 1С-Битрикс на новый хостинг: пошаговое руководство

Перенос сайта на 1С-Битрикс на новый хостинг — задача с двумя рисками: потерять файлы/БД и поймать простой из‑за DNS. Ниже рабочий сценарий «дамп → файлы → новый сервер → .settings.php → проверка по hosts → DNS», без лишней теории и с типичными граблями BitrixVM / обычного VPS.

Что именно переносим

• Код и ядро: публичка + /bitrix/ + /local/
• База MySQL/MariaDB
• Загрузки: /upload/ (часто самый тяжёлый кусок)
• Конфиг окружения: /bitrix/.settings.php, при необходимости .settings_extra.php, crontab, nginx/apache vhost

Кеш (bitrix/cache, bitrix/managed_cache, bitrix/stack_cache) на новый сервер не тащим — он пересоздастся. Если используете Redis/Memcached для кеша или сессий — учтите отдельно: на новом хосте другие DSN.

Подготовка (за сутки)

1. Снизьте TTL A-записи до 300 секунд (если DNS позволяет).
2. Проверьте место на новом диске: размер /upload + БД + запас 20–30%.
3. Согласуйте версии PHP и MySQL (не ниже, чем на проде; лучше совпадение major).
4. Включите maintenance / закройте запись в админке на время финального синка, если допустим короткий read-only.

Шаг 1. Дамп базы

mysqldump -u USER -p --single-transaction --quick --routines --triggers DB_NAME \
  | gzip > /tmp/bitrix-db.sql.gz

--single-transaction важен для InnoDB: консистентный снимок без длинной глобальной блокировки. Для очень больших БД смотрите лимиты max_allowed_packet на приёмной стороне (иначе импорт оборвётся на длинных BLOB).

Шаг 2. Архив файлов

cd /var/www/site
tar -czf /tmp/bitrix-files.tar.gz \
  --exclude='bitrix/cache/*' \
  --exclude='bitrix/managed_cache/*' \
  --exclude='bitrix/stack_cache/*' \
  --exclude='bitrix/html_pages/*' \
  --exclude='upload/tmp/*' \
  .

Альтернатива для первого прогона и последующего догона — rsync напрямую на новый сервер (меньше возни с одним гигантским tar):

rsync -az --info=progress2 \
  --exclude 'bitrix/cache/' \
  --exclude 'bitrix/managed_cache/' \
  --exclude 'bitrix/stack_cache/' \
  /var/www/site/ user@new-server:/var/www/site/

Шаг 3. Передача и развёртывание

# со старого
scp /tmp/bitrix-db.sql.gz /tmp/bitrix-files.tar.gz user@new-server:/tmp/

# на новом
mkdir -p /var/www/site
tar -xzf /tmp/bitrix-files.tar.gz -C /var/www/site
zcat /tmp/bitrix-db.sql.gz | mysql -u NEW_USER -p NEW_DB

Права после распаковки: владелец — пользователь PHP-FPM/Apache (часто bitrix, www-data, nginx). Типовой быстрый вариант на BitrixVM — утилиты из документации Битрикс по восстановлению прав; не оставляйте 777 «на всякий случай».

Шаг 4. .settings.php и окружение

В /bitrix/.settings.php обновите как минимум:

• блок connections → host, database, login, password;
• при переносе сессий/кеша — DSN Redis;
• exception_handling → путь к логу на новом ФС;
• если был HTTPS terminator / прокси — соответствующие заголовки и https в настройках сайта.

В админке (после входа) проверьте Настройки → Сайты: домен, URL, HTTPS. Старый домен в абсолютных ссылках в контенте ищите точечно (не массовым sed по ядру).

Шаг 5. Очистка кеша и проверка по /etc/hosts

rm -rf /var/www/site/bitrix/cache/* \
       /var/www/site/bitrix/managed_cache/* \
       /var/www/site/bitrix/stack_cache/*

На своей машине пропишите в hosts IP нового сервера и старый домен. Откройте сайт и админку, проверьте авторизацию, карточку товара/элемент инфоблока, заказ, почтовое событие, cron/агенты. Только после этого трогайте DNS.

Шаг 6. DNS с минимальным downtime

1. Финальный короткий rsync/дамп (догнать дельту upload и БД), сайт на старом — в read-only если возможно.
2. Импорт дельты на новый.
3. Переключение A-записи на новый IP.
4. Старый сервер не выключайте сразу: держите 24–72 часа на случай отката и «залипших» клиентов с старым DNS-кешем.

Типичные грабли

• Сессии в БД/Redis — после смены DSN всех «вылогинит»; это нормально.
• Агенты и crontab — на новом хосте должны быть свои задания; дубли на старом и новом дадут гонки.
• Лицензия / привязка к железу — при смене сервера иногда нужна реактивация; держите доступ к кабинету Битрикс.
• HTTPS редиректы и mixed content — проверьте протокол сайта и абсолютные URL в контенте.
• Права на /upload — картинки 404 при неверном владельце каталогов.
• Очереди почты / Б24-коннекторы — внешние webhook URL могут указывать на старый IP, пока DNS не разошёлся.

Короткий чеклист

1. Дамп с --single-transaction + архив/rsync без кеша.
2. Импорт БД, права на файлы, правки .settings.php.
3. Проверка по hosts, очистка кеша.
4. Финальный догон → DNS → наблюдение 1–3 дня.

Вывод

Успешный перенос Битрикс — это не «скопировать папку», а согласованная смена файлов, БД и окружения с проверкой до DNS. Кеш не переносите, .settings.php и crontab проверяйте руками, дельту догоняйте rsync’ом, старый сервер оставляйте страховочным буфером на пару суток.