Мой способ переноса сайта на другой хостинг в 1С-Битрикс — без потерь и за 10 минут

Когда нужно переносить сайт

Проект на 1С-Битрикс может годами работать на одном хостинге — пока не начнёт тормозить, падать или конфликтовать с новыми версиями PHP и MySQL. В какой-то момент разработчику или владельцу приходится решать: продолжать мучиться или перевести проект на более стабильную платформу. Но перенос — это не всегда про «срочно и в панике». Ниже — конкретные сценарии, когда переезд действительно оправдан, и к чему он приводит с технической стороны.

Ситуация	Признаки	Чем грозит, если не перенести
Устаревший или медленный хостинг	Сайт открывается дольше 3 секунд, падает при нагрузке, MySQL тормозит, PHP 7.0–7.3 или ниже	Снижение позиций, потери конверсии, невозможность обновить Битрикс и модули
Разработка на локальном сервере	Сайт готов, но работает только на OpenServer или Denwer	Невозможно показать заказчику, нет доступа из интернета, нет SSL
Смена подрядчика или владельца	Новые FTP-доступы, новый домен, смена юрлица	Старая команда может ограничить доступ, возможны конфликты при оплате
Ошибки из-за версии PHP или базы	Ошибка 500, parse error, сбои при авторизации или оплате	Пользователи не могут работать, техподдержка бессильна без обновления окружения
Непрозрачные лимиты на хостинге	Скрытые ограничения на inode, процессы, размер БД	Резкое падение сайта без объяснений, трудно отладить и найти причину

Смена хостинга

Это самый частый сценарий, с которым ко мне приходят заказчики: сайт работает, но стало слишком тесно. Что-то не обновляется, иногда сайт падает, поддержка отвечает скриптами, а скорость загрузки — как в 2009 году. Типичная ситуация: дешёвый shared-хостинг, на котором сайт "прожил" пару лет, но вырос из него.

Если Bitrix начал регулярно:

• выдавать ошибки 500 без очевидной причины;
• глючить при сохранении инфоблоков;
• сбрасывать корзину или заказы в магазине;
• зависать при импорте из 1С или выгрузке прайс-листов —

— это почти всегда не ошибка самого Битрикса, а реакция на устаревшую или перегруженную инфраструктуру.

Решение — не пытаться чинить всё на месте, а грамотно перевести проект туда, где можно нормально работать: с быстрыми дисками, свежими версиями ПО и поддержкой, которая не отправляет в "базу знаний".

Переезд с локального сервера на боевой

Один из самых недооценённых этапов в разработке — финальный перенос с OpenServer, Denwer, MAMP или Docker-сборки на реальный хостинг. Вроде бы всё готово: сайт работает, Битрикс настроен, инфоблоки заведены — осталось “выложить”. Но если просто «залить» файлы и базу как попало, можно получить сюрпризы: белый экран, битые пути, ошибки подключения и сломанные модули.

На локалке может быть:

• другая версия PHP (например, 8.2 вместо 7.4);
• MySQL без InnoDB или с нестандартными collation;
• другой формат путей и прав доступа (особенно на Windows);
• жёстко забитые пути в .settings.php, .access.php и других служебных файлах.

Я рекомендую переносить через restore.php даже такие проекты — чтобы сразу отследить проблемы с доступами, путями и шрифтами (на локалке часто стоят кириллические TTF, которых нет на проде). Плюс, restore автоматически разворачивает структуру и корректно подключает базу.

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

Переезд с нестабильного или медленного хостинга

Это история, с которой сталкивался каждый Bitrix-разработчик: сайт сам по себе «неплохой», шаблон адаптивный, SEO на месте, но страница грузится 6–9 секунд, и Google ругается на медленный TTFB. Вы обновили Битрикс, кеш сброшен, картинки сжаты — а толку ноль. Проблема — в хостинге.

Обычно такие хостеры:

• размещают 300 сайтов на одном сервере без изоляции ресурсов;
• не дают настроить OPcache, кеширование на уровне nginx или php-fpm;
• используют HDD вместо SSD или облачные медленные диски;
• ограничивают CPU и RAM, не предупреждая об этом в тарифах.

