Как перенести базу 1С на другой сервер

Перенос базы 1С на другой сервер — типовая задача при замене оборудования, переезде в виртуальную среду или разделении ролей сервера 1С и СУБД. Способ переноса зависит от режима работы базы: файловая база копируется как обычный каталог, а клиент-серверная требует либо выгрузки в файл .dt, либо переноса средствами самой СУБД (MS SQL, PostgreSQL). Выбор неправильного метода — главная причина потери данных и простоя, поэтому сначала определите конфигурацию, а затем действуйте по схеме.

Перед любыми действиями зафиксируйте исходное состояние: версию платформы 1С (например, 8.3.22), версию и релиз конфигурации, режим работы, расположение базы и настройки публикации. Убедитесь, что на новом сервере установлена платформа той же версии или новее — обратный перенос базы, открытой более свежей платформой, на старую невозможен без танцев с конвертацией.

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

Определите тип базы и выберите способ переноса

Откройте список информационных баз в окне запуска 1С и посмотрите строку подключения. Если путь выглядит как каталог на диске или сетевом ресурсе (например, \\server\bases\trade) — база файловая. Если указаны сервер кластера и имя базы — клиент-серверная. От этого зависит весь дальнейший сценарий.

Файловый режим переносится проще всего, но имеет ограничения по числу одновременных пользователей и размеру. Клиент-серверный режим даёт два варианта: универсальный перенос через выгрузку .dt (подходит при смене типа СУБД или версии) и нативный перенос средствами СУБД (быстрее на больших базах, но требует одинаковой СУБД на обоих серверах).

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

Перед переносом сделайте полноценную резервную копию, даже если планируете штатную выгрузку. Для файловой базы — скопируйте каталог целиком. Для клиент-серверной — создайте бэкап средствами СУБД (например, Full Backup в SQL Server Management Studio) и дополнительно выгрузку .dt. Две независимые копии страхуют от повреждения одного из носителей.

Завершите все сеансы: в консоли кластера серверов 1С откройте ветку «Сеансы» и удалите их, либо установите блокировку регламентных заданий и подключений через «Администрирование — Обслуживание — Блокировка установки соединений». Отключите регламентные и фоновые задания — они могут стартовать во время переноса и изменить данные.

Проверьте свободное место на новом сервере: для выгрузки .dt понадобится объём, сопоставимый с размером базы, а сама база после загрузки может занять больше исходной из-за индексов и журналов СУБД. Запас в 1,5–2 размера базы — разумный минимум.

Перенос файловой базы

Файловая база — это каталог, в котором главный файл называется 1Cv8.1CD. Завершив все сеансы, скопируйте весь каталог на новый сервер любым способом: проводником, robocopy или архиватором. Копирование средствами robocopy предпочтительнее для больших баз — утилита корректно обрабатывает длинные пути и умеет докопировать при обрыве связи.

robocopy "D:\bases\trade" "\\newserver\bases\trade" /E /COPY:DAT /R:2 /W:5 /LOG:C:\logs\move_trade.log

После копирования на клиентских машинах добавьте базу в список запуска с новым путём или отредактируйте существующую запись. Если база публиковалась на веб-сервере, потребуется перенастроить публикацию (файл default.vrd) на новом сервере. Старый каталог не удаляйте сразу — оставьте его в режиме «только чтение» как страховку минимум на несколько дней.

Перенос клиент-серверной базы через выгрузку .dt

Откройте конфигуратор от имени администратора и выполните «Администрирование — Выгрузить информационную базу». Укажите путь к файлу .dt на диске с достаточным местом. Выгрузка большой базы может занять часы — планируйте её на нерабочее время и не прерывайте процесс.

На новом сервере установите платформу 1С той же или более новой версии, при необходимости — сервер 1С и СУБД. Создайте через консоль кластера новую пустую информационную базу (при создании выберите нужный тип СУБД и укажите параметры подключения), затем откройте её конфигуратором и выполните «Администрирование — Загрузить информационную базу», указав файл .dt.

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

1. 1
   Завершить сеансы и заблокировать регламентные задания на старом сервере
2. 2
   Выгрузить базу в .dt через конфигуратор
3. 3
   Проверить размер и целостность файла выгрузки
4. 4
   Установить платформу и СУБД на новом сервере
5. 5
   Создать пустую базу в кластере нового сервера
6. 6
   Загрузить .dt в новую базу и перезапустить конфигуратор
7. 7
   Проверить пользователей, права и регламентные задания
8. 8
   Переключить клиентские подключения на новый сервер

Перенос средствами СУБД: быстрый путь для больших баз

Когда база велика (десятки гигабайт и больше) и СУБД на обоих серверах одинаковые, перенос через .dt неоправданно долгий. Эффективнее сделать резервную копию средствами СУБД и восстановить её на новом сервере. Для MS SQL это операции Backup/Restore в Management Studio, для PostgreSQL — утилиты pg_dump/pg_restore или физическое копирование кластера.

Порядок для MS SQL: создайте полную резервную копию базы, скопируйте файл .bak на новый сервер, восстановите базу под тем же именем. Затем в консоли кластера 1С на новом сервере создайте информационную базу, указав существующую базу данных СУБД, — платформа подключится к ней без загрузки данных. Убедитесь, что учётная запись, от имени которой сервер 1С обращается к СУБД, имеет права на восстановленную базу.

Ограничения метода: версия СУБД на новом сервере должна быть не ниже исходной (восстановление бэкапа со старшей версии на младшую невозможно), а смена типа СУБД этим способом невозможна в принципе. Для миграции, например, с MS SQL на PostgreSQL используйте только выгрузку .dt.

Настройка после переноса и проверка результата

После переноса пройдитесь по критичным настройкам: строки подключения в списках баз пользователей, параметры публикации на веб-сервере, настройки обменов (РИБ, обмен с сайтом, ЭДО), пути к внешним печатным формам и файловым томам хранения присоединённых файлов. Если в конфигурации где-то жёстко прописан старый путь или имя сервера — обмены молча перестанут работать.

Проверьте целостность данных: откройте базу в режиме предприятия, сформируйте оборотно-сальдовую ведомость и сверьте итоги с копией на старом сервере, сделанной до отключения пользователей. Совпадение сальдо по счетам — надёжный признак корректного переноса. Дополнительно для файловой базы можно запустить утилиту chdbfl.exe из каталога платформы для проверки физической целостности файла.

Типичные ошибки и как их избежать

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

Третья группа ошибок связана с версиями: попытка загрузить .dt в платформу старше той, на которой делалась выгрузка, или восстановить бэкап SQL на более раннюю версию СУБД. Проверяйте совместимость заранее и обновляйте целевой сервер до нужного уровня до начала переноса, а не в процессе.

Частые вопросы о переносе базы 1С