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

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

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

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

Начните с инвентаризации текущей конфигурации. Зафиксируйте: версию платформы 1С, версию и редакцию SQL Server, имя базы данных, имя информационной базы в кластере, учётную запись, под которой сервер 1С обращается к SQL, и список активных пользователей. Эти данные понадобятся при регистрации базы на новом месте, и их отсутствие — частая причина затягивания работ.

Проверьте совместимость версий. Восстановить резервную копию можно только на SQL Server той же версии или новее — обратное направление невозможно. Если новый сервер имеет более старую версию SQL, прямой перенос через backup/restore не сработает, и потребуется выгрузка через dt-файл конфигуратора. Также убедитесь, что версия платформы 1С на новом сервере приложений совпадает с той, под которой работала база, или новее.

Оцените объём базы и окно простоя. Полный backup и restore базы размером в десятки гигабайт занимает ощутимое время, а в период переноса пользователи не должны работать. Запланируйте перенос на нерабочие часы и заранее уведомите сотрудников.

Завершение работы пользователей и блокировка базы

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

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

Отдельно проверьте фоновые процессы за пределами 1С: плановые задания обмена, интеграционные службы, системы резервного копирования, которые могут обращаться к базе SQL напрямую. Их тоже следует приостановить на время переноса.

Создание резервной копии на старом сервере

Основной способ переноса — штатный механизм backup/restore SQL Server. Подключитесь к старому экземпляру через SQL Server Management Studio, найдите нужную базу в обозревателе объектов, щёлкните правой кнопкой и выберите «Задачи» → «Создать резервную копию». Тип копии — «Полная», назначение — файл на диске. Укажите путь, доступный для последующего копирования на новый сервер.

Ту же операцию можно выполнить командой T-SQL, что удобно для документирования процедуры:

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backup\MyBase1C_full.bak' WITH FORMAT, COMPRESSION, CHECKSUM;

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

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

Восстановление базы на новом SQL-сервере

На новом сервере откройте Management Studio, подключитесь к целевому экземпляру, щёлкните правой кнопкой по узлу «Базы данных» и выберите «Восстановить базу данных». В качестве источника укажите «Устройство» и путь к скопированному bak-файлу. Введите имя базы — рекомендуется сохранить прежнее, чтобы не путаться при регистрации в кластере.

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

После восстановления создайте учётную запись, под которой сервер 1С будет обращаться к базе. Обычно используется либо доменная учётная запись службы агента сервера 1С (проверка подлинности Windows), либо отдельный логин SQL. Этой учётной записи нужна роль владельца базы (db_owner) на восстановленной базе. Проверьте также сопоставление логина и пользователя базы: при переносе между серверами связь часто теряется, и логин остаётся «сиротой» — в этом случае проще удалить пользователя из базы и добавить логин заново с нужной ролью.

1. 1
   Завершите сеансы и включите блокировку базы в консоли кластера 1С
2. 2
   Создайте полную резервную копию базы на старом SQL Server
3. 3
   Скопируйте bak-файл на новый сервер
4. 4
   Восстановите базу в Management Studio с корректными путями к файлам
5. 5
   Создайте логин и назначьте роль db_owner на восстановленной базе
6. 6
   Перерегистрируйте информационную базу в кластере 1С на новый SQL-сервер
7. 7
   Проверьте вход в базу и снимите блокировку сеансов

Подключение базы в кластере 1С

Сценарий 1: кластер 1С остаётся прежним

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

Сценарий 2: переезжает и сервер 1С

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

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

Альтернатива: перенос через выгрузку в dt-файл

Выгрузка информационной базы в файл .dt через конфигуратор («Администрирование» → «Выгрузить информационную базу») — универсальный метод, не зависящий от версий и типа СУБД. Он незаменим при понижении версии SQL Server, смене СУБД или когда нет прямого доступа к файловой системе серверов.

У метода есть серьёзные ограничения. Выгрузка и загрузка dt выполняются значительно медленнее, чем backup/restore, — для больших баз это часы. Кроме того, dt-файл не переносит настройки на уровне SQL: права, индексы, созданные вручную, параметры базы данных. Для типовой базы среднего размера это приемлемый путь, для крупной производственной системы — запасной вариант.

Проверка результата и запуск в работу

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

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

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

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