Администрирование · 11 мин
Как изменить базу 1С с копии на рабочую
Как перевести копию базы 1С в рабочую: оценка изменений, проверка данных, загрузка в продуктивную базу, риски и контроль результата. Пошаговая инструкция для администратора.
Доработки в копии базы 1С завершены и протестированы — осталось перенести их в рабочую (продуктивную) базу, и именно на этом этапе чаще всего теряют данные: загружают конфигурацию из устаревшей копии, забывают про изменения, внесённые напрямую в рабочую базу, или запускают обновление конфигурации при активных сеансах пользователей. Перед переносом проверьте актуальность копии, сравните конфигурации через «Сравнить/объединить» и снимите резервную копию рабочей базы — это займёт минуты, но убережёт от часов восстановления.
Важно сразу различить два разных сценария. Первый — перенести в рабочую базу только изменения конфигурации (доработки, отчёты, обработки), сохранив все текущие данные пользователей. Второй — заменить рабочую базу целиком содержимым копии, что допустимо только если копия свежая и в рабочей базе с момента её снятия не вводились документы. Смешение этих сценариев — главный источник потерь данных.
Ниже разобраны оба пути: как определить, какой сценарий вам нужен, как подготовить базы, как выполнить перенос через конфигуратор и как проверить результат до того, как пользователи начнут работу.
Определите, какой сценарий переноса вам нужен
Прежде чем что-то загружать, ответьте на ключевой вопрос: что именно изменилось в копии и что происходило в рабочей базе за это время. Если в копии меняли только конфигурацию (модули, формы, макеты, роли), а пользователи в рабочей базе продолжали вводить документы — нужен перенос конфигурации, данные трогать нельзя.
Если копию сняли недавно, рабочая база фактически «заморожена» (например, переезд на новый сервер или восстановление после сбоя), и вся актуальная работа велась в копии — тогда возможна полная замена рабочей базы содержимым копии через выгрузку/загрузку .dt или развёртывание бэкапа СУБД.
Как выбрать действие
Подготовьте рабочую базу перед изменением
Первое и обязательное действие — резервная копия рабочей базы. Для файлового варианта достаточно выгрузки в .dt через конфигуратор (Администрирование → Выгрузить информационную базу) либо копирования файла 1Cv8.1CD при отсутствии активных сеансов. Для клиент-серверного варианта надёжнее сделать бэкап средствами СУБД (MS SQL, PostgreSQL), потому что выгрузка .dt большой базы занимает много времени и чувствительна к активности пользователей.
Второй шаг — завершить сеансы пользователей. В конфигураторе откройте Администрирование → Активные пользователи, предупредите сотрудников и дождитесь выхода. Для клиент-серверной базы удобно установить блокировку сеансов через консоль кластера или кодом, чтобы никто не вошёл во время обновления. Загрузка конфигурации при активных соединениях либо не выполнится, либо приведёт к ошибкам у пользователей.
Перенесите конфигурацию из копии в рабочую базу
Основной сценарий выглядит так. Откройте копию в конфигураторе и выгрузите конфигурацию в файл: Конфигурация → Сохранить конфигурацию в файл, получите файл с расширением .cf. Убедитесь, что конфигурация копии не находится на частичной поддержке с запретом изменений — иначе часть объектов может не выгрузиться корректно.
Затем откройте рабочую базу в конфигураторе монопольно и выполните Конфигурация → Загрузить конфигурацию из файла, указав сохранённый .cf. Платформа покажет окно сравнения — внимательно просмотрите список изменённых объектов. Если в рабочей базе были свои доработки, которых нет в копии, прямая загрузка их затрёт. В этом случае используйте Конфигурация → Сравнить, объединить с конфигурацией из файла и вручную отметьте, какие изменения брать.
После загрузки обновите конфигурацию базы данных (F7 или Конфигурация → Обновить конфигурацию базы данных). Если изменялась структура данных — добавлены реквизиты, изменены типы — платформа выполнит реструктуризацию. На больших базах это может занять продолжительное время, планируйте окно обновления заранее.
- 1Сделайте резервную копию рабочей базы (.dt или бэкап СУБД)
- 2Завершите сеансы пользователей и включите блокировку входа
- 3В копии: Конфигурация → Сохранить конфигурацию в файл (.cf)
- 4В рабочей базе: Конфигурация → Загрузить конфигурацию из файла
- 5Проверьте список изменений; при конфликтах используйте сравнение и объединение
- 6Обновите конфигурацию базы данных (F7), дождитесь реструктуризации
- 7Запустите базу в режиме предприятия и проверьте ключевые операции
- 8Снимите блокировку сеансов и сообщите пользователям
Замените рабочую базу копией целиком (если это оправдано)
Полная замена применяется, когда копия содержит актуальные данные, а старая рабочая база не нужна: восстановление после сбоя, перенос на новый сервер, откат после неудачного обновления. Для файлового варианта проще всего заменить файл 1Cv8.1CD в каталоге базы на файл из копии — при закрытых сеансах и после резервного копирования старого файла.
Универсальный способ — через .dt: в копии выполните Администрирование → Выгрузить информационную базу, затем в целевой базе (пустой или заменяемой) — Администрирование → Загрузить информационную базу. Для клиент-серверного варианта предпочтительнее восстановление бэкапа средствами СУБД: это быстрее и надёжнее для больших объёмов.
После замены проверьте привязки: путь к базе в списке информационных баз у пользователей, настройки публикации на веб-сервере, регистрацию в кластере 1С, подключённые внешние компоненты и каталоги обмена. Частая ситуация: база восстановлена, но пользователи продолжают подключаться к старому расположению.
Перенесите данные, если менялись и они
Если в копии заводили справочники, настройки или документы, которые должны попасть в рабочую базу, прямая загрузка конфигурации их не перенесёт — .cf содержит только метаданные. Для переноса данных используйте обработку «Выгрузка и загрузка данных XML» (входит в состав инструментов разработчика) или универсальный обмен через «Конвертацию данных».
Для типовых конфигураций часто удобнее встроенные механизмы синхронизации или обработки переноса, идущие с конфигурацией. Переносите данные точечно: только те объекты, которые действительно нужны, сверяя итоги по количеству записей и контрольным суммам (обороты по счетам, остатки по складам).
Проверьте результат до запуска пользователей
После обновления зайдите в рабочую базу в режиме предприятия под учётной записью с полными правами. Проверьте доработанный функционал: откройте изменённые формы, проведите тестовый документ, сформируйте отчёты, которые затрагивала доработка. Убедитесь, что версия конфигурации в сведениях о программе соответствует ожидаемой.
Отдельно проверьте регламентные и фоновые задания (для серверной базы), обмены с другими системами, права пользователей на новые объекты — при добавлении новых ролей или объектов доступы могут потребовать настройки. Только после успешной проверки снимайте блокировку сеансов.
Как проверить результат
Совпадает с версией копии
Старая версия — обновление не применилось
Открываются, доработки видны и работают
Ошибки открытия, старое поведение
Документы и остатки на месте, итоги сходятся
Пропали документы — возможна загрузка .dt вместо .cf
Выполняются без ошибок
Ошибки в журнале регистрации после обновления
Типичные ошибки и как их избежать
Самая разрушительная ошибка — загрузить .dt из копии в рабочую базу, когда требовалось перенести только конфигурацию. Все данные, введённые с момента снятия копии, исчезают. Вторая по частоте — загрузка .cf без сравнения: затираются доработки, сделанные прямо в рабочей базе другим разработчиком.
Также типичны: обновление без бэкапа («база маленькая, успею»), реструктуризация при активных сеансах, забытая блокировка входа (пользователь заходит в середине обновления и получает ошибки), а также отсутствие проверки после обновления — проблемы всплывают уже при реальной работе.
Держите простой регламент: любые доработки — только в копии, перенос в рабочую базу — по чек-листу в нерабочее время. Если доработки делает несколько человек, используйте хранилище конфигурации: это снимает большинство конфликтов при объединении изменений и показывает, кто и что менял.
Частые вопросы
Можно ли перенести изменения из копии, не останавливая работу пользователей?
Динамическое обновление возможно только для ограниченного набора изменений, не затрагивающих структуру данных, и даже оно требует перезапуска сеансов. На практике безопаснее планировать короткое окно обновления с завершением сеансов — особенно при изменении реквизитов и таблиц.
Чем отличается загрузка .cf от загрузки .dt?
Файл .cf содержит только конфигурацию (метаданные, код, формы) и не трогает данные. Файл .dt — полный снимок базы: конфигурация плюс все данные. Загрузка .dt полностью замещает содержимое базы, поэтому для переноса доработок используется только .cf.
Что делать, если доработки были и в копии, и в рабочей базе?
Используйте режим «Сравнить, объединить с конфигурацией из файла» вместо прямой загрузки. В окне объединения отметьте, какие изменения брать из файла, а какие оставить из текущей конфигурации. Для модулей доступно построчное сравнение текста.
Переносятся ли расширения конфигурации файлом .cf?
Нет. Расширения хранятся отдельно от основной конфигурации. Их нужно выгрузить из копии в файл .cfe (Конфигурация → Расширения конфигурации) и загрузить в рабочую базу через тот же список расширений, после чего проверить совместимость и применимость.
Как откатиться, если после обновления что-то сломалось?
Если есть резервная копия — восстановите базу из неё: для файлового варианта верните прежний 1Cv8.1CD или загрузите .dt, для серверного — восстановите бэкап СУБД. Если менялась только конфигурация без структуры данных, иногда достаточно загрузить обратно ранее выгруженный .cf рабочей базы.
Нужно ли обновлять копию после переноса в рабочую базу?
Да, иначе копия быстро устареет и следующий перенос превратится в рискованное объединение. После успешного обновления рабочей базы снимите с неё свежую копию и используйте её как новую тестовую среду для дальнейших доработок.
Что важно запомнить
Доработки переносятся файлом .cf, а не .dt; перед любым изменением рабочей базы делается резервная копия и завершаются сеансы; при конфликтах изменений используется сравнение и объединение; результат проверяется до запуска пользователей. Полная замена базы копией допустима только при отсутствии новых данных в рабочей базе.