На нормальном хостинге первая отрисовка страницы (TTFB) не должна превышать 300–400 мс даже без композита.

Как это можно проверить:

• Зайдите в PageSpeed Insights и посмотрите на показатель «Время до первого байта (TTFB)»;
• Откройте DevTools в Chrome → вкладка Network → фильтр document → столбец Waiting (TTFB);
• Если сайт откровенно тормозит в админке — это тоже симптом, особенно на разделах с инфоблоками, формами или каталогами.

Смена домена или юридического лица

Если меняется собственник проекта, юрлицо или название компании, чаще всего приходится переносить сайт на новые реквизиты: новый домен, новые доступы, отдельный хостинг. И здесь важно не просто “скопировать сайт”, а юридически и технически отсечь всё, что может быть связано с предыдущим владельцем.

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

Правильная стратегия — выносить проект на свой хостинг с полными правами администратора, доступом к DNS, базе и корню сайта. Это даёт контроль и снижает юридические риски.

Переезд при смене юрлица также часто требует смены доменного имени. В таком случае важно настроить 301-редирект, обновить все счётчики, sitemap и проиндексированные страницы в поиске. Это отдельная задача, но она решаема, если перенос сделан грамотно.

Критерии выбора хостинга

Bitrix — требовательная CMS. Она не простит дешёвого шареда с устаревшей версией PHP, слабой MySQL и криво настроенным кешем. Если вы переносите сайт, важно сразу выбрать хостинг, который подходит именно под Bitrix, а не “для Wordpress или визиток”.

Вот основные параметры, на которые стоит ориентироваться при выборе:

Критерий	Рекомендуется	Почему важно
Версия PHP	8.0, 8.1 или 8.2	Битрикс перестал поддерживать PHP ниже 8.0, модули и обновления не работают
MySQL / MariaDB	MySQL 5.7+ или MariaDB 10.5+	Старые версии не поддерживают InnoDB и могут вызывать ошибки при миграции
Поддержка InnoDB	Обязательно	С 2024 года Битрикс полностью перешёл на InnoDB — без него сайт не восстановится
OPcache	Включен	Повышает скорость работы в 2–3 раза, снижает нагрузку на сервер
Диски	SSD или NVMe	Сильно влияет на TTFB, особенно на страницах с кешом и базой
Права доступа и владельцы	Настраиваются вручную	Нельзя работать, если всё принадлежит www-data без доступа через FTP/SSH
Автоматические бэкапы	Есть и можно скачать вручную	Позволяет быстро восстановить сайт без restore, если что-то пошло не так

Также желательно, чтобы хостер:

• предоставлял Bitrix-окружение или BitrixEnv из коробки;
• поддерживал cron-задачи и почту с авторизацией SMTP;
• давал SSH-доступ и php.ini или .user.ini настраиваемый вручную;
• имел реальную техподдержку, а не автоответы по шаблону.

Как работает перенос через restore.php - теория

Что это за файл и зачем он нужен

restore.php — это специальный PHP-скрипт, разработанный командой 1С-Битрикс для безопасного и корректного восстановления сайта из резервной копии. Он входит в комплект стандартной системы резервного копирования Bitrix и создаётся автоматически при экспорте бэкапа через административную панель.

Скрипт полностью автоматизирует:

• распаковку zip-архива с резервной копией сайта;
• восстановление структуры файлов и прав;
• развёртывание базы данных MySQL;
• настройку конфигураций под новое окружение (логины, пароли, пути, кодировку);
• проверку и адаптацию окружения под Bitrix (например, нужные модули PHP, версии и права).

Официальная инструкция от Bitrix: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&LESSON_ID=2014

Когда restore.php — лучшее решение

Этот способ не просто «один из», а рекомендованный и проверенный лично мной в десятках проектов. Он идеально подходит в большинстве реальных сценариев, особенно когда:

• нужно быстро перенести рабочий сайт без потери структуры, данных и модулей;
• нет желания или возможности вручную ковыряться в phpMyAdmin, править bitrix/.settings.php или пережимать дамп базы;
• вы не уверены, какие именно модули и настройки должны быть на новом сервере — restore сам адаптирует окружение;
• сайт сложный: используется 1С-обмен, CRM-модуль, сложный каталог, множество форм или кастомный функционал.

