Как поменять сервер 1С и перенести базы без потерь

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

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

Ниже разобран полный цикл: подготовка, перенос файловых и клиент-серверных баз, лицензии, типовые ошибки и проверка результата. Инструкция подходит для платформ 8.3, различия между релизами указаны там, где они критичны.

Определите текущую архитектуру перед переносом

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

При клиент-серверном режиме дополнительно выясните, где стоит СУБД: на той же машине, что и сервер 1С, или отдельно. От этого зависит, переносите ли вы одну службу или две. Также проверьте, какие компоненты работают рядом: веб-сервер для публикации баз, сервер хранилища конфигураций, сервер взаимодействия, службы интеграции (обмены, планировщики заданий, COM-коннекторы).

Зафиксируйте версии: релиз платформы (например, 8.3.22.x), версию и разрядность СУБД, версию операционной системы. Новый сервер должен поддерживать те же или более новые версии — даунгрейд платформы после обновления базы невозможен без восстановления из копии.

Подготовьте новый сервер

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

Если используется СУБД, установите её заранее: MS SQL Server, PostgreSQL (сборку, рекомендованную для 1С) или другую поддерживаемую. Важны детали: разрядность, collation (порядок сортировки) для MS SQL должен совпадать, для PostgreSQL — корректная локаль. Расхождение collation — частая причина того, что база «не поднимается» после переноса.

Настройте сеть: статический IP или DNS-имя нового сервера, открытые порты агента сервера 1С (по умолчанию 1540, 1541, диапазон 1560–1591), доступ к СУБД. Убедитесь, что учётная запись службы агента сервера 1С имеет права на каталоги и доступ к СУБД.

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

Файловая база переносится двумя способами. Самый надёжный — выгрузка в dt: запустите конфигуратор на старом сервере, выполните «Администрирование → Выгрузить информационную базу», перенесите файл на новый сервер и загрузите через «Загрузить информационную базу». Этот способ заодно выполняет внутреннюю проверку целостности.

Второй способ — простое копирование каталога с файлом 1Cv8.1CD при остановленной работе пользователей. Он быстрее на больших базах, но не выявляет скрытых повреждений. После копирования обязательно запустите утилиту chdbfl.exe из каталога платформы или «Тестирование и исправление» в конфигураторе.

Учтите: если база больше 4–5 ГБ и активно растёт, файловый режим — повод заодно рассмотреть переход на клиент-серверный вариант, а не переносить проблему на новое железо.

Перенесите клиент-серверные базы

Для клиент-серверных баз переносится база данных СУБД, а не файлы платформы. Порядок такой: завершите работу пользователей, заблокируйте регламентные задания в консоли кластера, сделайте полный backup средствами СУБД (для MS SQL — Full backup в .bak, для PostgreSQL — pg_dump или pg_basebackup).

На новом сервере восстановите backup в СУБД (restore для MS SQL, pg_restore/psql для PostgreSQL). Затем в консоли администрирования сервера 1С создайте новую информационную базу: укажите имя, сервер СУБД, имя базы данных и поставьте флаг «Создать базу данных в случае её отсутствия» — снятым, если база уже восстановлена. Платформа подключится к существующей базе.

Дополнительно перенесите то, что живёт вне базы: настройки кластера (список рабочих серверов, требования назначения функциональности), публикации на веб-сервере (файлы default.vrd и настройки IIS/Apache), внешние компоненты и отчёты, лежащие в каталогах, а также планировщики обменов, если они запускались скриптами на старом сервере.

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

Разберитесь с лицензиями

Лицензии 1С бывают программные и аппаратные (USB-ключи HASP). Аппаратный ключ достаточно физически переставить в новый сервер и установить драйвер HASP — лицензия поднимется автоматически. Это самый безболезненный вариант.

Программная лицензия привязывается к параметрам оборудования, поэтому при переезде на новый сервер она станет недействительной. Если при активации был выбран вариант с резервными пин-кодами, активируйте новый пин-код на новом сервере через «Получение лицензии» в конфигураторе или сервисе лицензирования. Если пин-коды исчерпаны, потребуется восстановление лицензии через центр лицензирования 1С — на это нужно время, планируйте заранее.

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

Переключите пользователей и проверьте работу

Когда базы подняты на новом сервере, обновите список информационных баз у пользователей. Варианты: раздать новый файл списка баз (ibases.v8i), опубликовать список на веб-сервере и указать пользователям ссылку, либо — если новый сервер получил то же сетевое имя, что и старый — пользователи вообще ничего не заметят. Последний вариант удобнее всего: переименуйте старый сервер, присвойте его имя новому.

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

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

Контрольные точки

Как проверить результат

Вход пользователей

Норма

Все роли заходят без ошибок лицензий

Тревожный признак

Ошибка 'не найдена лицензия' или 'база не обнаружена'

Регламентные задания

Норма

Задания выполняются по расписанию на новом сервере

Тревожный признак

Задания висят или выполняются на старом сервере

Скорость работы

Норма

Отчёты и проведение не медленнее, чем раньше

Тревожный признак

Заметные тормоза — проверяйте диски и настройки СУБД

Обмены и интеграции

Норма

Синхронизации проходят, файлы уходят и приходят

Тревожный признак

Ошибки COM, недоступные пути, старые IP в настройках

Типичные ошибки при переезде

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

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

Частые вопросы

Можно ли перенести 1С на новый сервер без остановки работы?

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

Нужно ли заново покупать лицензии при смене сервера?

Нет. Аппаратный ключ просто переставляется. Программная лицензия переактивируется резервным пин-кодом; если резервных пин-кодов нет, лицензию восстанавливают через центр лицензирования бесплатно, но это занимает время.

Что лучше для переноса файловой базы: копирование или выгрузка в dt?

Выгрузка в dt надёжнее: она проверяет целостность и создаёт чистую базу. Копирование файла быстрее и подходит для больших баз, но после него обязательно запустите проверку chdbfl или тестирование в конфигураторе.

Можно ли заодно обновить версию платформы при переезде?

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

Пользователи подключаются по RDP к серверу 1С. Что меняется?

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