Экспорт и импорт данных в Битрикс: чек-лист перед продакшеном

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

Сначала определите, что именно переносится

Слово «данные» в Битрикс скрывает несколько разных объектов. Выгрузка инфоблоков не заменяет перенос базы, а копия базы без каталога /upload не восстановит изображения товаров.

• Контент: инфоблоки, разделы, элементы, свойства, торговые предложения.
• Файлы: изображения, документы, пользовательские поля и содержимое /upload.
• Операционные данные: пользователи, заказы, статусы оплат и доставок, накопленные скидки.
• Конфигурация: модули, сайты, почтовые шаблоны, агенты, обработчики событий, настройки SEO и интеграций.
• Служебные данные: кеш, поисковый индекс, очереди, временные файлы и журналы.

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

Безопасная миграция — это не «выгрузить базу и залить её на новый сервер», а воспроизводимая проверка: что перенесли, что изменилось и как откатиться.

Сравните способы переноса

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

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

Чек-лист до экспорта

1. Зафиксируйте версии. Запишите версию продукта, PHP, MySQL или MariaDB, веб-сервера и установленных модулей. Целевая среда должна поддерживать ту же версию или совместимый сценарий обновления. Проверка: у команды есть один документ с версиями исходного и целевого серверов.
2. Составьте карту данных. Перечислите сайты, инфоблоки, каталоги, пользователей, заказы, файлы, интеграции и планируемые исключения. Проверка: для каждого объекта понятно, переносится он целиком, выборочно или создаётся заново.
3. Сделайте резервную копию. Сохраните копию базы и файлов отдельно от исходного сервера. Если используется встроенное резервное копирование Битрикс, проверьте, что архив завершился без ошибки и его размер не выглядит подозрительно маленьким. Проверка: архив можно скачать и открыть на тестовой машине.
4. Проверьте свободное место. Для распаковки понадобится место под архив, исходные файлы и временные операции с базой. Проверка: на целевом сервере есть запас, а не только размер, равный объёму сайта.
5. Зафиксируйте активность. Определите момент, после которого на исходном сайте запрещаются изменения. Иначе новые заказы, пользователи и файлы не попадут в экспорт. Проверка: назначены ответственный и время финальной выгрузки.
6. Подготовьте секреты отдельно. API-ключи, пароли к базе, доступы к платёжным системам и SMTP не должны попадать в общий файл с инструкцией. Проверка: после миграции вы знаете, какие ключи нужно заменить или отозвать.

Что проверить сразу после импорта

База и структура сайта

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

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

Файлы, ссылки и изображения

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

Сделайте выборку из старых URL и проверьте ответы сервера. Отдельно откройте файлы с кириллицей, длинными именами и несколькими размерами изображений. Если сайт использует CDN или объектное хранилище, проверьте не только локальный путь, но и публичный URL.

Кеш, поиск и фоновые операции

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

Проверьте агентов и фоновые задания. Убедитесь, что на тестовой копии не запускаются реальные письма, платежи, обмен с 1С, службы доставки и уведомления клиентам. Если задача запускается через cron, сначала отключите боевой endpoint и используйте тестовый режим интеграции.

Что ломается чаще всего

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

Где подход ломается

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

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

Особое внимание уделите боевой базе. Если во время переноса продолжают оформляться заказы, финальная копия уже устаревает. Надёжнее включить короткий режим обслуживания, выполнить финальный экспорт, проверить контрольные записи и только затем переключить DNS или прокси.

Финальная проверка перед переключением

• резервная копия восстановлена на тестовой среде;
• админка, каталог, корзина и оформление заказа работают;
• проверены изображения, документы, старые URL и редиректы;
• поиск, кеш, агенты и cron настроены для новой среды;
• боевые интеграции включаются только после тестового заказа;
• есть план отката: старая среда, DNS или прокси, срок хранения резервной копии;
• после переключения назначен человек, который следит за логами, заказами и ошибками 404.

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