Примеры, где restore выручал лично:

• Перенос каталога на 40 000 товаров с полной интеграцией с 1С — восстановился за 7 минут;
• Сайт после заражения вирусом был очищен локально и развёрнут с нуля на новом сервере — без единой ошибки;
• Перевод с shared-хостинга на VPS — restore сохранил все симлинки, крон и кастомные папки;
• Передача проекта между разработчиками — архив + restore исключили любую путаницу с правами и зависимостями.

Важно понимать: restore.php — это не просто загрузка файлов, а развёртывание всего проекта как единого механизма. Поэтому для быстрого, чистого и надёжного переноса — это мой инструмент №1.

Какие ограничения у restore.php

Несмотря на удобство и универсальность, restore.php — это не магическая кнопка “сделать хорошо”. У него есть технические ограничения, которые нужно учитывать перед переносом. Вот ключевые подводные камни:

Ограничение	Что это значит	К чему приводит
Требуется архив в нужном формате	Файл должен быть создан через встроенное резервное копирование в Bitrix	Сторонние архивы (.zip вручную) не распознаются, восстановление не начнётся
Размер архива ограничен настройками PHP	upload_max_filesize, post_max_size и max_execution_time должны быть достаточно высокими	Большой архив (>500 МБ) может не загрузиться или “падать” при распаковке
Требуется пустой корень сайта	В папке, где запускается restore.php, не должно быть установленного Bitrix	Иначе может возникнуть конфликт с существующими конфигурациями и файлами
Нельзя восстанавливать частично	Нет выбора «только база» или «только файлы» — всегда полный разворот	Если нужно восстановить только часть — придётся вручную разбирать архив
Не работает без PHP-модуля zlib	Некоторые хостинги отключают zlib — restore откажется распаковывать	Будет ошибка «Failed to open stream», восстановление не начнётся

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

Подготовка к переносу

Чтобы перенос прошёл без сюрпризов, важно сначала всё правильно подготовить: создать рабочий бэкап, получить нужные файлы и проверить хостинг, куда вы будете переносить сайт. Ниже — пошагово.

Создаём полный резервный бэкап

Заходим в административную панель сайта:

1. Панель администратора → Настройки → Инструменты → Резервное копирование → Создание резервной копии.
2. Нажимаем «в папке сайта».
3. Снимаем чекбокс с «Включить экспертные настройки создания резервной копии».

После завершения процесса у вас появится архив с именем вроде:

Создание резервной копии завершено

Имя архива:           domain.ru_20250709_143052_full_qz7w2rbi88ch7ilb.tar.gz
Размер архива:        737.02 МБ
Размещение:           локально
Файлов в архиве:      70649
Размер данных:        1.27 ГБ
Время создания:       2 мин.

Скачиваем архив и файл restore.php

После создания резервной копии нужно скачать два файла:

• сам архив (.gz);
• файл restore.php.

Затем зайдите в раздел «Список резервных копий». Именно там вы можете скачать как архив с бэкапом, так и файл restore.php. Оба файла нужны для переноса — без них восстановление не запустится.

/bitrix/backup/

Оба файла нужно будет затем загрузить в корень нового сайта — именно от них будет происходить восстановление.

Проверяем настройки PHP и MySQL на новом хостинге

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

Параметр	Рекомендуемое значение
PHP	8.0, 8.1 или 8.2
MySQL / MariaDB	MySQL 5.7+ или MariaDB 10.5+
InnoDB	Обязательно включен (по умолчанию в новых версиях)
upload_max_filesize	больше размера архива (обычно 512M или 1G)
post_max_size	больше размера архива
max_execution_time	не менее 300 секунд
zlib	включён

<?php
phpinfo();

Пошаговый перенос сайта на новый хостинг

Когда архив и restore.php готовы, а окружение нового хостинга соответствует требованиям — можно переходить к переносу. Этот процесс занимает от 5 до 15 минут и не требует командной строки или ручной работы с базой. Ниже — пошагово, что делать.

1. Загружаем архив и restore.php на новый хостинг

Подключитесь к новому хостингу через FTP, SFTP или файловый менеджер в панели управления. Загрузите в корень сайта файлы:

