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