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