• архив резервной копии (например, domain.ru_20250709_143052_full_qz7w2rbi88ch7ilb.tar.gz (частей: 14));
• файл restore.php (скачанный заранее или из архива).

Файлы должны быть размещены в той же директории, откуда будет запускаться восстановление (обычно это корень домена — /public_html, /www или /htdocs).

ftp> cd /www/
ftp> put site_backup_full_2024_07_09.tar.gz
ftp> put restore.php

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

2. Запускаем restore.php и следуем инструкции

Когда все файлы загружены, пора запускать процесс восстановления. Откройте в браузере ссылку:

https://ваш-домен.ru/restore.php

Перед вами откроется фирменный мастер восстановления Bitrix. На первом шаге он проверит:

• доступность архива и всех его частей (.tar.gz, .tar.gz.1, .tar.gz.2 и т.д.);
• доступ к PHP-функциям (распаковка, работа с файлами, работа с БД);
• наличие необходимых модулей: zlib, mysqli, mbstring и др.

Если всё ок — скрипт предложит продолжить. Далее вы попадёте на пошаговый интерфейс:

1. Выбор архива. Restore автоматически определит имя файла — просто подтвердите.
2. Проверка прав доступа. Скрипт проверит, можно ли записывать файлы в директорию.
3. Настройки БД. Вводятся на следующем шаге (раскроем дальше).
4. Распаковка и установка. Сайт развернётся полностью: файлы, база, конфиги, скрипты, .htaccess.

Во время восстановления не закрывайте вкладку и не перезагружайте страницу — скрипт работает в один поток. Обычно процесс занимает от 1 до 10 минут, в зависимости от размера архива и скорости хостинга.

3. Настраиваем подключение к базе данных

На этом шаге restore.php предложит указать параметры для подключения к новой базе данных. Эти данные нужно получить заранее в панели хостинга или задать вручную (если хостинг это позволяет).

В форме вводим:

• Сервер баз данных: чаще всего localhost (если не указано иное в настройках хостинга);
• Имя пользователя: логин от базы данных;
• Пароль: пароль от БД;
• Имя базы данных: заранее созданная БД или новая (если стоит галочка «Создать базу данных, если не существует»).

После ввода всех данных нажмите «Восстановить» и дождитесь окончания развёртывания базы.

4. Проверяем восстановление и доступность сайта

После завершения восстановления restore.php выведет сообщение об успешной установке. На этом этапе:

• Файлы сайта уже развернуты в корне;
• База данных восстановлена;
• Настройки окружения адаптированы под новый хостинг.

Теперь можно открыть сайт в браузере и убедиться, что всё работает: главная страница, разделы, авторизация, форма обратной связи, админка (/bitrix/admin/).

На последнем шаге нажмите кнопку:

УДАЛИТЬ ЛОКАЛЬНУЮ РЕЗЕРВНУЮ КОПИЮ И СЛУЖЕБНЫЕ СКРИПТЫ

Это удалит временные файлы и restore.php, чтобы никто не мог повторно запустить восстановление.

Что сделать после переноса

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

Проверяем корректность сайта нестандартными методами

Не стоит полагаться только на визуальную проверку — многие ошибки (битые ссылки, дубли, редиректы, заголовки 500 и 404) могут быть незаметны снаружи, но повлияют на SEO и поведение пользователей.

Для быстрой технической диагностики я использую Screaming Frog SEO Spider. Это настольный сканер, который за 1–2 минуты показывает:

• битые ссылки (404);
• временные или лишние редиректы (301 → 301 → 200);
• заголовки с кодами ошибок (403, 500);
• неработающие канонические ссылки и hreflang;
• отсутствующие мета-заголовки, описания, заголовки h1;
• и многое другое.

Также можно использовать онлайн-сервисы:

Проверяем стандартными средствами

Затем проверьте сайт через привычные для Bitrix-интегратора инструменты. Это позволяет сразу выявить критические сбои: отсутствие шаблона, сбитый кеш, неработающую авторизацию или формы заявок.

Что проверяю первым делом:

