Как сделать копию 1С перед обновлением

Обновление конфигурации 1С — операция, которая изменяет структуру базы данных и не имеет кнопки «отменить». Если во время обновления произойдёт сбой, прервётся электричество или новый релиз окажется несовместимым с вашими доработками, единственный способ вернуться к рабочему состоянию — восстановить базу из заранее созданной копии. Поэтому резервная копия перед обновлением — не формальность, а обязательный этап.

Способ создания копии зависит от того, как развёрнута ваша база: в файловом варианте (папка с файлом 1Cv8.1CD на диске или в сети) или в клиент-серверном (MS SQL Server, PostgreSQL, аналогичная СУБД). Для файловой базы достаточно выгрузки через конфигуратор или простого копирования папки, для серверной нужен бэкап средствами СУБД. Ниже разобраны все рабочие варианты и проверки, которые подтвердят, что копия действительно пригодна для восстановления.

Что именно нужно скопировать и почему

Резервная копия базы 1С — это снимок всех данных: документов, справочников, проводок, настроек и пользователей на конкретный момент времени. Именно она позволяет вернуть базу в состояние «до обновления», если новая версия конфигурации работает с ошибками или обновление прервалось на середине реструктуризации данных.

Важно понимать разницу между двумя объектами: конфигурацией (программной логикой, которую обновляет поставщик) и информационной базой (вашими данными). Обновление меняет конфигурацию и преобразует данные под новую структуру. Копия должна сохранить и то, и другое — поэтому подходят только полные методы: файл выгрузки .dt, бэкап СУБД или копия всей папки файловой базы.

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

Любой способ создания копии через конфигуратор требует монопольного доступа к базе: ни один пользователь не должен быть подключён. Если кто-то останется в программе, выгрузка не начнётся, а копирование файловой базы «на живую» даст повреждённый файл, который не откроется.

Порядок подготовки: заранее предупредите сотрудников о времени работ, попросите всех выйти из программы, затем в режиме «Предприятие» откройте раздел «Администрирование» → «Обслуживание» → «Блокировка работы пользователей» (в типовых конфигурациях) и установите блокировку с кодом доступа. После этого завершите оставшиеся сеансы через консоль кластера (для серверной базы) или проверьте список активных пользователей.

Способ 1. Выгрузка базы в файл .dt через конфигуратор

Это универсальный и самый надёжный штатный метод, который работает и для файловых, и для клиент-серверных баз. Откройте конфигуратор, войдите под пользователем с правами администратора и выберите в меню «Администрирование» → «Выгрузить информационную базу». Укажите путь и понятное имя файла, например Trade_before_update.dt, и дождитесь завершения выгрузки.

Время выгрузки зависит от размера базы: небольшая база выгружается за минуты, объёмная — за десятки минут и дольше. Не прерывайте процесс: прерванная выгрузка даёт непригодный файл. Готовый .dt-файл сразу скопируйте на другой носитель — внешний диск, сетевую папку или облачное хранилище, чтобы копия не лежала только на том же диске, где сама база.

1. 1
   Завершите работу всех пользователей и включите блокировку сеансов
2. 2
   Откройте конфигуратор под администратором
3. 3
   Выберите Администрирование → Выгрузить информационную базу
4. 4
   Укажите путь и имя файла с датой, дождитесь завершения
5. 5
   Скопируйте .dt на отдельный носитель и проверьте размер файла

Способ 2. Копирование папки файловой базы

Если база файловая, допустим более быстрый вариант — скопировать всю папку базы средствами операционной системы. Найдите папку (путь виден в списке баз при запуске 1С), убедитесь, что все пользователи вышли, и скопируйте каталог целиком вместе с файлом 1Cv8.1CD в другое место.

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

Способ 3. Резервная копия серверной базы средствами СУБД

Для баз на MS SQL Server, PostgreSQL или другой СУБД наиболее надёжна копия на уровне самой СУБД. В MS SQL Server это делается через SQL Server Management Studio: правый клик по базе → «Задачи» → «Создать резервную копию», тип — полная, назначение — файл на отдельном диске. В PostgreSQL используется утилита pg_dump или pg_dumpall.

