← На главную

В процессе разработки и поддержки баз данных на платформе 1С:Предприятие специалисты регулярно сталкиваются с ситуацией: выполнено долгое и сложное сравнение/объединение конфигураций, изменения сохранены в Конфигураторе (через Ctrl+S или кнопку сохранения), но база данных еще не обновлена (клавиша F7 не нажималась). В этот момент разработчик понимает, что перед началом работ не был сделан бэкап. Возникает логичный вопрос: можно ли сделать резервную копию прямо сейчас, в этом промежуточном состоянии? Сохранятся ли внесенные изменения в бэкапе, и не повредит ли это саму базу данных? Рассмотрим подробно физику этого процесса, разберем поведение СУБД и выработаем оптимальный план действий.

Понимаем архитектуру: три конфигурации в одной базе данных

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

1. Конфигурация базы данных — это та конфигурация, с которой физически работают пользователи в режиме "1С:Предприятие". Ее метаданные определяют реальную структуру таблиц в СУБД (имена колонок, типы данных, индексы). Информация об этой конфигурации хранится в системной таблице базы данных с именем Config.
2. Основная конфигурация (редактируемая) — это рабочая область разработчика в Конфигураторе. Когда мы вносим изменения, пишем код или выполняем сравнение и объединение, мы работаем именно с ней. При нажатии кнопки "Сохранить" (Ctrl+S) изменения записываются в специальную системную таблицу СУБД под названием ConfigSave. Именно в этом состоянии сейчас находится база автора вопроса: основная конфигурация уже изменена и сохранена в ConfigSave, но конфигурация базы данных в Config все еще старая.
3. Конфигурация поставщика — это эталонная конфигурация от фирмы 1С или другого разработчика, которая используется для поддержки и обновления типовых решений. Она хранится в таблице DBSchema и других служебных объектах.

Таким образом, когда вы сохранили изменения в Конфигураторе, но еще не нажали F7 (Обновить конфигурацию базы данных), вы изменили только таблицу ConfigSave. Физическая структура таблиц с данными пользователей (справочники, документы, регистры) в СУБД осталась абсолютно нетронутой.

Что попадет в бэкап, если сделать его прямо сейчас?

Рассмотрим, как ведут себя различные механизмы резервного копирования, если запустить их в этом промежуточном состоянии:

1. Выгрузка в файл данных (.dt): Если выполнить команду "Администрирование — Выгрузить информационную базу", платформа упакует в архив как рабочие данные пользователей, так и обе таблицы метаданных — Config и ConfigSave. При последующей загрузке этого файла на другом компьютере или сервере вы получите базу в точно таком же состоянии: кнопка F7 (синий бочонок с восклицательным знаком) будет активна, а при запуске Конфигуратора вы сможете продолжить работу с сохраненными изменениями.
2. Резервная копия средствами СУБД (.bak для MS SQL, .backup для PostgreSQL): Этот бэкап копирует абсолютно все таблицы базы данных "как есть" на физическом уровне. В него полностью попадет текущее состояние таблиц Config (старая рабочая структура) и ConfigSave (новые сохраненные изменения). Метод абсолютно безопасен и полностью сохраняет вашу работу.
3. Копирование файла базы данных (1Cv8.1CD): Для файлового варианта работы простое копирование файла базы данных целиком сохранит промежуточное состояние. Вы сможете развернуть эту копию и продолжить обновление на ней.

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

Альтернативный и самый быстрый вариант: сохранение .cf файла

Если ваша информационная база имеет огромный объем (десятки или сотни гигабайт), создание полного бэкапа базы данных может занять часы. Если ваша цель — просто защитить результаты долгого сравнения/объединения конфигураций от потери, делать полный бэкап базы не обязательно. Проанализируем более эффективный сценарий разработки:

1. В Конфигураторе выберите пункт меню Конфигурация — Сохранить конфигурацию в файл....
2. Укажите путь на диске и сохраните файл с расширением .cf. Этот файл содержит только метаданные (вашу доработанную конфигурацию из таблицы ConfigSave) и создается практически мгновенно, независимо от размера пользовательских данных в базе.
3. Теперь вы застрахованы. Если при последующем обновлении (F7) произойдет критическая ошибка, повредятся данные или зависнет сервер: - Вы всегда сможете восстановить старый рабочий бэкап базы данных (сделанный до начала ваших работ). - Зайти в восстановленную базу в режиме Конфигуратора. - Выбрать пункт меню Конфигурация — Загрузить конфигурацию из файла... и указать ваш сохраненный файл .cf. - Нажать F7 для применения изменений.

Этот простой прием избавляет разработчика от необходимости тратить время на повторное сравнение и объединение конфигураций, экономя огромное количество рабочего времени.

Как безопасно откатить изменения без бэкапа?

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

1. В меню Конфигуратора перейдите по пути: Конфигурация — Конфигурация базы данных — Вернуться к конфигурации БД.
2. Платформа сопоставит содержимое таблиц ConfigSave и Config. Данные из таблицы ConfigSave (ваши не примененные изменения) будут полностью перезаписаны актуальными метаданными из таблицы Config.
3. После выполнения этой операции кнопка "Обновить конфигурацию базы данных" (F7) станет неактивной, а основная конфигурация вернется к рабочему состоянию. Учтите, что все не примененные изменения при этом будут безвозвратно утеряны (если вы предварительно не сохранили их в .cf файл).

Важные технические нюансы: локальный кэш пользователей

При активном манипулировании конфигурациями (частые откаты изменений, накатывание файлов метаданных, восстановление промежуточных состояний из бэкапов) разработчики часто сталкиваются с нестабильным поведением платформы на рабочих станциях пользователей. Это связано с тем, что локальный кэш конфигурации (папки DBNameCache, SICache в каталоге AppData пользователя) может вовремя не обновиться.

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

Аварийное восстановление при сбое во время обновления (F7)

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

Для клиент-серверных баз данных под управлением СУБД (MS SQL, PostgreSQL) существует способ реанимировать базу данных без долгого процесса полного восстановления из бэкапа. Для этого выполним следующие действия:

1. Откройте консоль управления вашей СУБД (например, SQL Server Management Studio).
2. Нам необходимо полностью очистить таблицу временной конфигурации ConfigSave. Для этого выполним запрос: DELETE FROM ConfigSave;
3. Затем необходимо убрать признаки незавершенной транзакции обновления из основной таблицы конфигурации. Для этого удалим служебные записи в таблице Config, содержащие маркеры обновления в поле FileName:
   Скопировать код

   
   DELETE FROM Config WHERE FileName IN ('commit', 'dbStruFinal', 'dynamicCommit', 'DynamicallyUpdated');
   

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