• Открывается ли главная страница и внутренние разделы;
• Корректно ли подключаются стили и скрипты (template_styles.css, template.js);
• Открываются ли страницы по пунктам меню;
• Загружается ли админка: /bitrix/admin/, и проходит ли авторизация;
• Отправляется ли форма обратной связи или добавляются товары в корзину (если это интернет-магазин);
• Правильно ли отображаются изображения — особенно если использовался resize или watermark.

Если проект использует кастомные компоненты или нестандартные шаблоны — откройте «Настройки» → Инструменты → «Журнал событий» и проверьте наличие ошибок уровня PHP notice или fatal error.

Проверяем ЧПУ и кеш

После переноса важно проверить, что человекопонятные URL (ЧПУ) работают корректно.

Откройте несколько внутренних страниц. Если вместо привычных адресов вроде /uslugi/ отображаются /index.php?ID=3, значит ЧПУ не работают — нужно повторно прописать пути в настройках инфоблока.

Далее очищаю кеш через административную панель: «Настройки» → «Настройки продукта» → «Автокеширование». Выбираю «Все» и запускаю очистку:

Если нет доступа в админку, можно удалить кеш вручную по FTP:

/bitrix/cache/
/bitrix/managed_cache/
/upload/resize_cache/

Делаем проверку конфигурации Bitrix

Ещё один обязательный шаг после переноса — запустить встроенную проверку системы. Это поможет выявить скрытые проблемы: несовпадения версий PHP, неправильные параметры сервера, сбои с кодировками или отсутствующие модули.

Перейдите в Настройки → Инструменты → Проверка системы и нажмите кнопку «Начать тестирование». Bitrix сам проведёт диагностику и покажет, на что стоит обратить внимание.

Обновляем robots.txt

После переноса сайта на новый хостинг важно перепроверить файл robots.txt. Иногда в нём остаются старые правила, запрещающие индексацию нужных разделов или ссылающиеся на другой домен (например, dev-сервер или staging-копию).

Файл robots.txt должен находиться в корне сайта и содержать актуальные правила для поисковых роботов. Пример базового файла для 1С-Битрикс:

