Перенос базы 1С на другой компьютер или сервер без сюрпризов

Технически перенос — две команды. Проблемы начинаются вокруг них: интеграции, лицензии, публикации и то, что происходит при первом запуске копии.

Файловая база на другой компьютер

Вариант первый, штатный:

1. Все вышли из базы. Конфигуратор → «Администрирование → Выгрузить информационную базу», получаем .dt.
2. На новом компьютере ставим платформу той же версии или новее. Более старая платформа файл не откроет.
3. Создаём пустую базу «без конфигурации», открываем конфигуратор, «Администрирование → Загрузить информационную базу».

Вариант второй, быстрый: скопировать каталог базы целиком при закрытой базе. Работает, но копия работающей базы почти всегда битая — файл держится открытым.

Практическое правило: .dt — для переноса и для смены варианта работы, копия каталога — для быстрого клонирования на месте.

Из файловой в клиент-серверную

1. Выгрузить .dt из файловой базы.
2. В консоли администрирования кластера создать информационную базу: указать сервер СУБД, имя базы данных и обязательно поставить «Создать базу данных в случае её отсутствия».
3. Подключиться конфигуратором к новой пустой базе и загрузить .dt.
4. Проверить, что сервер 1С и сервер СУБД видят друг друга, а служба 1С работает под учётной записью, у которой есть права на каталог лицензий.

Сразу после загрузки, до того как пустить пользователей:

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

Строки соединения различаются так:

rem файловая база
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" ENTERPRISE /F"D:\bases\unf"

rem клиент-серверная база
"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" ENTERPRISE /S"srv-1c\unf"

Первый запуск копии: главный подводный камень

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

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

Правило простое: тестовую копию всегда помечайте копией и разворачивайте с отключёнными обменами.

Что перенести кроме базы

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

После переноса проверить

1. Очистить кэш клиента на рабочих станциях (%LocalAppData%\1C\1cv8), иначе возможны странные ошибки форм.
2. Обновить ярлыки и списки баз у пользователей: путь или строка соединения изменились.
3. Провести контрольный документ, построить отчёт, выполнить закрытие месяца на копии.
4. Проверить регламентные задания: включены, расписание не сбилось, ошибок в журнале нет.
5. Включить обмены и убедиться, что первый сеанс прошёл без конфликтов.
6. Сделать свежую резервную копию уже на новом месте — старая относится к другому окружению.

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