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

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

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

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

Подготовка: что проверить перед переносом

Начните с инвентаризации. Откройте свойства информационной базы в списке баз 1С и зафиксируйте: режим работы (файловый или клиент-серверный), версию платформы, версию конфигурации, путь к базе или имя базы данных на SQL-сервере. Эти данные понадобятся для точного воспроизведения окружения на новом сервере.

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

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

Резервная копия — обязательный первый шаг

До любых действий сделайте полную резервную копию и проверьте, что она восстанавливается. Для файловой базы выполните выгрузку в файл .dt через конфигуратор («Администрирование» → «Выгрузить информационную базу») и дополнительно скопируйте сам файл 1Cv8.1CD при остановленной работе пользователей.

Для клиент-серверной базы сделайте полный backup средствами СУБД. Выгрузка .dt для больших баз (десятки и сотни гигабайт) занимает часы и создаёт сильную нагрузку, поэтому основным средством переноса служит именно backup/restore на уровне СУБД, а .dt остаётся дополнительной страховкой.

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

Файловый вариант — самый простой сценарий. На новом сервере установите платформу 1С той же версии (или новее, если планируете обновление), создайте папку под базу и настройте общий сетевой доступ к ней с правами на чтение и запись для всех пользователей.

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

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

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

На новом сервере разверните СУБД той же или совместимой версии, установите сервер 1С:Предприятия той же версии платформы, что и на старом. Если сервер 1С и СУБД размещаются на разных машинах, проверьте сетевую связность и права учётных записей служб.

Перенос базы данных выполняется штатными средствами СУБД: на старом сервере создаётся полная резервная копия, файл backup переносится на новый сервер и восстанавливается. Для MS SQL это команды BACKUP DATABASE и RESTORE DATABASE или соответствующие действия в Management Studio. После восстановления проверьте сопоставление пользователей базы данных и логинов сервера — при переносе на другой экземпляр SQL эта связь часто теряется.

BACKUP DATABASE [MyBase] TO DISK = N'D:\Backup\MyBase.bak' WITH COPY_ONLY;

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

Перенос через выгрузку .dt

Альтернатива — выгрузить базу в .dt на старом сервере и загрузить на новом через конфигуратор. Этот путь проще и не требует доступа к СУБД, но подходит только для небольших баз: на объёмах от нескольких десятков гигабайт процесс становится многочасовым и чувствительным к обрывам. Дополнительный плюс .dt — возможность сменить тип СУБД или даже перейти между клиент-серверным и файловым режимом.

Перенос лицензий и ключей защиты

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

Программные лицензии привязаны к аппаратным параметрам сервера, поэтому при переезде потребуется новая активация. Заранее найдите пин-коды из комплекта поставки: обычно доступны основной и резервные пин-коды. Если резервные исчерпаны, запрашивается новый комплект через центр лицензирования — этот процесс занимает время, поэтому решите вопрос с лицензиями до дня переезда, а не после.

Настройка после переноса

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

Отдельно проверьте регламентные и фоновые задания: в копии базы они могут быть заблокированы (это штатное поведение при загрузке копии, чтобы задания не выполнялись дважды). Разблокируйте их осознанно и только на рабочей базе нового сервера, предварительно отключив на старом.

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

Типичные ошибки и ограничения

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

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

Когда старый сервер можно выводить из эксплуатации

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

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

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