User-agent: *
User-Agent: *
Disallow: */index.php
Disallow: /bitrix/
Disallow: /*show_include_exec_time=
Disallow: /*show_page_exec_time=
Disallow: /*show_sql_stat=
Disallow: /*bitrix_include_areas=
Disallow: /*clear_cache=
Disallow: /*clear_cache_session=
Disallow: /*ADD_TO_COMPARE_LIST
Disallow: /*ORDER_BY
Disallow: /*PAGEN
Disallow: /*?print=
Disallow: /*&print=
Disallow: /*print_course=
Disallow: /*?action=
Disallow: /*&action=
Disallow: /*register=
Disallow: /*forgot_password=
Disallow: /*change_password=
Disallow: /*login=
Disallow: /*logout=
Disallow: /*auth=
Disallow: /*backurl=
Disallow: /*back_url=
Disallow: /*BACKURL=
Disallow: /*BACK_URL=
Disallow: /*back_url_admin=
Disallow: /*?utm_source=
Disallow: /*?bxajaxid=
Disallow: /*&bxajaxid=
Disallow: /*?view_result=
Disallow: /*&view_result=
Allow: /bitrix/components/
Allow: /bitrix/cache/
Allow: /bitrix/js/
Allow: /bitrix/templates/
Allow: /bitrix/panel/

Host: https://example.ru
Sitemap: https://example.ru/sitemap.xml

Проверьте, чтобы Host и Sitemap указывали на боевой домен. Если сайт переехал с test.example.ru на example.ru — нужно обязательно заменить значения.

Обновляем sitemap.xml

После переноса сайта важно проверить и при необходимости пересоздать sitemap.xml — особенно если структура URL изменилась или добавились новые страницы.

Если вы используете стандартный модуль «Поисковая оптимизация» в 1С-Битрикс, зайдите в него и пересоздайте карту сайта вручную:

1. Откройте Маркетинг → Поисковая оптимизация → Настройка sitemap.xml;
2. Нажмите «Изменить» у нужного sitemap;
3. Запустите пересоздание карты.

Если карта генерируется сторонним модулем или скриптом — запустите его повторно. Убедитесь, что в sitemap попадают только релевантные страницы (не должно быть дублей, 404 или технических разделов).

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

После переноса стоит запустить встроенный тест производительности в админке 1С-Битрикс. Он покажет, насколько хорошо работает сайт на новом хостинге — по скорости процессора, файловой системы, работы с базой данных и общему времени отклика.

Чтобы протестировать:

1. Перейдите в Настройки → Производительность → Панель производительности;
2. Выберите интервал тестирования (например, 1 минута);
3. Нажмите кнопку «Тестировать производительность».

Идеальное значение — «Битрикс (оптимально)». Если производительность ниже, стоит проверить загрузку сервера, кеш и работу баз данных.

Обновляем Яндекс.Метрику и счётчики

Если на сайте использовалась Яндекс.Метрика, Google Analytics или другие системы аналитики — убедитесь, что счётчики по-прежнему корректно подключены. После переноса пути могут поменяться, а скрипты — слететь из-за ошибок шаблона или кеша.

Что проверяю:

• Есть ли счётчик Метрики в исходном коде страниц (через «Просмотреть код»);
• Загружается ли он без ошибок (через вкладку «Сеть» в DevTools);
• Передаёт ли данные в реальном времени — откройте Метрику и зайдите на сайт, вы должны появиться в разделе «Посетители онлайн»;
• Если ID счётчика вшит через настройки шаблона (например, в header.php), убедитесь, что шаблон подтянулся правильно.

Проверяем cron-задачи (если были)

Если сайт до переноса использовал регулярные задачи (например, выгрузка из 1С, обновление остатков, отправка e-mail отчётов) — нужно убедиться, что cron на новом хостинге работает и задачи выполняются по расписанию.

Что нужно проверить:

• Открывается ли файл /bitrix/crm/configs/cron/ или /bitrix/php_interface/cron_tasks/ — убедитесь, что скрипты не пропали при переносе;
• Есть ли нужные строки в планировщике задач (crontab -l или через панель хостинга);
• Работает ли задание — можно вручную запустить его через SSH или браузер (если есть доступ);
• Нет ли ошибок в логах cron или в логе /bitrix/modules/main/crontab/.

* * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/backup.php

Обновляем системные настройки

После переноса сайта важно вручную проверить основные настройки в административной панели. Часто при смене хостинга или домена автоматически ничего не обновляется — и сайт может использовать старые пути, устаревшие email-адреса или нерабочие сервисы.

Что нужно перепроверить:

• Почта сайта: Настройки → Настройки продукта → Почтовые и СМС события → Почтовые шаблоны. Убедитесь, что указаны актуальные данные. Проверьте также email по умолчанию.
• Основной домен: Настройки → Настройки продукта → Настройки модулей → Главный модуль. В разделе сайта Системные настройки, указан актуальный домен, путь и email администратора.
• Кэш: если сайт ведёт себя нестабильно, проверьте параметры управляемого кеша и автокеширования — они могли быть изменены при переносе. Настройки → Настройки продукта → Автокеширование
• Интеграции: если сайт подключён к CRM, внешним API или сервисам доставки — проверьте токены, ключи и вебхуки.
• Оптимизация CSS: Настройки → Настройки продукта → Настройки модулей. Отмечаем все чекбоксы и проверяем работу на сайта.

Ошибки при восстановлении и как их избежать

В процессе восстановления сайта через restore.php могут возникнуть ошибки — от повреждённого архива до проблем с базой данных или правами доступа. Ниже собрал самые частые случаи и кратко описал, как их диагностировать и решать.

Ошибка	Описание	Что делать
Архив не загружается	Файл .gz не отображается в списке или не открывается	Проверьте размер (лимит на хостинге) и имя файла. Перезалейте вручную по FTP.
Зависает restore.php	Скрипт останавливается на этапе распаковки или не завершает восстановление	Проверьте лог, увеличьте max_execution_time и memory_limit в php.ini
Ошибка подключения к БД	restore не может создать или подключиться к базе	Проверьте имя БД, пользователя, пароль и хост. Убедитесь, что база создана.
Ошибки прав	Файлы не открываются, нет доступа, сломаны стили	Установите права 755 для папок и 644 для файлов. Проверьте владельца через FTP.
Сайт восстанавливается, но не работает	Открывается, но сломан функционал, корзина, формы, admin	Проверьте логи ошибок, журнал событий, включите отображение ошибок в Bitrix.

Архив не загружается или повреждён

Иногда после загрузки архива на хостинг restore.php просто не видит его — файл не отображается в интерфейсе или возникает ошибка при попытке распаковать.

Частые причины:

• архив весит больше лимита, установленного в php.ini (например, 512 МБ);
• файл загружен не в ту директорию (нужна та же папка, где лежит restore.php);
• файл переименован или загружен в кодировке Windows-1251 с недопустимыми символами в имени;
• архив повреждён при скачивании с локального сервера или не до конца загрузился по FTP.

restore.php зависает на распаковке

Иногда при запуске restore.php процесс распаковки зависает — не продвигается прогрессбар, и страница «висит». Это распространённая проблема, особенно на дешёвых хостингах с жёсткими лимитами на ресурсы.

Причины залипания могут быть следующие:

• ограничено время выполнения скрипта (например, max_execution_time = 30 секунд);
• ограничен объём оперативной памяти memory_limit — часто нужен минимум 256 МБ, лучше — 512 МБ;
• хостинг не поддерживает распаковку tar.gz-архивов через PHP или не позволяет использовать exec() и shell_exec();
• архив повреждён или имеет сложную структуру (много файлов, вложенные папки);
• файловая система хостинга работает медленно (например, если это сетевое хранилище).

Также можно попробовать альтернативный способ — создать файл phpinfo() и проверить ограничения:

<?php
phpinfo();

Ошибка подключения к БД

На этапе подключения к базе restore.php может выдать сообщение: «Невозможно подключиться к базе данных». Это критическая ошибка — без успешного соединения сайт не восстановится.

Вот что чаще всего вызывает проблему:

• неправильно указаны имя БД, логин или пароль (чувствительны к регистру);
• вместо localhost нужно указать другой хост (например, 127.0.0.1 или адрес сервера MySQL, указанный в панели хостинга);
• база данных не создана или пользователь не имеет к ней доступа;
• символы в пароле (например, %, &, #) вызывают ошибку парсинга формы (редко, но бывает);
• на сервере работает старый MySQL (например, 5.1), не поддерживающий нужный формат БД из архива.

Проверка подключения заранее помогает избежать проблем: создайте обычный тестовый скрипт mysqli_connect() и убедитесь, что всё работает до запуска restore.

<?php
$link = mysqli_connect("localhost", "user", "password", "dbname");
if (!$link) {
    die('Ошибка подключения: ' . mysqli_connect_error());
}
echo 'Успешно!';

Проблемы с правами на файлы и папки

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

Что может пойти не так:

• файлы распакованы с правами 600 или 644, но серверу нужен доступ 644/755 (в зависимости от конфигурации);
• папки с кэшом или upload имеют права, не позволяющие записи (upload/, bitrix/cache/);
• владелец файлов отличается от пользователя веб-сервера (особенно после распаковки через FTP от root'а);
• файлы .htaccess или php запрещают доступ к нужным директориям (проверьте логи);
• возникают ошибки 403 на картинках или CSS-файлах — часто это следствие неправильных прав.

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Если доступа по SSH нет — используйте файловый менеджер в панели хостинга или выставляйте права через FTP-клиент (например, FileZilla).

Сайт восстановился, но работает некорректно

Бывает, что восстановление прошло без ошибок, сайт открылся — но явно "что-то не так": нарушены стили, не работает часть функционала, возникают непредсказуемые баги.

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

• битые пути в шаблонах — $templateFolder может ссылаться на несуществующие ресурсы (если структура была нестандартной);
• не все .htaccess были восстановлены (например, в /upload/ или /bitrix/);
• файлы с кириллицей или спецсимволами в имени могли повредиться при переносе (особенно если архив создавался на Windows);
• часть настроек не применились — проверьте Настройки → Инструменты → Журнал событий на предмет hidden-ошибок;
• отвалились сторонние сервисы (почта, CRM, платёжки) из-за смены домена, путей или настроек подключения.

Чеклист переноса сайта на другой хостинг

Чтобы ничего не упустить, я собрал для себя (и теперь — для вас) полный чеклист. Он помогает перенести любой сайт на 1С-Битрикс быстро, без потерь и с минимальными рисками.

Шаг	Что делаю
1. Резервная копия	Создаю полный бэкап через административный раздел.
2. Загрузка	Скачиваю архив и restore.php, загружаю их на новый хостинг.
3. Проверка среды	Через phpinfo() или bitrix_server_test.php проверяю версию PHP, MySQL, лимиты.
4. Восстановление	Запускаю restore.php, распаковываю и подключаю к базе данных.
5. Финальная проверка	Проверяю работу сайта: ЧПУ, кеш, формы, админку, авторизацию.
6. Техаудит	Прогоняю сайт через Screaming Frog на ошибки и битые ссылки.
7. Финальная настройка	Обновляю robots.txt, sitemap.xml, Метрику, крон, счётчики и системные опции.

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

Личный опыт из практики

Однажды после переноса сайт просто не открывался — белый экран. Ни ошибок, ни логов. Проверил restore.php, базу, права, пути — всё чисто. Причина оказалась подлой- в начале файла header.php стоял невидимый символ.

Этот символ вставился перед <?php и мешал работе require. Визуально его не видно, но сайт уже начал вывод — а значит, Bitrix не может управлять заголовками. Обычные редакторы его не показывают, спас HEX-редактор.

// ВНИМАНИЕ: вот этот символ ниже — BOM (Byte Order Mark), он невидим, но ломает сайт
// &_#65279;
<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
$APPLICATION->SetTitle("Главная страница");

Вот этот символ  — это BOM (Byte Order Mark), байты EF BB BF в начале файла. Он часто появляется, если сохраняли файл в Windows или через онлайн-редактор с кодировкой «UTF-8 с BOM».

Решается просто: откройте файл в Notepad++ или Sublime Text, включите отображение скрытых символов и удалите всё до <?php. Или перекодируйте в «UTF-8 без BOM».

Ответы на популярные вопросы

Можно ли переносить сайт Bitrix с истекшей лицензией?

Да, перенос возможен. Лицензия не влияет на работу restore.php или восстановление сайта. Но после переноса некоторые модули (например, обновления) могут не работать без активной подписки.

Что делать, если после переноса появляются ошибки 403 или 500?

Ошибка 403 обычно связана с правами доступа на файлы и папки — проверьте CHMOD и владельцев. Ошибка 500 — это внутренняя ошибка сервера: включите отображение ошибок в PHP, проверьте логи и параметры окружения. Часто проблема в .htaccess или устаревшем модуле.

Как быть, если архив сайта повреждён или не открывается?

Попробуйте открыть архив локально с помощью 7-Zip или WinRAR. Если не получается — попробуйте восстановить из предыдущей копии. На будущее рекомендую всегда проверять архив после создания и делать 2 копии: основную и резервную.

Можно ли распаковать архив вручную и подключить базу?

Да, это допустимо. Распакуйте архив в корень сайта, импортируйте дамп базы через phpMyAdmin, укажите настройки подключения в bitrix/.settings.php или dbconn.php — в зависимости от версии Bitrix. Но restore.php всё же удобнее и безопаснее.

Нужно ли менять dbconn.php после переноса?

Если вы используете старую структуру подключения (до Bitrix D7), то да — в /bitrix/php_interface/dbconn.php нужно прописать новые параметры подключения к базе. Если используется .settings.php, настройки можно обновить прямо через restore.php.

После переноса перестали работать ссылки — что делать?

Проверьте, включено ли ЧПУ и не повреждён ли файл .htaccess. Также убедитесь, что модуль «Инфоблоки» активен, и для каждого типа контента настроены шаблоны URL. Часто проблема возникает при переносе с Windows-хостинга на Linux из-за регистра символов в путях.

Нужно ли переносить крон-задачи вручную?

Да. Bitrix не переносит задания cron автоматически — их нужно вручную прописать на новом хостинге. Проверьте, какие команды запускались по расписанию на старом сервере, и настройте аналогично через crontab -e или планировщик в панели хостинга.

Полезные ссылки и файлы

Заключение

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

Я помогаю переносить проекты на новый хостинг надёжно и без потерь: от подготовки архива до финальной проверки и настройки окружения. Если не хотите терять данные, позиции и нервы — обращайтесь.