Как из копии базы сделать основную базу 1С

После сбоя сервера, неудачного обновления или переезда на новое оборудование рабочей часто оказывается именно копия базы 1С — её и нужно назначить основной: прописать в списке информационных баз, указать правильный путь на SQL-сервере или в файловом каталоге и убедиться, что пользователи подключаются именно к ней. Задача решается штатными средствами платформы 1С:Предприятие — через конфигуратор, консоль администрирования или ручную правку файла ibases.v8i, — но требует аккуратности: ошибка в пути или невыполненная регистрация базы приведёт к тому, что сотрудники продолжат работать в старой копии и данные разойдутся.

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

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

Определите формат копии и режим работы базы

Первый шаг — понять, что именно у вас на руках. От этого зависит вся дальнейшая процедура. Файл с расширением .dt — это выгрузка информационной базы, созданная через конфигуратор (Администрирование → Выгрузить информационную базу). Файл 1Cv8.1CD — это сам файл файловой базы целиком, скопированный на уровне файловой системы. Файлы с расширениями .bak, .dump или папка с данными кластера — резервная копия средствами СУБД.

Также выясните, в каком режиме работала основная база. Файловый режим означает, что база хранится в одном файле на диске или сетевом ресурсе. Клиент-серверный режим предполагает, что данные лежат в СУБД, а доступ идёт через сервер 1С:Предприятия. Восстановление копии в «чужой» режим возможно, но требует дополнительных действий.

Подготовьте основную базу и пользователей

До начала восстановления завершите работу всех пользователей в основной базе и запретите новые сеансы. В файловом режиме достаточно попросить всех выйти и убедиться, что файл базы не заблокирован. В клиент-серверном режиме используйте консоль кластера: установите блокировку сеансов и завершите активные соединения.

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

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

Восстановление из файла выгрузки dt

Это универсальный способ, работающий и для файлового, и для клиент-серверного режима. Создайте новую пустую информационную базу: в окне запуска 1С нажмите «Добавить» → «Создание новой информационной базы» → «Создание информационной базы без конфигурации». Укажите каталог (для файлового режима) или параметры сервера (для клиент-серверного).

Откройте созданную базу в режиме конфигуратора и выполните: Администрирование → Загрузить информационную базу → выберите файл dt. Процесс может занять от нескольких минут до нескольких часов в зависимости от размера выгрузки. После завершения конфигуратор предложит перезапуститься — согласитесь.

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

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

Восстановление файловой базы подменой файла 1Cv8.1CD

Если копия — это файл 1Cv8.1CD, задача сводится к подмене файла основной базы. Убедитесь, что все сеансы завершены и файл не занят. Переименуйте текущий файл основной базы, например в 1Cv8_old.1CD, а файл копии поместите в каталог базы под именем 1Cv8.1CD. Путь к базе в списке пользователей при этом не меняется — для них переход будет незаметным.

Альтернатива — подключить копию как отдельную базу, проверить её и только потом переключить пользователей на новый путь. Это безопаснее: вы убедитесь в целостности копии до того, как основная база будет отключена.

Если файл копии открывается с ошибкой «Файл базы данных повреждён», попробуйте утилиту chdbfl.exe из каталога платформы (папка bin). Она выполняет проверку физической целостности файловой базы. Работайте утилитой только с копией файла, а не с единственным экземпляром.

C:\Program Files\1cv8\<версия>\bin\chdbfl.exe — утилита проверки файловой базы

Восстановление клиент-серверной базы из бэкапа СУБД

Для клиент-серверного режима копия обычно представляет собой резервную копию, созданную средствами СУБД. В MS SQL восстановление выполняется через SQL Server Management Studio: правый клик по узлу «Базы данных» → Restore Database → выбор файла .bak. В PostgreSQL используется команда pg_restore или восстановление через pgAdmin.

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

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

Что сделать после восстановления: очистка следов копии

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

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

Также проверьте: учётные записи пользователей и их права, настройки подключения торгового оборудования, пути к томам хранения файлов, настройки почты и обменов ЭДО. Всё, что ссылалось на старый сервер или старые каталоги, потребует перенастройки.

Проверка результата и переключение пользователей

После восстановления выполните контрольную проверку до того, как впустите пользователей. Войдите в режим предприятия и убедитесь, что открываются основные разделы, даты последних документов соответствуют ожиданиям, отчёты (например, оборотно-сальдовая ведомость или остатки склада) формируются без ошибок. Сравните ключевые цифры с теми, что были в старой основной базе на дату создания копии.

Если путь к базе изменился, обновите список информационных баз у пользователей. В локальной сети удобно использовать общий список баз через файл v8i или публикацию списка на веб-сервере — тогда изменение пути делается централизованно. Если база публиковалась на веб-сервере, проверьте и при необходимости пересоздайте публикацию.

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

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

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

Часто задаваемые вопросы