Можно ли обновлять рабочую базу 1С путем загрузки конфигурации, подготовленной на копии?

При обслуживании сильно доработанных, нетиповых конфигураций процесс обновления может занимать часы или даже дни. Возникает логичный вопрос: можно ли развернуть резервную копию рабочей базы, спокойно обновить и протестировать конфигурацию на ней, а затем просто перенести полученный файл конфигурации (.cf) в рабочую базу через меню «Конфигурация — Загрузить конфигурацию из файла»? Разберем эту методику детально, проанализируем технические нюансы платформы 1С:Предприятие 8, возможные риски и правила безопасного обновления.

Суть методики и почему ее применяют

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

1. Создаем резервную копию рабочей базы данных (предпочтительно средствами СУБД, например SQL-бэкап).
2. Разворачиваем копию на тестовом сервере.
3. Выполняем обновление конфигурации на копии: объединяем изменения, адаптируем доработки, выполняем отладку и всестороннее тестирование.
4. Выгружаем готовую результирующую конфигурацию в файл .cf.
5. В нерабочее время монопольно подключаемся к боевой базе и загружаем подготовленный файл через команду «Конфигурация — Загрузить конфигурацию из файла» с последующим обновлением конфигурации базы данных (клавиша F7).

Такой подход действительно широко применяется и существенно сокращает технологическое окно простоя рабочей базы, однако требует строгого соблюдения ряда технических правил.

Внутренние механизмы: UUID объектов и риск потери данных

Выясним причину, по которой некоторые специалисты категорически предостерегают от использования команды «Загрузить конфигурацию из файла». Дело заключается в механизме идентификации метаданных платформой 1С.

Платформа сопоставляет объекты метаданных (справочники, документы, реквизиты, табличные части) с реальными таблицами и полями в базе данных СУБД не по строковым именам (синонимам или идентификаторам), а по внутренним уникальным идентификаторам — UUID.

Проанализируем опасную ситуацию:

1. Разработчик при обновлении на копии удалил реквизит или объект метаданных, а затем создал его заново с точно таким же именем. В этом случае имя осталось прежним, но сгенерировался совершенно новый внутренний UUID.
2. Параллельно в боевой базе продолжали работать пользователи, и в исходном объекте накапливались данные.
3. При выполнении операции «Загрузить конфигурацию из файла» платформа полностью заменяет структуру метаданных. Увидев несовпадение UUID, система посчитает, что старый объект был удален, а новый — создан.
4. При обновлении конфигурации базы данных (реструктуризации) таблица или колонка со старыми данными будет безвозвратно удалена на уровне СУБД.

Главное правило контроля: при нажатии F7 в окне «Реорганизация информации» всегда внимательно проверяем список планируемых изменений. Если в списке присутствуют непредусмотренные операции удаления реквизитов или таблиц, принимать изменения нельзя ни в коем случае. Это свидетельствует о расхождении внутренних идентификаторов.

Как подготовить копию: бэкап СУБД или выгрузка в .dt?

Разберем различия между созданием копии через средства СУБД и выгрузкой в файл .dt. Использование дампа СУБД (SQL backup) является наиболее надежным и быстрым вариантом для клиент-серверных баз. Выгрузка и последующая загрузка базы через файл .dt на больших объемах данных занимает значительно больше времени и создает дополнительную нагрузку на дисковую подсистему. Однако с точки зрения структуры метаданных и сохранения UUID объектов оба способа являются валидными копиями исходной базы, если в процессе работы структура не подвергалась независимым правкам.

Критически важно: пока на тестовой копии идет подготовка релиза, в рабочей базе категорически запрещено менять состав метаданных (добавлять реквизиты, справочники, изменять структуру данных). Если изменения вносятся и в рабочую базу, и в копию параллельно, то при последующей загрузке .cf произойдет рассинхронизация.

Особенности обновления конфигураций на базе БСП

Обратим внимание на работу Библиотеки стандартных подсистем (БСП). Если рабочая база отстает от целевого релиза на несколько версий, накатывание одного итогового .cf не освобождает от процедур обновления данных:

1. Реструктуризация таблиц СУБД выполнится сразу к финальному виду.
2. Однако при первом запуске предприятия в режиме 1С:Предприятие механизмы БСП запустят обработчики обновления последовательно для каждого пропущенного релиза.
3. Если пропустить слишком много версий за один шаг, процедуры БСП могут попытаться обратиться к объектам или реквизитам с префиксом Удалить..., которые разработчики типовой конфигурации уже окончательно вырезали в финальной версии. Это приведет к аварийной остановке обновления данных. Для типовых и околотиповых конфигураций переходы следует выполнять по цепочке рекомендованных релизов.

Альтернативные и безопасные варианты обновления

Рассмотрим способы, позволяющие минимизировать риски потери данных и сократить время простоя:

1. Использование хранилища конфигурации: доработки и обновление ведутся в базе, подключенной к хранилищу конфигурации. В рабочую базу изменения доставляются через штатное обновление из хранилища, что полностью гарантирует сохранение всех внутренних UUID.
2. Сравнение и объединение вместо прямой загрузки: вместо полной замены через «Загрузить конфигурацию из файла» можно использовать команду «Сравнить, объединить с конфигурацией из файла». Это позволяет контролировать соответствие каждого объекта и исключает непреднамеренное удаление метаданных.
3. Поэтапное обновление на рабочей базе без монопольного захвата: как отмечалось в обсуждении, обновить основную конфигурацию в конфигураторе можно заранее, не выполняя обновление конфигурации базы данных. В платформе 8.3 для объемных баз также доступен механизм фонового обновления конфигурации базы данных, который выполняет основную реструктуризацию параллельно с работой пользователей, требуя монопольного доступа лишь на финальной короткой фазе фиксации.

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