Бэкап СУБД восстанавливается быстрее, чем загрузка .dt, и не требует монопольного режима в момент создания (хотя лучше всё равно делать его без активных пользователей, чтобы снимок был согласованным). Однако работа с СУБД требует прав администратора сервера баз данных — если у вас их нет, обратитесь к системному администратору.

Сравнение способов копирования

Выгрузка .dt

Универсально, переносимо между файловым и серверным вариантами; медленно на больших базах, требует монопольного доступа

Копия папки файловой базы

Быстро и просто; подходит только для файловых баз и требует полного выхода пользователей

Бэкап средствами СУБД

Быстрое восстановление для серверных баз; требует прав администратора СУБД и навыков работы с сервером

Проверка копии перед обновлением

Копия, которая не проверена, — это не копия. Минимальная проверка: файл существует, имеет осмысленный размер (сопоставим с размером базы) и лежит минимум в двух местах. Но этого недостаточно — файл может быть битым.

Надёжный способ проверки для .dt: создайте пустую базу в списке баз, откройте её конфигуратором и выполните «Загрузить информационную базу» из вашего файла. Если загрузка прошла без ошибок и база открывается в режиме «Предприятие» с актуальными данными — копия рабочая. Для бэкапа СУБД аналогично: восстановите его под тестовым именем базы и откройте через 1С.

Контрольные точки

Как проверить результат

Размер файла копии

Норма

Сопоставим с размером базы, файл не нулевой

Тревожный признак

Файл отсутствует, нулевой или аномально мал

Тестовое восстановление

Норма

База загружается из копии и открывается, данные на месте

Тревожный признак

Ошибка загрузки, база не открывается

Место хранения

Норма

Копия есть минимум на двух независимых носителях

Тревожный признак

Единственный файл лежит на том же диске, что и база

Типичные ошибки и ограничения

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

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

Что делать, если обновление пошло не так

Если обновление завершилось ошибкой или база после него работает некорректно, не пытайтесь «докрутить» обновление повторно — сначала вернитесь к копии. Для .dt: создайте чистую базу или очистите текущую, загрузите файл через конфигуратор командой «Загрузить информационную базу». Для бэкапа СУБД: восстановите базу средствами сервера и переподключите её в консоли кластера 1С, если это необходимо.

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

Удобно называть файлы копий с датой и версией релиза, например base_2026-05-10_before_3.1.30.dt. Когда копий накапливается несколько, такое именование избавляет от долгих поисков нужной версии и случайной перезаписи рабочей копии.

Частые вопросы

Достаточно ли скопировать только файл 1Cv8.1CD?

Для файловой базы — да, но только при условии, что все пользователи вышли и ни один процесс не держит файл открытым. Копирование «на живую» почти гарантированно даёт повреждённую копию. Надёжнее сочетать копию папки с выгрузкой .dt.

Чем отличается выгрузка .dt от сохранения конфигурации .cf?

Файл .dt содержит данные, конфигурацию и пользователей — полный снимок базы. Файл .cf содержит только программную конфигурацию без единой записи данных. Для защиты перед обновлением нужен именно .dt.

Сколько места нужно для резервной копии?

Ориентируйтесь на размер самой базы: файл .dt обычно сопоставим с ним или меньше за счёт внутреннего сжатия, бэкап СУБД — близок к размеру базы данных. Держите запас свободного места минимум в полтора размера базы на диске назначения.

Нужно ли делать копию при обновлении платформы, а не конфигурации?

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

Можно ли настроить автоматическое создание копий?

Да. Для серверных баз настраиваются планы обслуживания в СУБД, для файловых — скрипты, запускающие конфигуратор в пакетном режиме с выгрузкой .dt по расписанию. Автоматические копии полезны, но перед обновлением всё равно сделайте отдельную ручную копию и проверьте её.

Что делать, если копия не загружается обратно?

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